Accessibility Testing

Two facts shape how this should be architected. Accessibility is a legal requirement in a growing number of jurisdictions and a contractual one in most public-sector procurement. And automated tooling detects roughly a third of the issues in the standards — enough to be valuable, nowhere near enough to constitute compliance, and dangerous when a clean automated report is read as one.

What automation catches well: missing alternative text, insufficient colour contrast, absent form labels, invalid ARIA usage, missing document structure. What it cannot judge: whether alternative text is meaningful, whether focus order is logical, whether a custom component behaves sensibly with a screen reader, whether an error message actually explains the problem.

The architectural leverage sits earlier than testing. Accessible component libraries and design system primitives make the correct behaviour the default across every product built on them, which is a far better investment than auditing each application afterwards. The single most common source of failures is a custom interactive control rebuilt from generic elements without the keyboard handling and semantics the native one had.

Testing practice that works: automated checks in the pipeline, keyboard-only navigation as a manual step in review, and periodic testing with real assistive technology and, where possible, real users.