Accessible Operation
A governed platform is only trustworthy if the people accountable for it can actually operate it, including operators, analysts, and administrators who use assistive technology. Accessibility in System9 is treated as a property of the product, built into the shared interface primitives every screen is composed from, rather than retrofitted screen by screen.
System9 assesses the platform application against WCAG 2.1 AA and WCAG 2.2 AA. This is a self-assessment, and the application is partially conformant: the accessible foundations below are implemented at the design-system level and enforced mechanically on every change, while application-wide verification and a full screen-reader test cycle are still in progress.
There is no third-party audit, and no certified VPAT or Accessibility Conformance Report. That is a deliberate position rather than a gap awaiting budget. We would rather spend the effort on enforcement that catches regressions on every pull request than on a point-in-time attestation that is stale the week after it is issued. What we offer instead is below: the standards we hold ourselves to, the gates that hold us there, the numbers behind them, and the exceptions we have not yet closed.
If your procurement process requires a signed third-party ACR, tell us early so we can discuss it rather than have you discover it late.
Standards we target
| Standard | What it covers |
|---|---|
| WCAG 2.1 AA / WCAG 2.2 AA | The core web accessibility success criteria |
| Section 508 (Revised, 36 CFR Part 1194) | U.S. federal ICT accessibility |
| EN 301 549 (v3.2.1) | European ICT accessibility |
| ADA Title III | U.S. public-accommodation accessibility (WCAG 2.1 AA as the de-facto measure) |
| AODA | Accessibility for Ontarians with Disabilities Act |
Assistive technology supported
The platform application is built and tested to be operated with:
| Assistive technology | Platform / browser |
|---|---|
| NVDA | Windows, with Firefox and Chrome |
| JAWS | Windows, with Chrome |
| VoiceOver | macOS and iOS, with Safari |
| TalkBack | Android, with Chrome |
| Narrator | Windows, with Edge |
Beyond screen readers, the application supports keyboard-only operation with
no pointer required, switch control, voice control, browser zoom to
200%, operating-system high-contrast modes (via the forced-colors media
query), user-configured text spacing, and the operating-system
reduced-motion preference.
Accessible by construction
Every screen is assembled from a shared set of interface primitives, so accessible behavior is inherited rather than re-implemented:
- Navigation and focus. A skip-to-content link is the first focusable element,
the primary content region is a labeled
mainlandmark, navigation regions are labeled, and a live region announces route changes so screen-reader users hear where they have landed. Per-page titles keep the browser and screen-reader context accurate. (Active-route marking and a mobile-drawer focus trap are in progress.) - Forms. Form fields are built from labeled primitives with programmatic labels, autocomplete hints, and an error summary that surfaces on submit and moves focus to the first problem, so errors are both perceivable and reachable.
- Data tables. Every table carries a caption as its accessible name and associates header cells with their scope, so relationships are conveyed to assistive technology, not just visually.
- Dialogs. Modal and alert dialogs are built from primitives that manage focus and labeling.
- Visualizations, and their tabular equivalents. The pattern is that a custom chart also offers its data as a table, and several screens implement it. It is not yet universal across the console, and making it so is open work. The documentation does hold itself to the contract without exception: every figure on this site ships an equivalent Markdown table, and color is never the only carrier of meaning.
Enforced in the build
Accessibility has its own continuous-integration workflow, separate from the main build. Five layers run against the console:
| Layer | What it does |
|---|---|
| Lint | eslint-plugin-jsx-a11y on every change |
| Component tests | Every component rendered and checked with axe-core. Roughly 1,570 accessibility test files, more than half of all component tests in the console |
| Contrast matrix | The theme's colour pairs computed and checked against AA ratios |
| Route sweep | Playwright driving axe-core across the console's routes end to end |
| Two-engine page audit | pa11y-ci at WCAG 2 AA with both the axe and HTML CodeSniffer runners, because each finds defects the other misses |
Four ratchets keep it from sliding backwards:
- Coverage. Every new interface component must ship an accessibility test. Components that predate the rule sit in a baseline list that may only shrink: it started at 186 files and is down to 19. A file that gains a test must be removed from the list, so the baseline cannot rot into a permanent excuse.
- Route count. The end-to-end sweep currently covers 28 routes and may never cover fewer, with no route allowed to be skipped. This guard exists because the sweep once silently skipped 26 of its 28 routes.
- Table correctness. Every hand-authored table needs a caption and header scopes. This one is fully converged: its exception list is empty.
- Primitive adoption. Feature code must compose from the accessible shared primitives rather than raw, unlabeled controls.
The ratchets matter more than the raw counts. A test suite tells you where you are; a ratchet tells you which direction you are allowed to move.
None of the five layers is currently a required check. They execute on every change (the page audits weekly) and their results are visible, but a pull request can merge while they are red.
That is deliberate and it is not comfortable. Making the component-test job required today would block every merge, because a small number of components still fail it on the main branch. The sequence is to get main green, then make the job required. Until that happens, the honest description of these layers is continuous measurement with ratchets on the exception lists, not a gate.
The ratchet baselines are the part that genuinely cannot slide: each is a checked-in list that a test compares against, so a regression shows up as a failing test the moment anyone runs the suite.
Known limitations
Stated honestly, because a conformance claim is only as good as its exceptions:
- A small number of de-emphasized text tokens (for example decorative timestamps, version pills, and separators) do not meet AA contrast and are restricted to non-essential, non-interactive decoration.
- Some muted helper text on the dark theme currently measures below AA and is used only for de-emphasized supporting copy.
- The contrast check is not yet a required check on pull requests, and a small number of colour-contrast findings remain open against it.
- The first full screen-reader test cycle has not been completed. Individual flows are tested against assistive technology; a systematic pass across the whole console is not done.
- Tabular equivalents for custom charts are not universal across the console yet.
- No third-party audit, as stated above. A self-assessed conformance report is published; no independent party has attested to it.
The conformance report
For the criterion-by-criterion assessment a procurement process asks for, see the Accessibility Conformance Report, a self-assessed VPAT 2.4 ACR covering WCAG 2.1 AA, WCAG 2.2 AA, Section 508 and EN 301 549, with its evaluation methods and their limits stated up front.
Reporting a barrier
If you encounter an accessibility barrier operating the platform, email accessibility@system9.ai. We aim to acknowledge within one business day and respond substantively within five business days. Fixes are prioritized by severity: a blocking issue before the next release, a major issue within 60 days, and minor issues opportunistically.