Compliance officers and accessibility program managers are closely watching WCAG 3 development, intrigued and concerned. The draft's new conformance model introduces reporting tiers alongside traditional pass/fail conformance. This shift raises practical questions about planning, testing, and reporting accessibility work. These questions are critical for teams determining what changes next quarter and what remains the same.
Q1: What's different about WCAG 3's conformance model?
WCAG 3 introduces reporting tiers alongside the existing conformance structure. Instead of only declaring whether you meet a specific conformance level (A, AA, AAA), you'll also report on testing depth and coverage. The W3C draft states this approach "balances flexibility and harmonization by adding reporting tiers alongside conformance" rather than fixing every conformance challenge within a single pass/fail framework.
You'll document not just what you tested, but how thoroughly. Manual testing, automated scans, and assistive technology validation each provide different evidence. The model acknowledges that passing automated checks isn't the same as manual validation with screen readers and keyboard navigation.
Q2: Does this mean automated testing is worthless now?
No, but you can't stop there. Automated testing catches about 30-40% of accessibility issues, like missing alt text and insufficient color contrast. It's fast and repeatable, making it valuable for continuous monitoring.
The problem is treating a clean automated scan as proof of conformance. Consider a product like AAArdvark, which caps automated-only scans Assistive Technology a B grade, regardless of how clean the results are. You need manual testing to reach higher scores. Automated testing can't evaluate subjective criteria like whether alt text is meaningful or whether screen reader announcements are comprehensible.
Run automated testing on every build. Use manual testing to validate what automation can't reach.
Q3: How do we budget for manual testing if we've been relying on automation?
Identify your highest-risk interfaces: authentication flows, transaction processes, forms that gate access to services, and any content required for legal compliance. Manually test those first.
You don't need to test every page manually. Focus on templates, component patterns, and user flows. If your checkout process uses the same form pattern across five steps, validate that pattern thoroughly once.
Allocate time for screen reader testing (JAWS, NVDA, VoiceOver), keyboard-only navigation, and voice control testing. Budget 2-4 hours per complex user flow for an experienced tester. If you're testing quarterly, this is manageable. If you're testing every sprint, you'll need either dedicated accessibility QA staff or a rotation of trained testers across your QA team.
Q4: Should we wait for WCAG 3 to finalize before changing our testing approach?
No. The shift toward documenting testing depth isn't a WCAG 3 invention, it's what courts and regulators already expect. When the DOJ evaluates ADA Title III complaints, they don't just ask whether your site passes automated checks. They ask whether you've validated the experience with assistive technology.
WCAG 3 won't be a candidate recommendation until 2025 Assistive Technology the earliest, and regulatory adoption will lag by years. But the principle behind reporting tiers, that testing methodology matters as much as results, applies now. If you're only running automated scans, you're already behind the standard of care in accessibility governance.
Q5: How does this affect our Accessibility Conformance Reports?
Your Accessibility Conformance Reports should already document testing methodology, but WCAG 3's reporting tiers will make that documentation more structured. Specify which success criteria were evaluated through automated testing, which received manual review, and which were validated with assistive technology.
Your Voluntary Product Accessibility Template responses can't all say "Supports" without distinguishing between automated verification and manual validation. When you claim conformance with WCAG 2.1 Level AA Success Criterion 1.3.1 (Info and Relationships), note whether that's based on automated DOM inspection or manual screen reader testing.
Start tracking testing methodology now in your issue tracking system. Tag findings with the testing method that identified them. When you remediate an issue, document how you validated the fix. That metadata becomes your evidence trail for reporting tiers.
Q6: What happens to our existing WCAG 2.1 or 2.2 conformance claims?
They remain valid. WCAG 3 doesn't invalidate WCAG 2.x conformance. Section 508 of the Rehabilitation Act currently references WCAG 2.0 Level AA (through the Revised Section 508 Standards). EN 301 549 references WCAG 2.1 Level AA. The DOJ Final Rule (2024) for ADA Title II references WCAG 2.1 Level AA.
Those regulatory references won't shift to WCAG 3 until years after it's finalized. You'll have time to adapt. Don't ignore the direction of travel. The emphasis on testing depth, manual validation, and documented evidence isn't going away. Build those practices into your program now while you're still working under WCAG 2.x, and you'll be ready when WCAG 3 becomes the reference standard.
Q7: How do we explain this to executives who just want a pass/fail answer?
Frame it as risk documentation. Pass/fail conformance tells you whether you meet a baseline. Reporting tiers tell you how confident you should be in that claim.
Consider two sites both claiming WCAG 2.1 Level AA conformance. One ran automated scans and fixed the flagged issues. The other ran automated scans, conducted manual testing, validated with three screen readers, and tested all interactive components with keyboard-only navigation. Both can claim conformance, but one has far more defensible documentation if a complaint is filed.
Reporting tiers don't replace conformance, they add a confidence level. That's valuable information for anyone managing legal risk or procurement decisions.
Q8: Where should we focus our manual testing efforts first?
Prioritize anything that blocks access to core functionality. Authentication flows with inaccessible CAPTCHA or multi-factor authentication, forms that don't work with screen readers, modal dialogs that trap keyboard focus, and dynamic content that doesn't announce state changes.
Then move to high-traffic user journeys: search, navigation, account management, and transaction flows. Test with actual assistive technology users if you can, their experience data is more valuable than any checklist.
Document everything. WCAG 3's reporting tiers will reward organizations that can show their work.
Where to go for more
The W3C maintains the WCAG 3 Working Draft with ongoing updates. The International Association of Accessibility Professionals offers training on conformance testing methodology. If you're building testing capacity, consider sending team members through the Web Accessibility Specialist certification program, it covers manual testing techniques that automated tools can't replicate.
Your testing methodology is becoming as important as your test results. Start documenting both now.
