Compliance theatre in accessibility leaves users behind

At a glance

What this is: This article argues that automated accessibility compliance can miss major usability failures because scanners cannot evaluate context, workflow logic, or assistive-technology behavior.

Why it matters: For identity and security practitioners, the lesson is that governance checks must test real user outcomes, because technically passing controls can still leave critical journeys unusable for human users.

By the numbers:

• Automated accessibility tools can detect only 30% to 50% of WCAG violations, according to Arxan Technologies.
• In the UK, the spending power of disabled households is estimated at over £274 billion, showing the commercial impact of inaccessible journeys.
• In the US, disabled households represent nearly $21 billion in spending power, which makes accessibility failures a direct business risk.

👉 Read Arxan Technologies' analysis of the accessibility gap and compliance limits

Context

Accessibility compliance often fails when teams confuse a passing scan with a usable experience. A system can satisfy code-level checks and still break for a real person using a screen reader, keyboard navigation, or a mobile assistive technology stack. The same governance gap appears in identity programmes when policy evidence is treated as proof of functional control.

The primary issue is not the presence of automation, but its limits. Automated checks cannot judge context, interactive states, or whether a workflow actually supports the intended user. That makes real-user validation a necessary control layer, and the article's starting position is common in mature product teams but still uncommon in organisations that rely on release gates alone.

Key questions

Q: How should teams validate accessibility beyond automated scan results?

A: Teams should combine automated scanning with manual testing of critical journeys using the assistive technologies real users rely on. That means checking keyboard navigation, focus order, alerts, and state changes in live flows, then confirming that users can complete the task without workarounds. Pass rates are useful, but task completion is the real control signal.

Q: Why do automated accessibility checks miss so many real problems?

A: Automated checks read code, not context. They can confirm that elements exist, but they cannot determine whether a label is meaningful, whether a modal traps focus, or whether an error message is announced properly. Those failures only appear when a person interacts with the system, which is why human validation remains essential.

Q: What should security and identity teams learn from accessibility failures?

A: They should learn that evidence of compliance is not the same as evidence of function. In identity journeys, a technically correct control can still block access, frustrate recovery, or create support load if real users cannot complete the workflow. Governance should therefore test outcomes, not only policy conformance.

Q: How can organisations know if accessibility controls are actually working?

A: Look for task success rate, support ticket trends, and repeated failure points in high-value workflows. If users still abandon key journeys, rely on workarounds, or report keyboard and screen-reader issues, the controls are not effective. Accessibility assurance should prove usability under real operating conditions, not just pass an audit.

Technical breakdown

Why automated accessibility scans miss real usability failures

Automated scanners inspect markup and code patterns, but they do not understand user intent, assistive-technology behavior, or the way focus moves through a live interface. They can verify that an element exists, yet still miss a broken keyboard trap, a silent alert, or a misleading alt label. This is why scan results often overstate functional accessibility. The control gap is analogous to relying on policy compliance without testing whether the control works in practice.

Practical implication: treat automated scanning as a baseline check, not evidence that user journeys are actually accessible.

Dynamic states, focus management, and ARIA live regions

Many accessibility failures appear only when an application changes state. Single-page apps, modals, notifications, and error messages can all behave correctly in code while remaining invisible to screen readers if ARIA live regions and keyboard focus are not managed properly. These are runtime interaction problems, not static code problems. Teams therefore need tests that exercise transitions, not just page loads. The technical issue is that accessibility often fails in the gap between rendered UI and interactive state.

Practical implication: validate focus order, alerts, and modal behavior in live sessions using the assistive tools customers actually use.

Task success rate is a better control signal than pass rates

A pass rate tells you how many checks were satisfied, but task success rate tells you whether a person could complete a real journey. That distinction matters because accessibility is functional governance, not merely code hygiene. If a user cannot check balance, submit a form, or close a dialog efficiently, the control has failed even if the scan was green. For identity and verification flows, this same principle applies to onboarding, recovery, and authentication journeys.

Practical implication: measure whether users can complete critical tasks, not just whether automated tests return a green result.

NHI Mgmt Group analysis

Accessibility compliance is a governance signal, not an outcome. A green scan can show that code-level rules were satisfied, but it does not prove that a person can complete the task. That distinction matters in identity-heavy journeys such as login, account recovery, and verification, where functional failure creates operational exclusion even without a security incident. The right control model is evidence of use, not evidence of inspection.

Real-user validation is the missing assurance layer in many digital programmes. Manual testing with assistive technologies and native user testing expose failure modes scanners cannot see, especially in keyboard traps, focus loss, and dynamic content. This is the same pattern identity teams face when policy attestation is confused with real entitlement behavior. The named concept here is verification trust gap: organisations trust automated proof more than actual user experience, which weakens governance. Practitioners should validate the journey, not just the rule set.

Accessibility is part of identity and trust governance wherever users must complete critical workflows. If a disabled user cannot authenticate, recover access, or complete a regulated transaction, the organisation has failed a trust obligation even if its compliance dashboard looks clean. That makes accessibility relevant to IAM, verification, and customer assurance programmes, not just front-end teams. The practical conclusion is straightforward: human validation belongs in governance, not as an optional UX review.

Shift-left testing only works when it is paired with shift-right validation. Bringing QA into design and development helps catch structural barriers earlier, but runtime testing is still needed to confirm that the delivered experience works under real conditions. In practice, that means accessibility assurance should sit alongside release approval, not after it. Practitioners should treat accessibility as continuous assurance across the product lifecycle.

What this signals

The broader lesson for security programmes is that control assurance must be outcome-based, not inspection-based. When the verification model only proves that a check ran, it can miss the functional failure that matters to users and to the business. That same pattern appears in IAM, where access review evidence can look complete while critical journeys still fail in practice.

Evidence-to-experience gap: organisations increasingly accumulate proof of testing, but not proof of usability. That gap will matter more as workflows span identity verification, customer onboarding, and regulated service delivery. Practitioners should expect accessibility assurance to become part of broader trust and governance reporting, especially where user exclusion creates operational or legal risk.

For practitioners

• Embed assistive-technology testing into release gates Require manual verification of critical user journeys with tools such as screen readers and keyboard navigation before release approval. Use the test results as release evidence, not as a post-release cleanup task.
• Measure task success instead of scan pass rates Track whether users can complete high-value journeys such as login, balance checks, checkout, and recovery. Replace generic compliance dashboards with outcome-based metrics that show whether the interface works for real users.
• Review dynamic states as part of QA Test modal dialogs, error alerts, focus order, and state changes in live sessions because those conditions often fail after the page loads. Validate keyboard traps and live-region behavior on the exact flows users depend on.
• Tie accessibility checks to identity journeys Prioritise onboarding, authentication, recovery, and verification flows where inaccessible design can block access or create support burden. Treat those paths as governance-critical rather than cosmetic UI work.

Key takeaways

• Accessibility compliance can be technically correct and still functionally broken for real users.
• Automation is a baseline control, but task success testing is the stronger indicator of usable product governance.
• Identity and trust journeys should be validated with real users because policy evidence alone does not prove access works.

Key terms

• Accessibility Gap: The gap between passing technical accessibility checks and delivering a genuinely usable experience. It appears when code-level compliance does not translate into successful interaction for people using screen readers, keyboard navigation, or other assistive technologies.
• Attack Success Rate: Attack success rate is the percentage of test attempts in which an injected adversarial scenario achieved its intended effect. For agentic systems, it helps distinguish a one-off anomaly from a repeatable workflow weakness that requires governance action.
• Assistive Technology: Software or hardware that helps users interact with digital systems, including screen readers, voice input, switch controls, and keyboard navigation aids. In governance terms, it is part of the operating environment a product must support if access is to be considered real.

What's in the full article

Arxan Technologies' full post covers the operational detail this analysis intentionally leaves for the source:

• Specific examples of accessibility failures in screen-reader and keyboard-driven journeys
• The testing workflow it recommends for QA teams working alongside developers
• Practical guidance on using automated tools as a baseline rather than a final gate
• How to measure task success rate instead of relying on scan-only compliance

👉 Arxan Technologies' full post explains the QA, testing, and user-validation details behind this accessibility gap

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security practitioners build stronger lifecycle controls across identity and access programmes.