Accessibility

Conformance status

We believe the site substantially conforms to WCAG 2.2 Level AA. Substantially, not fully, because full conformance is a claim that requires an audit against every success criterion and we have tested against the ones that apply to a text-heavy static site rather than commissioning a formal audit.

The known gaps are listed further down, in specific terms rather than as a general disclaimer. If you find one that is not listed, telling us is the fastest route to it being fixed.

What is implemented

Structure and semantics

Every page uses real HTML landmarks: a header with the site navigation, a main region, a footer. Headings are properly nested, with one level-one heading per page and no levels skipped, so heading navigation in a screen reader gives you an accurate outline of the document.

Articles use ordinary paragraph, list and table elements. There is no content rendered as an image of text anywhere on the site.

Every page begins with a skip link that jumps to the main content. It is visually hidden until focused, at which point it appears at the top left with a solid background.

Keyboard

Everything interactive is reachable and operable with a keyboard alone. That means the navigation, the mobile menu toggle, every link, and every control in the step solver.

Focus indication is a three-pixel solid outline with an offset, applied through :focus-visible so it appears for keyboard users without adding a ring on every mouse click. The outline uses the page's foreground colour, which gives it maximum contrast against the background in both light and dark schemes.

There are no keyboard traps, no custom focus management that moves focus unexpectedly, and no positive tabindex values anywhere. Tab order follows document order because the layout does not reorder content visually.

The expression field in the solver accepts Enter to evaluate, so the common case does not require tabbing to a button.

Colour and contrast

The palette is deliberately near-monochrome. Body text is near-black on white, which measures a contrast ratio around 19 to 1, far above the 4.5 to 1 required at Level AA. Muted secondary text uses a mid grey at approximately 5.3 to 1, above the threshold. Large headings clear the 3 to 1 large-text requirement with substantial margin.

Colour is never the only carrier of meaning. There is no red-for-error and green-for-success anywhere. The solver's error state inverts to white text on a solid black block, which is a change in luminance and layout, legible regardless of colour perception.

A dark colour scheme is supported through prefers-color-scheme and inverts the palette while preserving the same contrast ratios.

Text and zoom

All type is sized in relative units. Text reflows without horizontal scrolling at 400 percent zoom in a 1280 pixel viewport, which is the WCAG 2.2 reflow requirement.

Line length in article text is capped at roughly 70 characters, which is within the range recommended for readers with dyslexia and for anyone using magnification. Line height in body text is 1.75, above the 1.5 minimum in the text spacing criterion.

Applying custom text spacing through a user stylesheet does not clip or overlap content, because no container has a fixed height that depends on the text fitting.

Motion

There is very little animation on the site: a link underline that grows on hover, and nothing else. Any animation is disabled entirely under prefers-reduced-motion: reduce.

Nothing moves, blinks, auto-plays or updates without your action. There are no carousels, no auto-advancing content and no video.

Forms and controls in the solver

Every input has a visible, programmatically associated label. Nothing relies on placeholder text as a label.

The mode tabs use ARIA tab semantics with aria-selected reflecting the current state, and the selected tab is also distinguished visually by inverted colour and heavier weight, so the state is not conveyed to assistive technology alone.

The result region carries role="status" and aria-live="polite", so a screen reader announces the answer when a calculation completes, without interrupting whatever is being read at the time.

Error messages appear in the same region as results, in text, describing what was wrong in ordinary language. An unbalanced parenthesis says so. It does not say "invalid input".

Native inputs are set to 16 pixels on small screens, which prevents iOS Safari from zooming the viewport on focus and then failing to zoom back out.

The contact form

Every field has a visible label bound to its control, and the labels say what the field is for rather than relying on placeholder text. The message field states its purpose below the control, not inside it.

Validation happens on submit, not while you type, so nothing is flagged as wrong before you have finished writing it. When a field fails, the message describes the problem in ordinary language and focus moves to that field, so a screen reader user is told what is wrong and taken to it in one step.

The status message uses role="status" with a polite live region, so success, failure and progress are announced without interrupting whatever is being read. The error state is a filled black block rather than a colour change, legible regardless of colour perception.

The form works without JavaScript. It is a real form element with a real action, so submitting it without scripts posts normally and lands on the relay's own confirmation page. The script only keeps you on this site and shows the result inline.

Without JavaScript

Every page except the solver and search works completely with JavaScript disabled. Articles, navigation, all static pages and the contact form are plain HTML.

The one degradation is the mobile navigation toggle, which needs script to expand the menu below 760 pixels. On a wider viewport the navigation is always visible. This is a gap and it is listed below.

The solver requires JavaScript because it is a calculator. There is no server to fall back to.

Known gaps

Stated specifically, because a vague statement of ongoing commitment is not useful to someone deciding whether the site will work for them.

Mobile navigation without JavaScript. With scripts disabled on a viewport under 760 pixels, the menu cannot be opened. Every page remains reachable through the footer, which is always visible and contains links to the archive, the solver, and every static page. A fix using a checkbox-based disclosure is planned.

Mathematical notation. Formulas in articles are written as prose or as plain-text expressions rather than as MathML or rendered LaTeX. This was chosen deliberately: rendered mathematics has poor and inconsistent screen reader support across browsers, and image-based rendering is worse. The tradeoff is that complex expressions read awkwardly. Where an expression is genuinely difficult to express in prose, the article restructures the argument rather than introducing notation.

Wide tables. A small number of articles contain comparison tables that scroll horizontally on narrow viewports. The scroll container is on the table rather than the page, so the article itself never scrolls sideways, but reaching the far column on a phone requires a horizontal gesture.

No formal audit. Testing has been manual, against the criteria listed above. No third-party accessibility audit has been commissioned and no automated scan substitutes for one.

How this was tested

Keyboard-only navigation through every page and every solver control, checking focus visibility and order.

Screen reader passes with NVDA on Windows in Firefox, and VoiceOver on macOS in Safari, covering heading navigation, landmark navigation, the skip link, form labels and the live region announcements.

Zoom to 400 percent at 1280 pixels wide, checking for reflow and clipping.

Contrast measured on every text and background pairing in both colour schemes.

Rendering with JavaScript disabled, and with a custom stylesheet applying the WCAG text spacing values.

Automated checks with axe and the browser's built-in accessibility inspector, understood as a floor rather than a verdict, since automated tools detect roughly a third of real barriers.

Reporting a barrier

If something here does not work with your setup, we want to know, and a report will be treated as a bug rather than a request.

Report it through the contact form, picking the accessibility topic. Useful detail: the page URL, what you were trying to do, what happened instead, and what you are using, meaning browser, operating system and any assistive technology with its version.

You will get an acknowledgement within five working days with an assessment of the problem and, where a fix is straightforward, a date. Where it is not straightforward, you will get an honest account of what is involved rather than an indefinite acknowledgement.

If you need content from this site in a different format, ask. A plain text version of any article can be provided.

Why this page is specific

Most accessibility statements are written to satisfy a requirement rather than to inform a reader, which is why they tend to describe aspirations and omit gaps. A statement that lists no known problems is either describing a fully audited site or is not being candid, and the second is more common.

The four gaps above are real and the first one will affect somebody. Listing them is more useful than a paragraph about our commitment to inclusion, and it means this page can be checked against the site rather than merely believed.