Accessibility

Accessibility statement

Last updated 27 October 2026

Benchmark Lab wants this website to be usable by as many people as possible, including people who use a keyboard rather than a mouse, a screen reader or other assistive technology, or browser zoom. We aim to meet the international Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. We do not meet it in full yet, and we list the shortfalls we know about below.

What this statement covers

This statement covers the Benchmark Lab website at www.benchmarklab.co.uk: the homepage, the pages in its menu (Our indices, For your organisation, Custom benchmarks, How every index is built and Pricing, which is the founding rates page), the enquiry form and the free partner application, and the information pages they link to.

It does not cover answering an index. There is no questionnaire on this website, and if you have been invited to answer one you answer it on the website of whoever runs it, under their own accessibility statement. That includes the AI Adoption Index, which is ours and which partners, The AI Lab among them, run under their own names; The AI Lab is a trading name of the same company as Benchmark Lab. Its questionnaire, results and reports are built and hosted separately from this website and have not been assessed for this statement.

What we have done

  • Built every page from plain, semantic HTML with a clear heading structure and labelled navigation, so that assistive technology can find its way around.
  • Made every link and button reachable by keyboard, with a visible focus outline, and put a “Skip to content” link at the top of every page.
  • Made every page read in full without JavaScript. The site runs two small scripts. One folds the navigation behind a menu button on small screens; the other runs the cookie banner and, if you accept analytics, the analytics behind it. If your browser does not run JavaScript, you see every page’s content, the navigation laid out in full at the top of the page, and no banner at all.
  • Made the menu button on small screens a real button: it tells a screen reader whether the menu is open or closed, it opens and closes from the keyboard, and the Escape key closes it and returns you to the button.
  • Kept text as real text rather than pictures of text, underlined links within paragraphs so that they do not rely on colour alone, and hidden purely decorative graphics, such as the logo mark, from screen readers.
  • Used one responsive layout that reflows to fit the screen, from a phone to a desktop.
  • Set the language of every page, so that screen readers pronounce it correctly.
  • Avoided anything that moves, flashes or plays on its own. The only motion is smooth scrolling when you follow a link to another part of the same page, and it is switched off if your device is set to reduce motion.
  • Served our fonts from this website rather than from a third party.

Known limitations

  • The illustrative specimen reports use very small text. On the homepage, the Our indices page and the Custom benchmarks page they are drawn at reduced scale to look like printed or on-screen reports. They show fictional data, and what each illustrates is described in the text beside it.
  • Long words can push the page sideways if you widen letter spacing yourself. If you use a browser setting or an extension to increase the space between letters, the largest heading on the homepage becomes wider than a narrow phone screen and that page scrolls sideways. Nothing is cut off or hidden, and the heading is still there and still readable, but you have to scroll to reach the end of it.

How we checked

An automated check, run on the built site every time we change it, confirms that each page sets its language and has exactly one main heading, a skip link to the main content, a title and a description, and that every link within the site leads somewhere.

On 12 September 2026 we also tested every page with an automated accessibility tool, against the WCAG 2.2 rules it covers, at both desktop and phone widths and with the cookie banner both open and reopened from the footer. It reported nothing. We went through every page with the keyboard alone, checking that each link, button and form field can be reached in a sensible order and shows a visible outline when it has focus. We measured the contrast of every piece of text against the colour actually behind it on the page, which is how we found the contrast problems described in the paragraphs below. And we checked each page at a 320 pixel width, the width WCAG asks about, to confirm it reflows rather than scrolling sideways.

On 15 September 2026, after the homepage was redesigned, we ran the automated tool over every page again at desktop and phone widths, measured the contrast of the rust text again, and repeated the 320 pixel and letter spacing checks. The tool reported only the two small “Route one” and “Route two” labels, whose rust text was below the contrast WCAG asks for.

On 27 September 2026, when the menu button was added, we ran the automated tool over the homepage at phone and desktop widths with the menu open and closed, confirmed from the keyboard that the button opens the menu, that Tab then moves into it and that Escape closes it and returns focus to the button, checked the page again at a 320 pixel width, and checked that with JavaScript switched off the navigation is laid out in full. The tool again reported only the two route labels.

On 30 September 2026, when the site grew from one page to six, we ran the automated tool over every page at desktop and phone widths, with the Improve register form open, and checked every page at a 320 pixel width for sideways scrolling, with and without JavaScript. The tool reported only some small rust labels and numbers, on the Our indices, Founding rates and How every index is built pages, whose contrast was below what WCAG asks for. We also confirmed that the register form opens from its buttons without JavaScript, and that its two “We are” choices can be reached and chosen from the keyboard.

On 2 October 2026 we fixed those rust labels and numbers. Where the rust was used for small text we made it a very slightly darker shade on the cream background and a slightly lighter one on the dark section, each measuring at least 4.5:1, and the colours that links and buttons turn while you point at them moved with them, so that they met the same ratio. We then ran the automated tool over every page again at desktop and phone widths, with the register form open, and it reported nothing.

On 25 October 2026 the site’s accent colour changed from rust to a deep red, and on 26 October 2026 it changed back to the rust described above. That day we ran the automated tool over every page again at desktop width and at a 320 pixel width, and it reported nothing.

Those checks are not a full accessibility audit. An automated tool finds perhaps a third of the problems a person would. The site has not yet been audited against WCAG 2.2 by anyone independent of us, and it has not yet been tested with screen readers or other assistive technology.

Compatibility

The site is plain HTML and CSS, with two small scripts, one for the menu button on small screens and one for the cookie banner, and is designed to work in current versions of the major browsers (Chrome, Edge, Safari and Firefox). It works without JavaScript, it plays no media, and apart from the cookie banner and the menu it shows no pop-ups.

Tell us about a problem

If you find something on this site that is hard to use, or you need information from it in a different format, please email index@benchmarklab.co.uk. Tell us the page and what went wrong, and we will do our best to put it right and to get you the information you need. We aim to reply within five working days.