Accessibility statement

We build this site to be usable with a keyboard, with a screen reader, at high zoom, on a small screen, on a slow connection, and with JavaScript switched off. Those are not edge cases; they are Tuesday.

Last reviewed: September 3, 2026.

The standard we aim at

We target the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA, published by the World Wide Web Consortium. We describe this as our target rather than as a certified conformance claim, because we have not commissioned an independent audit. Where we know we fall short, it is listed below rather than omitted.

WCAG is also the yardstick behind most national accessibility rules, wherever you are reading from. In the United States, Section 508 of the Rehabilitation Act adopts WCAG level AA by reference for federal agencies, and the Department of Justice rule under Title II of the Americans with Disabilities Act sets the same level for state and local government sites. Rules elsewhere are built on the same guidelines, so a page that satisfies WCAG generally satisfies them too. Those regimes are aimed mainly at public bodies and at certain commercial services rather than at an independent reference publisher, so most of them do not apply to us directly. We treat the level of access they describe as a floor rather than a ceiling, and WCAG 2.2 AA sits above it.

What we have done

Structure. Every page uses real semantic HTML: one h1, headings in order, landmark elements for the header, navigation, main content and footer, real lists for lists, and real tables with header cells scoped to their rows and columns. A screen reader user can navigate by heading and land where they expect to.

Keyboard. Everything works without a mouse. There is a skip link as the first focusable element on every page. Focus is always visible, with a high-contrast focus ring that we have deliberately not removed. The mobile menu can be opened, used and closed with the keyboard, and Escape closes it.

Color and contrast. Body text, headings and interface text are chosen to exceed the WCAG AA contrast minimum against their backgrounds in both light and dark modes. Color is never the only way information is conveyed. The site follows your system's light or dark preference automatically.

Text. Text is real text, never an image of text. It reflows to a single column on narrow screens and remains usable at 200 percent zoom without horizontal scrolling. Line length is limited for readability. We use system fonts, which respect any font settings you have configured.

Motion. There is almost no animation in anything we write, and what little there is respects the prefers-reduced-motion setting, including smooth scrolling, which is disabled if you have asked your system to reduce motion. Nothing on a page moves, expands or reflows after it has loaded: the layout is settled by the time the text appears, and no third-party code runs afterwards to shift it.

Images and diagrams. The diagrams here are inline SVG with a title and a description, exposed to assistive technology. Decorative marks are hidden from screen readers rather than being announced as meaningless.

Without JavaScript. The site is fully readable and navigable with JavaScript disabled. Navigation is real links. The search page falls back to a complete, browsable list of every guide and every glossary entry. JavaScript adds the mobile menu toggle, the reading-position highlight in the table of contents, and live search, and nothing that only exists in JavaScript is essential to reading the content.

Performance as accessibility. There are no web fonts and no third-party code of any kind: every file a page loads comes from this domain. Pages are small and render quickly on a slow connection or an old device, which matters more for real-world access than most accessibility features do, and nothing loads late and pushes the text you were reading down the screen.

Language and clarity. The page language is declared. We define jargon on first use, keep sentences short, and avoid relying on idiom. Link text describes its destination rather than saying "click here", and links that open in a new tab say so to screen reader users.

What we know is not yet right

Being specific about this is the point of the exercise.

• No independent audit. Our testing is internal. We have not had the site assessed by an external accessibility specialist or by a panel of assistive technology users, so there will be things we have not noticed.
• Wide comparison tables. Several guides use tables with four or five columns. On a narrow screen these scroll horizontally inside a focusable region. That works, and it is announced, but a genuinely responsive alternative would be better and we have not built one yet.
• Table complexity. A few tables carry more information than is ideal for linear reading. We are gradually splitting the worst offenders.
• Long pages. Some guides are very long by design. The table of contents helps, but there is more we could do to support navigation within a page.

Reporting a barrier

If any part of this site is hard for you to use, please tell us through the contact page, with "Accessibility" in the subject line. Say what you were trying to do, what happened, and what you were using (browser, assistive technology, device) if you can.

We treat these reports as bugs rather than as suggestions. We aim to acknowledge within three business days and to tell you what we are going to do about it and when. If we cannot fix something quickly, we will say why and offer an alternative way to get at the information. If we cannot fix it at all, we will say that too, rather than leaving you waiting.

Related

Our editorial standards cover the writing side of clarity, and the corrections policy covers factual errors, which are a different kind of barrier and are handled separately.