Record AR-STD-040 · Accessibility statement
What was built for access,
and where it falls short.
A statement about this specific site rather than a generic commitment. It names the standard aimed at, lists what is actually implemented, states plainly that no formal audit has been carried out, documents four limitations that are known and unresolved, and explains what makes a report of a failure actionable.
01The standard, honestly statedAR-STD-040·01
WCAG 2.2 AA as an aim,
not as a claim.
This site is built with the Web Content Accessibility Guidelines 2.2 at level AA as its design target. Every structural decision — landmarks, heading order, focus management, contrast, target size, motion control, text alternatives — was made with those success criteria in view.
It has not been formally audited, and no conformance claim is made. No qualified accessibility professional has reviewed it, no accessibility conformance report exists, and no automated scan is a substitute for either. The correct description of its status is partially conformant, unverified — meaning the intent is there, the implementation is careful, and nobody with the standing to certify it has looked.
That distinction is not pedantry. A site that announces “WCAG 2.2 AA compliant” without an audit behind it is making a claim it cannot support, which on a site whose entire argument is about not making unsupported claims would be a particularly poor look. The known limitations section below lists four issues that would almost certainly be raised by an audit, and it is safe to assume there are others that have not been noticed.
Accessibility defects are treated as defects of the same severity as a wrong number, and they are prioritised above feature work. That is the actual commitment, and it is a more useful one than a badge.
Status summary
02What is implementedAR-STD-040·02
Specific measures,
specifically described.
Each entry below describes something you can verify on this page while reading it. A statement of intent would be shorter; this is meant to be checkable.
| Measure | What is implemented | Applies to |
|---|---|---|
| Semantic landmarks | Every page uses a banner header, a primary navigation region, a single main region and a content-info footer, each correctly labelled. The contents rail on long pages is a labelled complementary region rather than an unlabelled block of links. | Every page |
| One h1, no level jumps | Exactly one first-level heading per page, describing that page and nothing else. Heading levels descend by one and never skip, so the document outline is navigable by heading shortcut. | Every page |
| Skip link | A skip-to-content link is the first focusable element on every page. It is visually hidden until focused, then rendered clearly, and it moves focus to the main region rather than merely scrolling to it. | Every page |
| Visible focus | Every interactive element carries a high-contrast focus ring that is never removed. Focus is never suppressed for aesthetic reasons, and the ring is visible against every surface used in the design. | Every control |
| Keyboard-operable components | Tabs, accordions, parameter sliders, switches and the facility menu are all fully operable from the keyboard. Tabs support arrow-key traversal with correct selection state; accordions expose expanded state; sliders are native range inputs with keyboard stepping; the menu closes on Escape and returns focus. | All interactive modules |
| Reduced motion | The operating-system prefers-reduced-motion setting is honoured automatically, suppressing scroll reveals, parallax and canvas animation. A persistent motion toggle in the footer and the facility menu overrides it in either direction, stored in one local key so the choice survives navigation. | Every page |
| Chart text alternatives | Every figure is inline SVG carrying an accessible title and a plain-language description generated at construction — the figure library requires both. A screen reader announces what the chart shows and what conclusion it supports, and each figure also carries a written caption in the visible text. | All figures |
| Decorative canvas | Animated canvas scenes are marked aria-hidden and are never the sole carrier of information. Everything a scene depicts is stated in prose immediately adjacent to it, and each scene host provides a text fallback naming the scene. | All scenes |
| Target size | Interactive targets meet a 44-pixel minimum in their smallest dimension, including navigation links, tab controls, accordion headers, buttons and the consent checkbox on the contact form. | All controls |
| Dense tables scroll | Wide analytical tables sit inside a horizontally scrollable wrapper rather than being compressed. Column headings, row headings and captions are marked up properly so the structure is announced, and a caption states what the table contains. | All data tables |
| Status is never colour alone | Every state indicator pairs a coloured dot with a text label — operational, preview, planned, simulated, warning. Form errors are written as text beneath the field they concern as well as marking the field invalid. Table cells that carry a tone also carry the value that justifies it. | Every status surface |
| Tabular numerals | Figures, readouts, tables and log entries use tabular numerals so digits align in columns and a changing value does not shift the layout around it — which matters most for anyone reading with magnification. | All numeric displays |
Text and zoom
Type is set in relative units and the layout reflows rather than breaking at 200 per cent browser zoom and at a 360-pixel viewport. No page produces horizontal scrolling of the document itself at either.
No timing, no interruption
Nothing on this site is timed, expires, auto-advances, auto-plays sound, or interrupts reading with a modal. There are no countdowns and no dismissable overlays because there are no overlays.
Works without a network
Once loaded the site functions offline, which also means it functions on a slow or intermittent connection — an accessibility property that is rarely listed as one.
03Motion, in detailAR-STD-040·03
Two ways to stop
everything moving.
This is a site with scroll reveals, parallax, animated canvas scenes and transitioning instrument values. For a reader with a vestibular disorder, that combination is not a stylistic preference — it can be actively harmful. Two independent controls exist.
Your system setting is honoured automatically. If your operating system reports prefers-reduced-motion, the site suppresses reveals, parallax and canvas animation from the first paint, with no interaction required and nothing stored. This is the default path and it needs no action from you.
A persistent toggle overrides it in either direction. The motion control in the site footer and in the facility menu switches motion off — or back on, if your system setting is suppressing motion you would rather have. The choice is written to a single local key so it survives navigation between pages, and it is the only value this site stores.
When motion is off, transitions collapse to zero duration rather than being shortened, canvas scenes stop rather than slowing, and reveal-on-scroll content is shown immediately in its final position — so nothing becomes unreachable as a consequence of turning motion off.
Keyboard reference
No custom keyboard shortcut is bound anywhere on this site, so nothing here conflicts with your assistive technology's own key bindings.
04Known limitationsAR-STD-040·04
Four limitations,
with the reasoning behind each.
Two of these are deliberate design positions that can reasonably be argued with. Two are simply not done. All four appear on the facility status board's known-issues list as well, so they are visible to someone who never reaches this page.
The animated scenes — the drawdown terrain, the regime tunnel, the branch network, the correlation field, the Monte Carlo path cloud — are rendered to a canvas element and marked aria-hidden. A screen reader does not encounter them at all.
The reasoning: they are decorative by design. Every relationship a scene depicts is also stated in the prose immediately beside it, and in most cases rendered again as an accessible SVG figure elsewhere on the same page. Announcing a scene with a short description would imply there was additional content behind it that a non-visual reader was missing, which would be false and would waste their time.
Where the argument is weak: a sighted reader watching a correlation field collapse under stress gets an intuition that a sentence conveys less immediately. That intuition is a real, if secondary, benefit and it is currently unavailable non-visually. Closing the gap properly means rebuilding those scenes as accessible figures, which is a substantial piece of work rather than a label change.
Mitigation today: no scene carries unique information; each scene host also provides a visible text fallback naming what it depicts; and every page states in prose what its scene shows.
Every chart carries an accessible title and a plain-language summary stating what it shows and what conclusion it supports. What no chart offers is point-by-point navigation of its underlying series, or an equivalent data table.
For a simple comparison — expectancy across twelve archetypes, module counts by status — the summary carries essentially all of the information. For the dense figures it does not. The correlation matrix, the Monte Carlo path field and the regime timeline reward inspection at individual points, and compressing that into a sentence is a genuine loss rather than a reformatting.
Status: open, with the intended fix identified — tabular equivalents for the dense figures, exposed alongside the chart rather than hidden behind it, so the data is available to everyone rather than provided as a lesser alternative.
Everything on this page describes work done by the person who built the site, checked by the person who built the site. That is the weakest possible form of verification: a builder tests the paths they had in mind, and accessibility failures cluster in the paths they did not.
No accessibility professional has reviewed this site. No conformance report exists. No assistive-technology user has been asked to attempt a task on it and report where they got stuck, which is the test that actually matters and the one whose absence is most significant.
What follows from that: the four limitations listed here are the ones that were noticed. It is close to certain that others exist. A report of a specific failure from someone using this site with real assistive technology is worth more than any amount of further self-checking, and it will be acted on.
The site has one visual theme: a dark instrument palette chosen for extended reading of dense technical material and for the legibility of coloured data series against a dark ground. Body text and interface text were selected to exceed the AA contrast minimum against their surfaces, and status colours are always paired with text.
There is nonetheless no high-contrast mode, no light theme, and no support for a forced-colours or inverted-colours environment that has been specifically tested. Readers who need substantially higher contrast, or who find light text on a dark ground harder to read — which is a real and common preference rather than an unusual one — are currently dependent on operating-system-level adjustment that this site does not test against.
Status: open. A forced-colours pass is the smaller piece of work and would come first; a full light theme would require re-deriving every data-series colour and is a larger undertaking.
05How this was checked · methodologyAR-STD-040·05
Informal checks,
described as such.
The following is what was actually done. It is deliberately not called “testing” without qualification, because certified testing means something specific and none of this is it.
Checks performed
What those checks are worth
Assistive technologies the site was checked against
Informal checks were made with a desktop screen reader on a modern browser, keyboard-only operation across desktop browsers, browser zoom to 200 per cent, and the operating-system reduced-motion preference. It has not been checked with voice control, switch access, screen magnification software, braille displays, or mobile screen readers. Those are unverified rather than unsupported — the absence of a claim is not a claim of absence, and reports from any of them are particularly welcome.
06Reporting a problemAR-A11Y-REP
How to report a failure,
and what happens then.
Use the contact record and select the accessibility issue enquiry type. A report is most useful when it contains the page, the assistive technology and version, the browser and operating system, what you were trying to do, and what happened instead. If a control was reachable but not operable, saying which key you pressed usually identifies the fault immediately.
You do not need to diagnose anything or to cite a success criterion. “The tab controls on the regimes page do not respond to arrow keys with my screen reader in browse mode” is a complete report. So is “I cannot tell which of these states is the active one.”
Accessibility defects are prioritised above feature work. Where a fix is straightforward it is made and recorded in the build log with a description of what was wrong. Where it is not — the canvas scenes are the obvious example — the limitation is added to the known-issues list on the status board with its reasoning, rather than being left undocumented while it waits.
No response timescale is promised anywhere on this site, and this page will not be the exception. What is promised is that these reports go to the front of the queue.
Worth reporting
Access is part of
the honesty policy.
A facility that argues at length about disclosure, reproducibility and not overstating a claim cannot be quietly unusable for a portion of its readers and treat that as a separate matter. It is the same commitment applied to a different surface, and it is measured the same way — by what is documented, what is admitted, and what gets fixed.
WCAG 2.2 AA targeted · partially conformant · not formally audited · reports prioritised