WCAG is really two documents. One is normative: the success criteria, the conformance requirements, the thing that became law in dozens of countries. The other is everything else: the Understanding documents, the Techniques, the supporting specs that tell you what the success criteria actually mean in practice. One has the force of regulation. The other is advisory.
This was a deliberate design choice, and for most of WCAG's life it was the right one. But the distance between the two documents has grown into a gap, and the gap has consequences that are worth examining.
Here is a simple question. You are auditing a web page. You encounter an <input type="image">. You need to determine whether it has an accessible name, per SC 4.1.2. Where do you look?
Not what to look for. Where. Which document. Which specification. Which source of truth.
WCAG does not say.
How two documents became one standard
To understand why the gap exists, you have to go back to 1999.
WCAG 1.0 already had the split. There was a normative guidelines document and a separate, non-normative Techniques document with HTML and CSS examples. But the normative document itself was technology-specific. It named HTML elements, referenced markup constructs directly. If you were building an HTML page, the guidelines alone told you most of what you needed to know. The Techniques document was helpful, but supplementary.
Then the web diversified. Flash, Java applets, PDF, eventually mobile. A normative standard bound to HTML could not keep up.
WCAG 2.0, published in 2008, made a deliberate architectural bet: make the normative layer technology-agnostic. Success criteria would describe outcomes rather than implementations. All technology-specific guidance would live in the non-normative layer, in Techniques and Understanding documents, easier to update without reopening the standard itself. The two documents still existed, but their relationship changed. The non-normative layer went from supplementary to essential.
This was a smart bet. WCAG 2.0 was designed to apply broadly to different web technologies now and in the future, and it succeeded. The standard has survived nearly two decades, adapted to technologies its authors could not have anticipated, and achieved something rare in standards work: genuine global adoption.
But the bet had a cost. The non-normative layer, the part that tells you how to meet the criteria in a specific technology, carries no formal authority. It is advisory. Useful, often good, but not binding.
For a voluntary best-practice document, that was fine. The flexibility was the point.
When one document became law
Then governments discovered WCAG.
Governments worldwide adopted WCAG as the technical basis for binding law. Section 508 in the United States incorporated WCAG 2.0. The European Accessibility Act, enforced from June 2025, references EN 301 549, which incorporates WCAG 2.1. Australia, Canada, and others built their own frameworks around it. WCAG 2.2 is now an ISO standard: ISO/IEC 40500:2025.
A standard designed as voluntary guidance became the technical basis for binding law across the world. But only one half of it. The normative layer, the success criteria, has the force of regulation. The non-normative layer, the part that tells you how to check compliance, does not.
An auditor enforcing the EAA technically needs to determine whether content meets SC 4.1.2. But the documents that would tell them how to evaluate that, for a specific HTML element, are all non-normative. The regulatory framework inherited WCAG's architectural split, and with it, a gap the architecture was never designed to bear.
And regulatory adoption did something else: it locked the architecture in place. Because governments reference specific WCAG versions, every subsequent version must be backwards compatible. WCAG 2.1 could only add success criteria, not restructure. WCAG 2.2 the same, its requirements explicitly constrained by structural requirements inherited from WCAG 2.0. Even the removal of a single obsolete SC, 4.1.1 Parsing, was unprecedented and required extensive justification. The gap between the two documents cannot be closed within the WCAG 2.x line, because the architecture that created it is now load-bearing.
WCAG 3.0 is the intended escape: a different structure, a different conformance model, a broader scope. It is also years from becoming a Recommendation, and further still from being adopted into law. In the meantime, the two documents remain as they are.
The dependency chain WCAG doesn't name
Let's trace what happens when you try to evaluate SC 4.1.2 on an HTML page.
SC 4.1.2 says the name and role of user interface components must be "programmatically determined." To check this, you need to know what the correct name is. But WCAG does not tell you how to compute it.
The WAI-ARIA 1.2 specification, a W3C Recommendation, defines the general framework for accessible names. It references the Accessible Name and Description Computation (AccName), which provides the algorithm. AccName 1.1 is a W3C Recommendation. AccName 1.2, the current working version, is a Working Draft.
But AccName is a general-purpose algorithm. For HTML specifically, it defers to the host language. It says, in effect: for HTML elements, consult HTML Accessibility API Mappings (HTML-AAM). HTML-AAM provides the element-specific steps: for this element, the accessible name comes from these sources, in this order.
HTML-AAM is a Working Draft. Its status section reads: "publication as a Working Draft does not imply endorsement by W3C." It is, by the W3C's own description, a work in progress.
And WCAG, the ISO standard that underpins legislation in dozens of countries, does not normatively reference any of these documents. Not ARIA. Not AccName. Not HTML-AAM. The entire evaluation chain for SC 4.1.2 on an HTML page hangs on documents WCAG does not formally require you to consult.
When the map disagrees with the territory
Now, back to that <input type="image">.
The HTML-AAM accessible name computation for this element lists the following steps, in order: aria-labelledby, aria-label, alt attribute, title attribute, and finally a localized "Submit Query" string. The value attribute is not listed.
But on Windows, in Chromium-based browsers, with both NVDA and JAWS, the value attribute is computed as the accessible name. Browsers do something the spec does not document. This is not a hypothetical. It is documented in the W3C's own issue tracker, where contributors tested implementations and found that "button type inputs: value maps to accessible name (and is added as visible text content)."
So an auditor following HTML-AAM's documented steps concludes: no accessible name from value. An auditor checking the browser's accessibility tree concludes: accessible name present, from value. Both are acting rationally. Both are following a defensible procedure. They reach opposite conclusions.
WCAG is silent on which one is right.
And this is not an isolated edge case. Issue #304 on the HTML-AAM repository notes inconsistent language across the computation steps, with contributors observing "no consistent language regarding these steps." Issue #414 records the ACT Rules Community Group raising concerns about how "technologies (both browsers and AT) render/expose inconsistently elements that support the alt attribute." The ACT Rule for image button accessible name itself documents that "some user agents and assistive technologies combinations stop at the first existing [name], even if empty," contrary to what the spec describes.
The people writing the specs know about these problems. They are working on them. The problems are not secret. They are structural.
The two-implementation irony
There is a small irony here worth savoring.
The W3C's own process for advancing a specification to Recommendation status has a notable requirement: the Working Group should be able to demonstrate two interoperable implementations of each feature. Features that lack two implementations during the Candidate Recommendation phase are expected to be dropped. This is a good requirement. It ensures that specs describe things browsers actually do, consistently.
HTML and CSS have met this bar. They are mature, well-implemented Recommendations. But the accessibility-relevant behaviors within those specs, how a given HTML element's accessible name is computed, how that name is exposed to assistive technology, do not always receive the same consistency verification. The two-implementation gate ensures that border-radius renders the same across browsers. It does not ensure that the accessible name for <input type="image"> is computed the same across browsers.
And when browsers do converge on a behavior that no spec documents, as with value-as-accessible-name, that convergence has no normative standing. WCAG does not recognize it. HTML-AAM has not codified it. It is a de facto standard with no de jure existence.
ACT Rules: the almost-solution
The Accessibility Conformance Testing (ACT) Rules are the closest thing the ecosystem has to deterministic test procedures for WCAG. They are formalized, technology-specific, and come with test cases. They are exactly what you would build if you wanted to close the gap between "what WCAG requires" and "how you check it."
They are also, explicitly and repeatedly, informative. Not required for conformance. Not normatively referenced by WCAG. Content can fail an ACT Rule and still conform to WCAG. Content can pass all relevant ACT Rules and still fail a success criterion, because ACT Rules typically check specific aspects of WCAG success criteria rather than the criterion in its entirety.
ACT Rules are the right idea at the wrong level of authority. They demonstrate that the W3C recognizes the problem. They also demonstrate that the solution has been kept deliberately non-binding, preserving the flexibility of the original architecture while leaving the compliance gap unresolved.
What could be different
I want to be clear about what I am not saying. I am not saying WCAG is poorly made. The technology-agnostic architecture was the right call in 2008, and it has proven remarkably durable. I am not saying the W3C has been negligent. The constellation of supporting specs, ARIA, AccName, HTML-AAM, ACT Rules, represents an enormous, largely volunteer-driven effort to fill the gap. And I am not saying there is an easy fix. Normatively binding WCAG to specific versions of HTML-AAM risks reintroducing the brittleness that sank WCAG 1.0.
But the current state has real costs. Auditors reach different conclusions on the same component. Automated tools disagree because they consult different sources. Legal compliance depends on documents that carry no legal authority. And practitioners are expected to independently discover, select, and navigate a chain of specifications that WCAG itself does not name.
Something directional is possible without reopening the entire architecture. WCAG could normatively reference the evaluation procedures for its own success criteria, or at minimum, name the documents in its dependency chain and describe their relationship to conformance. Not embedding technology-specific details in the SCs themselves, but creating a formal bridge between "what must be true" and "how you determine whether it is true." The ACT Rules effort already points in this direction. The question is whether the final step, giving evaluation procedures normative standing, is worth taking.
There is also a question the W3C could usefully answer about implementation consensus. When all major browsers converge on an accessibility behavior that no spec documents, what is the status of that behavior? Should specs track implementation consensus? If so, through what process? These are not new questions in standards work. The W3C's own two-implementation requirement for Recommendation status acknowledges that specs should reflect what browsers actually do. Extending that principle to accessibility-relevant behaviors seems natural.
A coda: where this is headed
Everything above concerns web content: HTML, CSS, the browser, the accessibility tree. WCAG's home territory.
But WCAG is already being applied far beyond it. The European Accessibility Act covers self-service terminals. EN 301 549 puts native mobile apps and embedded devices in scope. Consider a touchscreen coffee machine. SC 2.1.1 requires keyboard operability. The machine has no keyboard. The success criterion is not hard to apply here. It is incoherent on the platform.
If WCAG cannot formalize its relationship to HTML and CSS, its own home ground, the problem only compounds as scope expands to platforms it was never designed for.
An open question
I began with a simple question: you have an <input type="image">, and you need to check SC 4.1.2. Where do you look?
I hope I have shown that the answer is not simple, and that the difficulty is not about individual competence. The difficulty is structural. WCAG is two documents, one with the force of law and one without, and the distance between them has grown wider than the architecture was designed to bear.
This is not a crisis. It is an architectural debt, accumulated over two decades, in a standard that has done more for digital accessibility than any other single document. Acknowledging it is not disrespect. It is the kind of attention the standard deserves.