A Phrase Everybody Knows
You run an accessibility audit. You check success criteria (SC). SC 1.1.1. SC 4.1.2. SC 2.4.7. Findings get tracked, remediated, retested. The conformance statement gets signed. This is how accessibility audits work. It is also, almost without exception, only part of what WCAG requires.
Web Content Accessibility Guidelines (WCAG) 2.2 has five conformance requirements. Meeting all five is what conformance actually means. Most audits check one of them systematically: Requirement 1, which maps to success criteria. The other four receive, at best, a scoping declaration at the start of the engagement and are rarely revisited.
Requirement 4 says: only accessibility-supported ways of using technologies may be relied upon to satisfy success criteria. It has been in WCAG since 2008. The phrase "accessibility-supported" appears in most auditor training. In practice, what it requires is unspecified: which combinations to test, what threshold counts as "supported," who decides.
That gap is not a practitioner failure. The industry's model was never built to surface it.
What It Actually Requires
Two conditions must both be true for a technology to be accessibility-supported. First, users' assistive technology (AT) must support that technology as used. Second, browsers must expose it accessibly through platform accessibility application programming interfaces (APIs).
The key word is "relied upon." WCAG does not prohibit using non-accessibility-supported technologies. It prohibits depending on them to carry accessibility on their own. A non-supported decorative animation differs in conformance consequence from a non-supported form input that is the only path to completing a transaction.
If a technology is not accessibility-supported, the same information and functionality must also be available through a technology that is.
The definition is precise. The problem is not with the definition. It is with what sits behind it.
Three layers separate writing markup from being accessibility-supported. Layer one: markup validity, whether the ARIA usage is correct per ARIA in HTML, which is what validators check. As co-editor Scott O'Hara describes it, that spec "does not define the features of HTML, or of ARIA. Nor does it define how HTML and ARIA map to accessibility APIs." Layer two: browser API exposure, whether the browser correctly maps valid markup to platform accessibility APIs, which is what the HTML Accessibility API Mappings (HTML-AAM) specifies. Layer three: AT interpretation, whether the AT correctly reads what the browser exposes.
"Accessibility-supported" sits entirely at layer three. Most tooling validates layer one. An audit that stops at layer one has not checked WCAG conformance. It has checked markup validity.
What Audits Actually Check
Accessibility audits are, in practice, SC audits. A conformance audit is not the same thing.
An SC audit asks whether specific features work accessibly against a set of success criteria. A conformance audit also asks whether the technologies relied upon to make those features work are actually accessible to the AT users rely on. Those are different questions, and most audit practice asks only the first.
This is not auditor negligence. The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 from 2014 reflected the industry's SC-centric approach rather than challenging it, treating accessibility support as a scoping declaration in Step 1 rather than as an active evaluation target.
This is the audit process working exactly as the industry built it. A finding against SC 4.1.2. ARIA attributes added. Automated checker passes. Finding closed. The SC-centric model emerged from where the profession was: automation-first tooling, legal frameworks that referenced specific criteria, clients who wanted quantifiable pass/fail results, procurement requirements built around SC counts. CR4 requires a qualitative judgment about real-world AT support that does not fit that model. The industry took the path that was operationalizable. The SC finding is resolved. CR4 has never been evaluated. The result is a conformance statement that has never been tested against the requirement it is supposed to reflect.
The WCAG-EM 2.0 Group Note Draft published in February 2026 acknowledges this directly. It restructures Step 4 so that accessibility support and non-interference are discrete, named evaluation steps alongside SC testing, not scoping declarations made at the start and forgotten. Step 1.3 requires defining an accessibility support baseline. Step 2.4 requires identifying technologies relied upon. An evaluator following WCAG-EM 2.0 must check CR4 and Conformance Requirement 5 (CR5) as separate steps.
The direction is right. Three caveats apply. The document is a Group Note Draft, not yet published and not endorsed by W3C. When published, it will carry no normative authority. And it defines the evaluation step without defining the threshold. It tells evaluators to check whether features are accessibility-supported. What "supported enough" means remains with the evaluator.
The Threshold Nobody Defined
CR4 asks authors to determine whether a technology is accessibility-supported for their users. WCAG provides no definition of what "supported" means in quantitative terms. Supported by which AT? How many? Which browser pairings? What percentage of the user base?
No official list exists. No registry. No runtime API answers the question. The AT layer operates at the operating system (OS) level, outside JavaScript's reach. There is no CSS.supports() equivalent for ARIA.
The most structured response to this gap is the ARIA and Assistive Technologies Community Group, launched at the World Wide Web Consortium (W3C) in 2018 and formally connected to the ARIA Authoring Practices Guide (APG). It produces AT interoperability reports for APG patterns across JAWS, NVDA, and macOS VoiceOver, using a Must-Have and Should-Have behavioral taxonomy. Must-Have behaviors are those without which users could be blocked entirely. Should-Have behaviors are those whose absence could impede users. The APG embeds these reports directly into example pages as AT support tables. Testing is automated through an AT Driver specification. This is the closest thing to a threshold definition anywhere in the accessibility ecosystem.
The gap in that coverage is significant. iOS VoiceOver and TalkBack are not in the current test suite. These are not equivalent to their desktop counterparts. iOS VoiceOver uses a gesture-based interaction model with different browsing mode architecture and different ARIA interpretation behavior than macOS VoiceOver. TalkBack has documented implementation gaps across multiple ARIA attributes. For two of the most common real-world AT combinations on mobile devices, no equivalent structured evidence base exists.
Under WCAG's own logic, without established support, those technologies cannot be considered accessibility-supported and cannot be relied upon to satisfy success criteria.
The most common defense of the undefined threshold runs in three directions. First: the vagueness is intentional, preserving flexibility for different deployment contexts. A corporate intranet with a known AT user base has different support obligations than a public consumer website. Second: the threshold is implicitly defined by knowing your users' AT. WCAG says "for users of the site," which places the determination with those who know their audience. Third: the professional community has already built a de facto threshold through the big four test matrix and ARIA-AT.
Each has real force. Each breaks down at a specific point.
The intentional flexibility argument was valid when WCAG was voluntary guidance. It becomes a liability when WCAG is binding law evaluated by third-party auditors. Two auditors applying different self-defined baselines to the same regulated product can reach opposite conformance conclusions and both be following the standard as written. Flexibility without a floor is not a feature in an enforcement context.
The "know your users' AT" argument collapses before it reaches practice. There is no web platform API to detect what AT a user is running. The JavaScript sandbox has no visibility into OS-level assistive technology. Web platform proposals for AT detection have consistently met community resistance: knowing that a user relies on a screen reader could enable serving a degraded experience rather than making the primary one accessible. AT usage is private by design and by community consensus. Knowing your users' AT requires either detection the platform deliberately does not provide, or population-level surveys that are indirect, infrequent, and self-selected. Neither is a reliable basis for compliance decisions.
The de facto standard argument is the strongest of the three. ARIA-AT and the big four matrix do constitute a working threshold in professional practice. But a de facto standard that different practitioners apply differently, that carries no normative authority, and that excludes mobile AT entirely is not functioning as a standard. It is a workaround for a normative gap, not a resolution of it.
The Honest Problem With That Logic
Follow that instruction consistently and the conclusion is uncomfortable: most complex interactive web interfaces would need to be simplified or replaced with less capable alternatives to satisfy CR4 for mobile AT users.
Nobody in the accessibility community actually advocates this. And that collective silence is worth naming directly. CR4 as currently written, applied consistently to mobile AT, produces a requirement most organizations cannot satisfy without downgrading their products. The accessibility community implicitly agrees to look away from this, not because the requirement is wrong in spirit, but because its literal application leads somewhere neither realistic nor honest.
Downgrading is the wrong response for reasons beyond the obvious. If authors systematically built down to current mobile AT capabilities, accessibility would become a genuine constraint on what the web can build. That perception, that accessibility limits capability, is exactly what damages the advancement of the field. It removes pressure on AT vendors to improve their implementations. The web exposing what AT should support is what creates pressure to close the gap. Strip that signal away and the gap stays.
The right response to mobile AT gaps is to build correctly, document known AT vendor failures transparently in your accessibility statement, and report those failures to AT vendors. Treat them as bugs. But to be clear about what this means: there is no graceful degradation mechanism for ARIA the way there is for CSS. There is no runtime API to detect AT support and conditionally apply a fallback. If mobile AT does not implement a feature, users who rely on those combinations are blocked, and no amount of correct authoring changes that. The fix is pressure on the ecosystem, not on the product.
The Chain Behind the Requirement
WCAG holds authors accountable. HTML-AAM uses normative MUST language requiring browsers to map HTML semantics to platform accessibility APIs correctly. The ARIA specification does the same for ARIA attributes. AT vendors do face normative requirements in both the ARIA specification and the Accessible Name and Description Computation (AccName) spec. Both explicitly state that authors, user agents, and assistive technologies MUST follow their normative sections for an implementation to conform.
The problem is that across all versions of ARIA, from 1.0 through 1.2, AT compliance has been explicitly excluded from the Candidate Recommendation testing process. The ARIA CR implementation reports state it directly: "assistive technology behavior will not be tested as a formal part of the Candidate Recommendation process." The stated rationale is that AT behavior is "specific to the particular AT and user and is not specified by WAI-ARIA." That rationale sits in direct tension with the spec itself, which contains normative MUST requirements addressed to AT vendors. The spec says AT MUST comply, then explicitly declines to test whether they do. Normative requirements exist on paper. They have never been verified as a condition of any version of ARIA reaching Recommendation. No law enforces them independently. User Agent Accessibility Guidelines (UAAG) 2.0, which addresses browser accessibility behavior most directly, is a Working Group Note, not a Recommendation. No legislation references it.
Every accessibility law in force holds content publishers accountable. Section 508 in the US and the European Accessibility Act via EN 301 549 in the EU both target organizations that produce and publish content. Browser vendors and AT vendors carry no equivalent legal obligation for accessibility.
A Question Worth Asking Openly
In a LinkedIn exchange responding to the post A Story of Two Documents, Alastair Campbell, co-chair of the WCAG Working Group, shared where WCAG 3.0 is headed: a default "accessibility support set" of specific user agents, with regional regulators able to define their own. A defined baseline that regulators can customize would narrow the gap between authoring guidance and evaluation standard significantly.
Campbell confirmed it will still live in informative documentation, deliberately. Section 508 has referenced WCAG 2.0 for years without updating. Normative technology-specific procedures would lock laws worldwide to outdated requirements. The informative layer's flexibility is a feature given how slowly regulatory adoption cycles move. WCAG 3.0 remains years from becoming a Recommendation, and further still from adoption into law.
Which raises a question worth putting to the community directly: should CR4 be reformed?
Not weakened. Rewritten to be less vague and more honest about what it actually requires. The current requirement defines no threshold, no mandatory baseline, no decision rule. An honest reading applied to mobile AT produces a requirement most organizations cannot satisfy without either downgrading their products or excluding mobile users from scope. That is not a sustainable position, and it is not an honest one either.
A more explicit CR4, one that names a minimum AT baseline, defines what "supported" means in behavioral terms, and removes the threshold from individual judgment, would give authors, evaluators, and AT vendors something concrete to work against. A platform-based minimum is the only honest answer available. Defining the threshold through user knowledge is off the table: there is no mechanism to detect AT usage, and when Apple proposed one, the accessibility community rejected it on principle as potentially discriminatory. AT usage is private by design and by community consensus. What remains is a testable, platform-based definition. A reasonable starting point: a technology must be supported on at least two distinct OS platforms, with specific AT and browser combinations verified against behavioral assertions. Deterministic: you can test it. Realistic: the ARIA-AT project already produces exactly this evidence for the major desktop platforms. Substantial: it covers the majority of current AT users without demanding support for platforms where the AT ecosystem has not yet caught up.
That framing also resolves the mobile problem honestly. It does not exclude mobile AT from future versions of the baseline. It acknowledges where the evidence base currently is and builds from there, rather than either pretending mobile AT is covered or demanding support nobody can yet provide.
WCAG 3.0's default accessibility support set is a step in that direction. Whether it goes far enough, and whether it should carry normative rather than informative weight, is worth asking openly.
The ARIA-AT reports are building the evidence base that baseline would need. The question is whether the profession is ready to use it.
Practitioners are the right people to carry this argument forward. Not because they created the gap, but because they live with it. The conformance statement that does not fully cover mobile users. The SC finding closed while the underlying AT support question stays open. The audit scope that quietly excludes combinations that would reveal failures nobody knows how to fix. These are not personal oversights. They are the reasonable accommodations practitioners have made to an impossible demand: a requirement the standard made load-bearing without making actionable.
Naming that gap explicitly, in audit reports, in accessibility statements, in client conversations about what conformance actually means, is where the reform starts. WCAG-EM 2.0 is already moving in this direction. The question is whether the profession moves with it.