Comments on the current exploratory WCAG 3 conformance proposal and the Working Group’s related Conformance issue record.

AFixt appreciates the substantial effort the Accessibility Guidelines Working Group has invested in developing WCAG 3 and, in particular, in reconsidering limitations that have become apparent through more than two-and-a-half decades of experience with WCAG 1 and WCAG 2. The ambition behind WCAG 3 is appropriate. Modern digital products are not well represented by a model concerned principally with static web pages and accessibility cannot always be reduced to deterministic tests. Some accessibility barriers have substantially greater consequences than others. People with cognitive and learning disabilities, among others, have needs that have historically been difficult to accommodate within WCAG’s conventional success-criterion model. These are legitimate problems, and WCAG 3 is right to address them and, in turn, address how conformance is claimed.

Our principal concern is with the architecture now being explored for conformance. The draft is trying to accommodate several real problems at once: WCAG 2’s all-or-nothing character, the approaches of measurement, the uneven consequences of different failures, the difficulty of expressing some accessibility needs as deterministic tests, and the value of organizational practices that cannot be observed simply by inspecting a page. Those problems do not, however, all belong inside the conformance determination. The present proposal places normative requirements, supplemental achievement, organizational assertions, functional-performance coverage, and graduated levels into the same mechanism. In our view, that asks the word conformance to carry more meaning than it can carry reliably. [WCAG 3: Conformance]

This distinction is not semantic. WCAG is used in legislation, regulation, procurement, contracts, litigation, accessibility policies, product requirements, and third-party assessments throughout the world. A future WCAG conformance model must therefore do more than encourage accessibility improvement. It must permit a regulator, purchaser, organization, evaluator, court, and person with a disability to understand substantially the same thing when someone says that a product “conforms.”

There is no need to choose between the comparatively rigid structure of WCAG 2 and a richer account of accessibility. WCAG 3 can report considerably more than WCAG 2 reports now. It can recognize enhanced accessibility, disclose the basis and confidence of an evaluation, identify the severity of failures, and give meaningful credit to mature accessibility practices. What should not be lost in that expansion is a stable answer to the threshold question: did the subject of the claim satisfy the applicable accessibility requirements?

The meaning of conformance should remain clear

The current draft describes Core Requirements as requirements that “must be met in order to conform.” It describes Supplemental Requirements as requirements that build upon the core set and Assertions as documented statements concerning accessibility practices followed by an organization. The proposed Bronze level, however, requires all Core Requirements plus an as-yet-undetermined portion of Supplemental Requirements and Assertions within each functional performance statement. Silver and Gold require progressively larger portions. [WCAG 3: Conformance]

This is an unusual conception of conformance. International conformity-assessment practice provides a useful comparison. ISO conformity-assessment materials frame conformity assessment around demonstrating whether specified requirements are fulfilled, while ISO/IEC 17029 addresses general principles and requirements for validation and verification bodies. [ISO: Conformity Assessment] [ISO/IEC 17029] This does not mean WCAG must adopt ISO terminology or procedures wholesale, nor does it mean every accessibility requirement must be reducible to a machine-testable proposition. It does illustrate an important principle: a conformity decision ordinarily answers whether the applicable requirements have been fulfilled. Other measurements may describe how well an organization performs, how confident an assessor is, or how mature the organization’s processes are, but those measurements do not ordinarily redefine an unmet requirement as met.

The current WCAG 3 model risks doing exactly that. It combines mandatory requirements, additional requirements, organizational assertions, functional categories, and graduated achievement into a single Bronze/Silver/Gold construct. This makes it increasingly difficult to determine what a conformance claim actually communicates. [WCAG 3: Conformance]

The Working Group’s own issue history demonstrates that this is not a hypothetical concern. SiteImprove raised the difficulty of producing reliable and reproducible conformance results. UsableNet emphasized the legal and practical importance of conformance claims. WilcoFiers asked whether test coverage itself should become part of conformance. Kate Kalcevich considered using severity in determining conformance levels. Sydney Coleman raised questions about how Assertions fit into the model.  Lisa Seeman challenged the distinction between Core, Supplemental, and Assertion provisions from an equity perspective. These are not isolated editorial questions. Collectively, they indicate that the model is being asked to represent several fundamentally different kinds of information, much of which are wholly inappropriate for claiming conformance. That history points toward a need to separate these functions rather than shoehorning them into an elaborate conformance formula.

Conformance should not be compensatory

The most important principle we urge the Working Group to adopt is that minimum accessibility conformance should be non-compensatory. An accessibility success in one area should not erase an accessibility failure in another. This matters particularly because accessibility concerns the ability of individuals with disabilities to perceive, understand, operate, and interact with digital products and services. Users do not experience an aggregate accessibility score. They experience either success or failure in using a digital system.

Consider an online banking service that performs exceptionally well for users with low vision, users who are Deaf or hard of hearing, and users with certain motor disabilities, but whose authentication process cannot be completed by a blind screen-reader user. The fact that the bank performs well for other disability groups does not mitigate the complete exclusion experienced by the blind customer. Nor would ten accessibility enhancements elsewhere in the application make that authentication barrier less exclusionary. The same is true even within a single functional category. Excellent heading structure does not compensate for an inability to make a purchase. Accessibility provisions are not necessarily fungible merely because they benefit people who share a functional limitation.

The current draft attempts to address this concern by requiring some Supplemental Requirements and Assertions “within each functional performance statement.” [WCAG 3: Conformance] We recognize the intent and consider the use of functional performance statements an important improvement in WCAG 3. However, distributing points or requirements across functional categories reduces the compensatory problem without resolving it. Requirements within a functional category are no more inherently interchangeable than requirements across functional categories.

We therefore recommend that WCAG distinguish a minimum accessibility floor from enhanced accessibility performance. Every applicable minimum requirement within the claimed scope should be satisfied for conformance. Bronze, Silver, and Gold could then serve a valuable purpose by measuring accessibility achievements beyond that floor. This would preserve the Working Group’s goal of recognizing accessibility beyond minimum compliance without allowing enhanced performance to compensate for a failure of a minimum requirement.

Difficulty and expense must not determine whether an accessibility requirement is normative

We have particularly serious concerns with the current definition of Supplemental Requirements. The draft states that this category can include “requirements that are currently more difficult or expensive to implement.” [WCAG 3: Conformance]

We recommend removing this distinction. Whether an accessibility requirement is difficult or expensive to implement does not tell us whether it is necessary for a person with a disability to use a product. Implementation difficulty describes the provider’s circumstances. Accessibility describes the user’s ability to obtain access. These are different questions.

The distinction is especially important in the context of civil-rights and accessibility law. Under the United States Department of Justice’s Title II web and mobile accessibility rule, covered public entities must ensure that covered web content and mobile applications are readily accessible to and usable by individuals with disabilities and, subject to specified exceptions, comply with WCAG 2.1 Level A and AA. The regulation separately recognizes fundamental alteration and undue financial and administrative burdens. [DOJ Title II Web Rule] The legal structure does not redefine an accessibility requirement as less necessary because satisfying it is expensive. Instead, it establishes the accessibility obligation and separately provides a defense under defined circumstances.

European law exhibits the same conceptual structure. Article 4 of the Web Accessibility Directive establishes accessibility requirements, while Article 5 separately addresses disproportionate burden and expressly directs consideration of matters including the size and resources of the public-sector body and the estimated costs and benefits. [Directive (EU) 2016/2102] The European Accessibility Act similarly establishes accessibility requirements and then separately provides, in Article 14, for fundamental alteration and disproportionate burden, including an assessment and documentation obligation. [Directive (EU) 2019/882]

That separation is important because the technical question of what is required for access is not the same question as whether a particular entity may be excused from satisfying a requirement in particular circumstances. WCAG should not inadvertently embed an affordability defense into the technical definition of accessibility by categorizing necessary accessibility provisions as Supplemental because they are difficult or expensive. Doing so would invert the normal relationship between a right and an exception to that right.

This concern becomes even more significant when considered alongside Lisa Seeman’s comments, which specifically asks the Working Group to revise the Core/Supplemental distinction to make WCAG 3 more equitable. Some disability-related needs are intrinsically harder to express through deterministic technical requirements than others. If difficulty of testing or implementation contributes to a provision becoming Supplemental, WCAG risks creating a structural hierarchy in which needs that are easiest for standards developers and automated tools to formalize receive stronger normative protection than needs that are difficult to measure.

That would be the wrong result. Difficulty of measurement is a property of the measurement system, not evidence that the human need being measured is less important. In essence this tells people with certain types of disabilities that their needs are not as important as others because meeting their needs are more difficult to measure.

Assertions should measure assurance and maturity, not substitute for accessible outcomes

AFixt supports the Working Group’s interest in organizational practices. WCAG 2 says comparatively little about the processes necessary to create and maintain accessible products, despite extensive practical evidence that sustainable accessibility depends upon governance, procurement, training, design systems, user research, testing, quality assurance, defect management, monitoring, and remediation.

Assertions can provide valuable information about those practices. The current draft includes Assertions within the conformance architecture. [WCAG 3: Conformance] Sydney Coleman demonstrates, however, that substantial uncertainty remains concerning the role and documentation of Assertions, while Lisa Seeman raises the possibility that some Assertions should themselves become Core or Supplemental. We recommend a different architecture. Assertions should primarily describe accessibility assurance and organizational maturity, while requirements should describe accessible outcomes.

A company can truthfully assert that it performed usability testing with people with disabilities and still release an inaccessible product. They can also maintain an excellent accessibility style guide while teams fail to follow it. They can provide annual accessibility training while its checkout remains unusable. Conversely, a small organization can produce an accessible product without possessing the formal governance apparatus of a multinational enterprise.

Process matters because good process increases the probability of good outcomes and makes those outcomes more sustainable, but the process is not itself the outcome. This distinction is familiar in other compliance disciplines. Having a cybersecurity policy does not establish that a system contains no exploitable vulnerability. Having a quality-management procedure does not demonstrate that every manufactured item satisfies its specification. Having an anti-discrimination policy does not demonstrate that discrimination did not occur. Process controls are evidence about the organization’s management of the program; product testing is evidence about the product.

Accordingly, Assertions should not become a mechanism by which an organization can compensate for failures of product-level accessibility requirements. If an accessibility need cannot currently be assessed through a simple deterministic test, the answer should not be to convert the underlying user need into an organizational assertion. WCAG should define the normative user outcome and permit appropriate forms of evidence to demonstrate that outcome. The inability to devise a convenient deterministic test does not make a user’s accessibility need optional.

Sampling should affect confidence in a conformance conclusion, not the underlying accessibility obligation

Sampling is one of the clearest examples of a problem being addressed at the wrong conceptual layer.

ITIC correctly identifies representative sampling as important for large and complex sites. Comments in issue #509 similarly argue that WCAG 3 needs a workable sampling methodology for very large systems. Kathy Eng provides useful sampling concepts derived from Trusted Tester practices, including consideration of content types, templates, high-use functionality, user roles, critical paths, changed content, and previously failing material. Wilco Fiers goes further by suggesting conformance claims for pages that have not been completely tested.  AFixt agrees emphatically that exhaustive manual testing is not a realistic prerequisite for assessing every large digital system. But, we disagree with the inference that this requires redefining which portions of the system are expected to conform.

The more useful way to frame sampling is as a question about evidence: how much evidence, and what kind of evidence, is sufficient to support a conclusion about a larger conformance scope? For example, numerous bodies (such as UL) and physical product manufacturers frequently use statistical sampling. Their use of statistical sampling does not thereby cause them to declare that only the sampled products satisfy the manufacturing specification. Sampling provides evidence from which an inference about a larger population is made. The same principle should apply to digital accessibility. The claimed scope should be expected to satisfy the applicable accessibility requirements; representative evaluation provides evidence supporting the conclusion that it does.

This distinction permits WCAG 3 to be both rigorous and practical. A conformance report could identify the population represented by the claim, the sample that was examined, the sampling method, features and components included, known limitations, and confidence associated with the conclusion. A known failure discovered anywhere within the claimed scope remains a nonconformity. The fact that portions of the population were not individually inspected does not convert them into exemptions.

We caution against simplistic numerical sampling rules. Testing five percent of a million-page site is plainly impractical, but testing ten randomly selected pages may be equally meaningless. Modern digital systems are heterogeneous. Sampling should therefore be stratified and risk-based, considering templates, reusable components, content types, technologies, roles, states, high-volume functions, critical interactions, dynamic variations, localization, newly changed areas, and historically problematic areas. Statistical methods can be incorporated where appropriate, but statistically frequent content is not necessarily the content presenting the greatest accessibility or civil-rights risk.

Automated testing must not become a separate accessibility conformance level

ITIC proposes an automated-testing compliance level, motivated by the scalability of automated testing across very large collections of pages. We understand the operational motivation but strongly oppose characterizing an automated-only result as accessibility conformance.

Automated accessibility testing is useful precisely because it can evaluate certain conditions rapidly, consistently, and at enormous scale. Its limitation is that the absence of an automatically detected failure does not establish that an accessibility requirement has been satisfied when the relevant condition requires contextual or human judgment. A machine can frequently determine that an image lacks an accessible name. It cannot infer from the presence of an accessible name that the alternative conveys the purpose or equivalent information of every image. Similar limitations exist throughout automated testing.

Consequently, an automated-only “conformance” level would risk institutionalizing a logical error: treating absence of machine-detectable evidence of failure as evidence of accessibility. WCAG 3 could instead define a standardized automated-testing status, machine-testable coverage measure, or continuous-monitoring result. Such information would be extremely useful, particularly in large development environments. It should simply not be confused with a WCAG conformance determination.

Severity is important, but it should not convert known failures into conformity

AFixt likewise supports incorporating severity into WCAG 3, but not as a mechanism through which known accessibility failures cease to affect conformance. Kate Kalcevich considers a model in which Bronze might permit lower-severity problems while prohibiting high or critical problems, with stricter levels progressively excluding additional severity categories. This approach would be useful as a risk-management system, but it creates significant problems as a conformity system.

Severity answers a different question from conformance. Conformance asks whether a requirement is satisfied. Severity asks how consequential a failure is. The distinction is important because accessibility severity is highly contextual. A defect may inconvenience many users slightly while completely excluding a smaller population. Frequency, prevalence, and aggregate user impact must not transform complete exclusion of an identifiable group into a “minor” accessibility problem.

Severity should therefore inform remediation priority, risk reporting, escalation, service-level objectives, and perhaps enhanced accessibility measurements. It should not make an unmet minimum accessibility requirement conforming. WCAG 3 would be substantially more useful if an evaluation could say that a product does not conform because of three identified nonconformities while simultaneously communicating that one is critical and two are minor. That preserves both pieces of information rather than forcing severity and conformity into the same result.

Scope must not become a mechanism for manufacturing conformance

WCAG 3 appropriately recognizes that modern digital products cannot be understood exclusively as collections of static web pages. Wilco Fiers calls for a conformance model capable of addressing complete websites and web applications. Intopia examines processes and the difficulty of defining where one process ends and another begins. We strongly support this direction.

However, scope creates its own risk. If the claimant has unrestricted discretion to define a conformance scope, a formally accurate claim can nevertheless become materially misleading. An organization could conceivably test its homepage, contact page, and accessibility statement while excluding the application functionality that customers actually use, then publish a narrowly worded conformance claim that many readers would reasonably interpret more broadly.

Sailesh Panchang illustrates a related concern by discussing whether portions of a view outside a task or process might be excluded from lower-level conformance. We do not support such exclusions as a general rule. A footer, complementary region, secondary navigation area, or other content outside the principal task can contain important information or functionality. The fact that content is peripheral to one task does not make it irrelevant to users with disabilities. For example, web page footers often contain links to important terms and policies that contain important and relevant legal information.

We recommend that WCAG distinguish clearly between a conformance scope and an evaluation sample. The former identifies the product, service, application, collection, or portion thereof for which conformity is claimed. The latter identifies what was actually examined to support that conclusion. Claims should describe their boundaries conspicuously enough that a reasonable reader cannot mistake a limited assessment for whole-product conformance.

For claims covering an entire product or service, the evaluation methodology should require coverage of essential user journeys and material functionality. Claimants should not be permitted to create artificial process boundaries that exclude inaccessible steps necessary to achieve the user’s actual objective.

WCAG 3 should explicitly address states and variations

Francis Storr correctly observes that WCAG 3 needs a conformance requirement addressing page or view variations. AFixt strongly agrees and recommends broadening the concept. A modern digital interface is often not a document represented by a URL. The same URL may produce substantially different interfaces according to viewport size, orientation, authentication status, user role, personalization, localization, feature flags, responsive breakpoints, application state, dynamically loaded content, theme, input modality, or prior interaction. Accessibility must follow the user’s experience through these variations.

A conformance model should therefore account not merely for pages and views but for materially distinct states, variants, components, interactions, tasks, and processes. Responsive variants should conform. Expanded and collapsed states should conform. Relevant modal states should conform. Role-dependent functionality within scope should conform. Localization variants covered by the claim should conform. This is one area in which WCAG 3 can substantially improve upon the conceptual model inherited from WCAG 2.

Accessibility support must remain grounded in real users

We support the principle that authors should not be held responsible for every defect in every historical browser or assistive technology. The draft recognizes that user-agent and assistive-technology support varies by language, region, and environment and discusses accessibility-support concepts in its conformance architecture. [WCAG 3 Editor’s Draft] Nevertheless, accessibility-supported technologies must not become a mechanism through which an organization defines inconvenient users out of the conformance population.

There is a significant difference between demonstrating that an author used a standards-supported mechanism that fails only because of an isolated defect in obsolete assistive technology and demonstrating that an implementation is actually usable by the technologies reasonably relied upon by the affected population. WCAG should provide authors reasonable protection against defects outside their control, but specification correctness cannot be treated as conclusive evidence of accessibility.

Issue #649 is useful in this respect because it challenges testing approaches that reject modern, standards-conforming CSS or runtime behavior merely because older static validation techniques do not understand them. We agree with the underlying principle. Conformance should ultimately concern the accessible result, not the limitations of a validator.

But the same principle cuts in both directions. A technically valid accessibility tree is not necessarily proof of an accessible experience. Correct semantics can coexist with unusable keyboard interaction, inappropriate focus behavior, incomprehensible instructions, inaccessible state changes, or interoperability problems. Source syntax, platform semantics, accessibility APIs, user agents, assistive technologies, and actual user outcomes constitute different layers of evidence. For conformance purposes, the decisive inquiry should remain the accessibility of the resulting experience, considered with appropriate evidence about the technologies on which real users rely.

Functional performance statements should provide coverage, not compensatory currency

We support the expanded attention to functional needs represented in WCAG 3. Sailesh Panchang proposes making functional needs part of normative WCAG 3. He also raises legitimate questions concerning the composition and taxonomy of those needs.  Functional performance statements can provide something WCAG 2 has historically lacked: an explicit mechanism for asking whose needs are addressed and whose may have been overlooked. That is particularly valuable when a technically oriented requirement set unintentionally provides strong coverage for some disability groups and weak coverage for others.

We therefore encourage the Working Group to continue developing functional performance statements, but recommend treating them principally as a coverage and interpretation framework rather than as scoring buckets. Their most important function should be to ensure that WCAG’s normative requirements collectively address the full range of relevant functional limitations and to help evaluators understand the human consequences of requirements and failures.

This approach also responds to the equity concern raised by Lisa Seeman. The standard should not provide stronger normative protection to needs that happen to map cleanly to HTML, ARIA, or deterministic testing while relegating needs associated with cognition, language, learning, or other difficult-to-measure areas to optional achievement. The standard must begin with the human need and then determine how that need can responsibly be assessed, not begin with what is easy to test and allow testability to determine which needs become mandatory.

Outcomes and usability should not create an escape hatch from technical accessibility

Sydney Coleman raises the concern that greater emphasis on “usability” and “outcomes” could facilitate claims by accessibility-overlay vendors that their products satisfy WCAG 3 even where structural barriers remain. The concern is legitimate, although we do not believe the answer is to abandon outcome-oriented accessibility. Outcomes are ultimately why accessibility requirements exist. A technically perfect implementation that a person with a disability cannot use has failed the purpose of accessibility. WCAG 3 is right to move closer to user outcomes. The difficulty is therefore not the use of outcomes as such. It is whether the outcome is stated precisely enough, and supported by evidence strong enough, to permit a reproducible judgment.

An outcome must be sufficiently defined that evidence can demonstrate whether it occurred. “Users can complete the transaction” is more meaningful when accompanied by defined user populations, applicable conditions, interaction expectations, exceptions, and evidence requirements. “Users find the website usable” is far less useful as a normative proposition if no reproducible method exists for determining what “usable” means.

Outcome-based requirements should complement rather than erase deterministic technical requirements. Neither an overlay vendor nor any other provider should be able to substitute a generalized assertion of usability for demonstrable satisfaction of applicable accessibility requirements.

WCAG 3 must remain suitable for legal and regulatory adoption

Some historical commentary suggests that regulations should adapt to WCAG 3 rather than WCAG 3 being constrained by existing regulation. Kate Kalcevich captures this tension. We agree with the proposition only to a point.

WCAG 3 should not preserve deficiencies in WCAG 2 merely because existing laws refer to WCAG 2. Standards must be allowed to improve, and governments should update technical references as technology and standards evolve. However, it does not follow that the Working Group can disregard the characteristics necessary for regulatory adoption.

WCAG’s influence is inseparable from its role as an externally referenceable technical standard. The United States Title II rule incorporates WCAG 2.1 Level A and AA into a legally enforceable accessibility obligation. [DOJ Title II Web Rule] European accessibility law likewise operationalizes accessibility obligations through defined legal and technical requirements. [Directive (EU) 2016/2102] [Directive (EU) 2019/882]. For WCAG 3 to succeed in that environment, its requirements must be sufficiently clear to support consistent interpretation, its assessment methods must permit defensible evidence, and independent competent evaluators presented with materially equivalent evidence should ordinarily reach materially equivalent conclusions.

SiteImprove’s concern about reproducibility is therefore fundamental, not incidental. Human judgment is not itself incompatible with conformity assessment. Many mature compliance regimes depend upon professional judgment. The requirement is not mathematical identity between evaluators. The requirement should be sufficiently bounded judgment that the result is not arbitrary or based on personal biases. A conformance system in which two competent evaluators can examine substantially the same product, agree on the underlying facts, and nevertheless assign materially different conformance levels because of discretionary scoring is not ready to serve as an international compliance benchmark.

WCAG 2 compatibility should be transparent, not controlling

ITIC requests mapping between WCAG 2 and WCAG 3. Sydney Coleman raises the substantial “compliance debt” organizations may incur when moving from WCAG 2 to WCAG 3. Both concerns deserve serious attention. We strongly support a comprehensive crosswalk. Organizations worldwide have built policies, procurement standards, training, automated tools, design systems, contracts, audit methodologies, and legal requirements around WCAG 2. A migration without an authoritative mapping would impose unnecessary cost and confusion.

However, backward compatibility should not become a normative constraint that prevents WCAG 3 from correcting genuine weaknesses in WCAG 2. Nor should WCAG 3 weaken existing accessibility protections merely because its new architecture makes them inconvenient. The Working Group should eventually publish a requirement-by-requirement mapping identifying whether each WCAG 2.2 A/AA provision is equivalent to, stronger than, weaker than, divided among, subsumed by, or absent from WCAG 3 (similar things were done for WCAG 2 vs. WCAG 1). Where WCAG 3 intentionally reduces an existing requirement, that change should be explicit and justified. Where it strengthens requirements, transition guidance can address implementation burden without compromising the technical definition of accessibility.

Small organizations need scalable assessment, not reduced accessibility

Jeanne Spellman asks how WCAG 3 can remain usable by personal websites and small businesses that cannot afford extensive expert assessment.  The underlying concern is legitimate. A standard that can only be credibly evaluated through a large professional audit will have serious adoption problems. The solution, however, should not be to define accessibility differently according to the claimant’s audit budget.

Small organizations benefit from better authoring tools, accessible components, accessible templates, automated testing, clear requirements, inexpensive testing methodologies, targeted sampling, good documentation, education, and straightforward self-assessment. Legal systems may separately recognize proportionality, undue burden, or other exceptions where appropriate. The accessibility need of the user does not change according to the annual revenue of the website owner.

The distinction between technical accessibility and legal burden is again useful. The European Web Accessibility Directive expressly considers organizational size, resources, costs, and benefits when determining disproportionate burden. [Directive (EU) 2016/2102] That is where such considerations belong. A standards body should identify accessibility requirements; a legislature or regulator can determine the circumstances under which a particular actor may be excused from satisfying them.

A proposed architecture

AFixt recommends that the Working Group reorganize the WCAG 3 conformance architecture around distinct dimensions rather than attempting to encode all accessibility information in Bronze, Silver, and Gold.

1. Normative accessibility requirements. These describe the minimum user-facing conditions necessary for accessibility. All applicable minimum requirements within the claimed scope must be satisfied for conformance. Full stop.
2. Conformance scope. This identifies precisely what product, service, application, pages/views, processes, states, or other material is covered by the claim.
3. Evaluation methodology and confidence. This describes what was actually examined, how representative samples were selected, what automation and manual testing were performed, what technologies were used, known limitations, and the degree of confidence supporting a scope-wide conclusion.
4. Accessibility severity and risk. This communicates the consequences of identified nonconformities and assists remediation prioritization without converting known failures into conformity.
5. Functional coverage. This identifies the disability-related functional needs addressed by requirements and evaluations and helps prevent systematic omission of groups whose needs are difficult to express through conventional technical tests.
6. Accessibility assurance and maturity. This encompasses Assertions concerning governance, policies, training, design practices, procurement, user research, monitoring, testing, and remediation. It describes the organization’s capacity to produce and maintain accessibility but does not compensate for inaccessible product outcomes.
7. Enhanced accessibility performance. This is the natural home for Bronze/Silver/Gold or another graduated model. Once the minimum conformance floor is satisfied, higher levels can recognize Supplemental Requirements, enhanced outcomes, and other achievements beyond the minimum.

Such a model would permit substantially richer accessibility reporting than WCAG 2 while preserving the integrity of the conformance decision.

WCAG 3 Conformance: Conforms. Enhanced Accessibility: Silver. Evaluation Confidence: High. Accessibility Assurance Maturity: Level 3.

Another organization might report:

WCAG 3 Conformance: Does Not Conform. Evaluation Confidence: High. One critical nonconformity prevents keyboard-only users from completing authentication. Enhanced accessibility performance is otherwise high.

The second statement contains more useful information than simply awarding the product Bronze because its strengths elsewhere outweigh the failure. It acknowledges the organization’s achievements without declaring an exclusionary experience conforming.

Conclusion

We support the Working Group’s effort to make WCAG 3 more inclusive, outcome-oriented, scalable, and representative of modern digital products. We support stronger consideration of complete processes rather than isolated pages, functional needs rather than technology alone, representative sampling rather than impractical exhaustive testing, user outcomes rather than source-code formalism, organizational accessibility practices, severity, and accessibility beyond the minimum requirements historically represented by WCAG 2 A and AA.

WCAG 3 is trying to communicate several kinds of information that are all important, but they are not the same information and should not be collapsed into a single designation. A conformance result should answer the conformity question. Other parts of the reporting model can, and should, say much more.

The recurring problems visible throughout the Conformance issue history—sampling, automation, scoring, reproducibility, scope, severity, Assertions, Core versus Supplemental requirements, functional needs, page variations, small-business burden, legal usability, and retro-compatibility—become substantially easier to reason about once conformance is separated from the other dimensions the Working Group is attempting to measure. [WCAG 3 Conformance Issues]

WCAG 3 should be more sophisticated about accessibility than WCAG 2 is. That increased sophistication should not come at the cost of making conformance itself less determinate. A known accessibility barrier affecting one population should not become conforming because an organization accumulated accessibility successes elsewhere. An organization’s good processes should not compensate for an inaccessible product. A low-severity failure should not become a passing requirement merely because its aggregate impact is considered small. An untested portion of a system should not become accessible by inference merely because exhaustive testing is impractical. An accessibility requirement should not become Supplemental because it is expensive to implement. A disability-related need should not receive weaker normative protection because standards developers find it difficult to test.

The last point is especially important. WCAG has historically been strongest where accessibility needs can be translated into deterministic technical requirements. WCAG 3 presents an opportunity to extend equally meaningful protection to needs that do not fit that model. It would be a serious mistake to respond to the difficulty of doing so by making those needs less normative.

Most importantly, difficulty in measuring an accessibility need should be understood as a limitation of the available assessment methodology. It is not a reason to treat the underlying need as less important or to give it weaker normative status.

For that reason, we recommends that the Working Group establish a clear, non-compensatory minimum conformance floor; remove implementation difficulty and expense as criteria for determining whether an accessibility requirement is Supplemental; separate Assertions and organizational maturity from product-level conformity; treat sampling as evidence supporting a conformance conclusion rather than an exception to accessibility requirements; report severity separately from conformity; develop explicit rules governing scope, processes, states, and variations; and use functional performance statements to ensure equitable coverage rather than as containers for compensatory scoring.

Bronze, Silver, and Gold can still have substantial value. Their strongest role, however, is not to redefine what it means for a product to conform. Their strongest role is to recognize organizations that go beyond the minimum. That architecture would preserve the innovations the Working Group is seeking while producing a standard that is clearer for authors, more reproducible for evaluators, more useful for regulators and purchasers, more compatible with established conformity-assessment principles, and, most importantly, more defensible from the perspective of the people with disabilities whose access WCAG exists to protect.