Accessibility teams have long worked with a difficult tension. A product can satisfy a list of technical requirements and still be hard to use, while a small defect can create a formal failure even when most of the experience works well. The March 2026 working draft of W3C Accessibility Guidelines 3.0 continues an effort to build a standard that can address more technologies, more disability needs and more realistic evaluation.
The word “draft” matters. WCAG 3 is still being developed and should not replace WCAG 2 in current policies, procurement or testing. Its value today is directional. It shows where accessibility practice may be heading and which capabilities teams should begin strengthening before a future standard becomes stable.
From isolated rules to user outcomes
Technical criteria remain essential because they make expectations testable. But people experience a journey, not a collection of code checks. They need to discover a control, understand it, operate it and recover from mistakes. A broader outcomes-based approach can connect individual requirements to whether someone can actually complete an important task.
For designers, this reinforces the need to test flows rather than screens. A form may have correct labels but still create confusion through unclear instructions. A modal may meet contrast requirements but trap attention in an unexpected sequence. Accessibility quality emerges from the relationship among content, interaction and implementation.
Nuance must remain accountable
A more flexible scoring model could describe partial progress and complex experiences more accurately. It also risks becoming harder to explain. Organisations need results that designers can act on, developers can reproduce and buyers can compare. Nuance is useful only when it does not become an excuse for subjective self-certification.
The answer is stronger evidence. Automated tests should be combined with structured manual review and usability research with disabled people. Teams should document which technologies and tasks were tested, what barriers were found and how severe their practical effects are. That record is more informative than a badge detached from its test conditions.
What teams should do now
The immediate priority remains conformance with the applicable WCAG 2 version and local legal requirements. Teams should not wait for WCAG 3 to improve research, governance and design-system coverage. They can define critical user journeys, include assistive technology in quality assurance and make accessibility defects visible in the same systems used for security and reliability work.
Design systems can translate standards into defaults: focus states, target sizes, colour roles, error patterns and reduced-motion behaviour. Product teams can then spend more time on the contextual problems no component library can solve, such as cognitive load and the clarity of decisions.
A standard is a floor for practice
WCAG 3 will evolve through public review, testing and debate. Its most useful message is already clear: accessibility cannot be reduced to a final audit. Standards provide a common floor, but inclusive products require continuous attention to how different people accomplish real goals. The organisations best prepared for the next standard will be those that have already made that work routine.
