Accessibility

What was done

• Keyboard. Every control is reachable and operable from the keyboard in the order it appears in the markup. A skip link is the first focusable element on every page.
• Visible focus. Focus is never removed. The focus ring is a triple ring — light, dark, then a clay outline — so it stays visible on the paper background, on the raised warm-white panels and on the dark green header.
• Contrast. Body text and anything under 24px uses only the colours measured as body-text safe on this palette. Two colours in the palette, the moss green and the clay orange, are decorative only: they draw rules, ticks and pegs, and never carry text meaning on their own.
• Nothing signalled by colour alone. An invalid field has a border, a tint and a message in words. A stale result has a wash and the sentence "Inputs changed." An outcome chip has a label as well as a colour.
• Targets. Every interactive element, including unit selects, segmented chips and row remove buttons, is at least 44px in both directions.
• Labels and names. Every input has a real <label>. Names read sensibly out of context — "Section 2 length", not "Length" — and help text is associated with aria-describedby rather than left as a placeholder. Placeholders never carry information.
• Number entry. Measurement fields are text inputs with inputmode="decimal", never type="number", because a number input silently discards a decimal comma in several browsers and hides the character from validation.
• Announcements. Results are announced through a polite live region and the error summary uses role="alert". Both regions exist in the page from load, so announcements are reliable rather than dependent on an element appearing.
• Focus movement. A successful calculation moves focus to the result card without a scroll jump. A failed one moves focus to the error summary heading, which links to each field that needs attention.
• Motion. There is no animation on scroll, no parallax and nothing auto-playing. Under prefers-reduced-motion the remaining transitions collapse to zero.
• Forced colours and increased contrast. Supported. In forced-colours mode the decorative rails, ticks and graph-paper ruling disappear and borders switch to the system text colour, so nothing depends on a background image surviving.
• Headings and landmarks. One <h1> per page, no skipped heading levels, and header, navigation, main and footer landmarks throughout.
• Zoom and reflow. Layouts reflow rather than scroll sideways. Every route was checked for horizontal overflow at 1440, 768, 390 and 340 pixels wide.

What works without JavaScript

All navigation, including the menu, which is a native disclosure element rather than a scripted one. All reading content: the direct answer, the method sections, the tables, the source citations and the limitations. On calculator routes the measurement form is visible and readable, and the worked example is shown and labelled as an example.

What does not work is calculation. The calculators and the three planners need JavaScript, because the arithmetic runs in your browser and there is no server to run it on. Without scripting, the Calculate control is not a submit button and the page says so in words: "Calculations run in your browser. Enable JavaScript to use this calculator." No static content is ever presented as though it were your result.

Known limitations

• Calculation requires JavaScript. There is no server-side fallback and, on a static site with no back end, there cannot be one.
• The measurement form is long on the calculators with many assumptions. Screen-reader users moving field by field will pass through a number of optional inputs before reaching the calculate control; the fieldset legends are there to make skipping between groups easier.
• When a section row is removed, the remaining rows renumber. That is correct for matching the printed record, but it means a field's accessible name can change while you are working.
• Result tables are wide by nature. At 340px they remain readable but some cells wrap tightly.
• Testing was done with automated checks and manual keyboard and zoom passes in a Chromium-based browser. It has not been tested with every combination of screen reader and browser, and no testing with disabled users has been carried out.
• There is no contact channel in this build, so a problem you find cannot be reported to anyone. That is recorded here rather than papered over with a form that goes nowhere.

What this statement is not

It is a description of the approach taken and of what was actually tested. It is not a certification, not a conformance claim and not the result of a third-party audit. WCAG 2.2 AA is the target this build was written against, and the list above is what was done in pursuit of it — stated as work performed rather than as a standard met.

Related tools

• Read what this site is
• Read the privacy statement