What we hold ourselves to, what is automated in CI, and how to tell us when we fall short.
FocusArx targets WCAG 2.2 AA: keyboard-operable controls, accessible names on interactive elements, sufficient contrast, reduced-motion support, and automated axe-core accessibility tests in continuous integration. Barriers should be reported and will be treated as bugs.
WCAG 2.2 Level AA is the target. In practice that means every control reachable and operable from the keyboard, visible focus states, a logical heading order, accessible names on buttons and inputs, and contrast that survives both the dark and light themes.
Animations respect the prefers-reduced-motion setting. The app also has heavy 3D and particle surfaces, which are skipped or simplified when reduced motion is requested or when the device cannot sustain them.
Playwright tests run axe-core against key flows on every change, so regressions in contrast, naming and landmarks are caught before they ship. Automated tooling catches a minority of real barriers, which is why manual testing and user reports still matter more.
The 3D Focus City and some canvas-heavy surfaces are not fully exposed to assistive technology; the underlying data is available in text form elsewhere in the app. We would rather name that than imply complete coverage.
Tell us what you were trying to do, what happened, and which browser and assistive technology you were using. Accessibility reports are treated as bugs, not feature requests.
Last reviewed 2026-08-29.