Job Lab field guide

Accessibility

The site is designed and tested towards WCAG 2.2 Level AA. Do not describe it as fully conformant until the completed public build has passed the release audit and any remaining failures are documented.

Our target and current status

The target applies to calculators, guides, source records, navigation and print output. Current verification includes semantic headings and landmarks, keyboard operation, visible focus, narrow viewports, zoom, no-JavaScript reading, reduced motion, automated accessibility checks and print review. Automated checks cannot establish conformance by themselves.

Tests use the completed static artifact rather than relying only on component source.

Meaning is not conveyed by colour alone. Result states use text labels, and the site does not use green as a safety verdict. Units and assumptions are written beside values rather than encoded only by a tick position.

Manual review remains necessary.

It includes reading order, heading sense, focus order, table navigation and the clarity of errors and stop messages.

Keyboard and focus

Interactive controls must work by keyboard, have programmatic labels and use a visible 2 px ink-coloured focus outline; amber may be an additional cue but not the only focus indicator. Navigation follows document order, and no component should trap focus.

Skip/navigation controls, links, calculator fields, reset and print controls are included in the keyboard path. Focus indication is tested against the paper surface and ruled elements, not merely against a plain white sample.

Text, colour and zoom

Layouts must remain usable at 200% browser zoom and at a 390 × 844 CSS-pixel viewport without horizontal page scrolling; data tables may use a labelled local scroll region only when unavoidable. A 340 px narrow check is also used to expose long source keys, formulae and controls.

Text can reflow, paragraphs are kept short and abbreviations are expanded at first use. Tables have headings and an accessible region label where horizontal local scrolling is necessary. The deliberate no-image design avoids decorative media and unverified technical diagrams; no information depends on an image.

Calculator status and errors

Input errors and stopped results are announced in text. Focus must move to or be programmatically associated with the error summary after calculation, without trapping the user. Required inputs, units, allowed ranges and assumptions remain available in text.

A stopped result suppresses the affected number and print control. Status is not indicated by colour alone, and a passed numeric gate is not described as an overall safety or compliance outcome.

Motion, JavaScript and print

Reduced-motion preferences disable non-essential cursor/tick movement and transitions. No content depends on animation. Without JavaScript, guides and methodology remain readable and the Job Pack route provides a printable blank worksheet and links to individual tools. Interactive calculations require JavaScript.

Print output is monochrome-readable and includes labels rather than colour-only states. Representative guides, Methodology and Sources are checked for clipped tables, orphaned stop headings and legible source/version information.

Known limitations

Interactive calculations require JavaScript; the no-JavaScript fallback cannot calculate results. Dense formula notation and wide source tables may require additional navigation on small screens. These are limitations to minimise and test, not reasons to omit accessible names, text equivalents or local table scrolling.

The source register contains long canonical keys and external URLs. They wrap where possible, while formula/source tables use a labelled local scroll region when they cannot reflow meaningfully. PDF output can vary between browser print engines, so the release audit uses a supported browser and textual extraction as well as visual review.

The absence of a public feedback route is another limitation. The target remains WCAG 2.2 Level AA rather than a claim of completed conformance until the final integrated build, including P4, is audited and remaining failures are published.

Reporting a problem

We do not currently publish an accessibility contact email or form. When the operator supplies a public contact route, it will be added here. Until then, do not invent or infer an address. This lack of a reporting channel is itself a known launch limitation.

When a channel exists, a useful report will identify the page, control, browser/assistive technology and what prevented completion. It will be handled under the change process in Methodology.

See Privacy, About, the calculators and the readable guide routes.