Accessibility,
stated as it is.

Target

The website and the product consoles target WCAG 2.2 AA . The items below are not aspirations; they are enforced by CI on the current build.

Measured on every build

• Automated accessibility scan: axe runs against 90 server-rendered pages across five frontends. The 70 findings currently on record are held by CI and may only decrease, never grow.
• Contrast is enforced arithmetically: body and link text at 4.5:1 or better (brand text measures 4.67:1 light / 6.25:1 dark), non-text elements such as control boundaries at 3:1 or better (measured 3.66:1 / 4.34:1). The figures are computed from the token source during the build, not written into a comment by hand.
• Keyboard focus is visible, measured in a real browser: each watched control is focused in Chrome and 22 of 22 draw a visible indicator. The ring is opaque; a translucent ring measured below 3:1 and was replaced. This measurement is enforced by the build gate.
• Document language: every page declares lang, which assistive technology uses to choose a pronunciation voice.
• Self-hosted fonts: pages request no third-party font CDN; assets are served from this origin.

What still falls short

The following are known issues, listed rather than hidden. CI records them, so the counts can only fall as they are fixed:

• Heading levels that skip a rank:67 nodes(usually h1 straight to h3).
• Content outside a landmark region:13 nodes.
• A select element with no accessible name:1.
• Progress indicators with no accessible name:2(design lab).
• Routes with no server-rendered HTML, rendering only in the browser:4(3 of them in the customer console).
• Automated testing cannot find every accessibility problem: how a screen reader actually sounds, complex interactions, motion and cognitive load still need human verification.

Feedback

If you hit an accessibility barrier, please tell us through the contact page, including your browser and assistive technology where possible. We will reproduce and fix it.