The Future of Web Accessibility: 7 Shifts to Prepare For (and What to Do About Each)

Predictions about technology tend to age badly. So instead of guessing what accessibility will look like in 2035, this post looks at seven shifts that are already under way, the kind you can see in audit findings, legal deadlines and tool roadmaps today, and what you can do about each one now.

I’ve spent six years testing enterprise products for accessibility, and as a low vision professional I use screen readers and magnification every day. These are the changes I see reshaping the work, from both sides of the screen.

Key takeaways

• Accessibility is moving from voluntary best practice to enforced law, especially in the EU and US public sector.
• AI is speeding up testing and authoring, but it is not replacing manual testing or human judgment.
• WCAG 2.2 AA is the target that matters now. WCAG 3 is coming, but it is not something to build against yet.
• The biggest wins are moving upstream: accessible design systems, components and acceptance criteria.
• Teams that measure accessibility like they measure performance or security will be the ones that keep it.

1. From “should” to “must”: enforcement is real now

For years, many organisations treated accessibility as a nice-to-have, because nobody was checking. That has changed.

• European Union: the European Accessibility Act (EAA) has applied since 28 June 2025 to a wide range of consumer products and services, including e-commerce, banking, e-books, ticketing and electronic communications. It covers businesses outside the EU that sell to EU consumers. The technical benchmark is EN 301 549, which incorporates WCAG.
• United States: the ADA continues to be applied to websites and apps through litigation, Section 508 governs federal technology, and the Department of Justice’s 2024 rule under ADA Title II sets WCAG 2.1 AA as the standard for state and local government websites and apps, with compliance deadlines starting in 2026.
• India and elsewhere: the Rights of Persons with Disabilities Act and GIGW guidelines already set expectations for government digital services, and more countries are aligning with WCAG-based standards.

What it means in practice: accessibility findings are no longer filed as “low priority enhancements”. In audits, I increasingly see them tracked as legal and procurement risk, alongside security issues.

What to do now:

• Know which laws apply to your product and which markets you sell into.
• Treat WCAG 2.2 AA as your baseline target, even where the law still cites 2.1.
• Publish an accessibility statement (EU) or keep an up-to-date VPAT / ACR (US) for each product.

2. AI speeds up testing, but doesn’t replace testers

AI is already changing how accessibility work gets done. Tools can now suggest alt text, flag likely contrast and labelling issues as code is written, summarise screen reader output and help triage large audit reports.

But the limits matter just as much:

• Automated checks, AI-assisted or not, still catch only a portion of WCAG failures. Keyboard traps, confusing reading order, unclear error recovery and poor focus management usually need a human with assistive technology to find.
• AI-generated alt text is often generic or wrong. A model can describe “a chart with bars”, but it doesn’t know what the chart is meant to show.
• Overlays that promise one-line compliance remain a problem. In 2025 the US Federal Trade Commission ordered accessibility overlay provider accessiBe to pay $1 million over misleading claims that its AI tool could make any website compliant.

What to do now:

• Use AI and automated tools in CI and in design reviews to catch the easy issues early.
• Keep manual testing with screen readers, keyboard and zoom as a non-negotiable step before release.
• Treat every AI-generated alt text, caption or summary as a draft that a person reviews.

3. WCAG 2.2 is the target; WCAG 3 is on the horizon

WCAG 2.2 became a W3C Recommendation in October 2023. It added nine success criteria, including Focus Not Obscured, Target Size (Minimum), Dragging Movements, Consistent Help and Accessible Authentication. These address problems I see constantly in real products: sticky headers hiding the focused element, tiny icon buttons, drag-only interfaces and login flows that rely on memorising or transcribing codes.

WCAG 3 (the “W3C Accessibility Guidelines”) is still in draft. It aims to broaden scope beyond the web, cover more cognitive accessibility needs and move from pass/fail toward a more graduated way of scoring. It is worth following, but nothing in law points to it yet, and its structure may still change.

What to do now:

• Add the nine WCAG 2.2 criteria to your test plans and design checklists.
• Fix focus visibility and target size in your design system first, because they affect every screen.
• Follow WCAG 3 drafts for direction, but don’t rebuild processes around them yet.

4. Accessibility moves upstream, into design systems

The most expensive way to do accessibility is to audit a finished product and send back a list of 300 issues. The cheapest is to make the components accessible once, so every team that uses them inherits the fix.

This is where mature teams are heading:

• Accessible components by default: buttons, dialogs, menus, tabs, tooltips and form fields built with correct semantics, keyboard support and focus management, tested with screen readers before they ship to product teams.
• Annotations at handoff: reading order, headings, landmarks, focus destinations and live-region announcements documented in design files, so developers don’t have to guess. I’ve written about this approach in Audio-First Design Heuristics.
• Acceptance criteria: “keyboard operable, announced correctly, meets contrast” written into the definition of done for every user story.

What to do now:

• Audit your design system components before your product pages.
• Add accessibility annotations to your design handoff template.
• Make one accessibility check part of every pull request review.

5. Beyond web pages: documents, e-books, apps and immersive tech

“Web accessibility” is becoming simply “digital accessibility”. The EAA explicitly covers e-books and e-reading software, mobile apps are held to the same expectations as websites, and PDFs and documents remain one of the most common sources of barriers.

Emerging interfaces raise new questions too: voice assistants that don’t work for people with speech disabilities, AR and VR experiences with no non-visual alternative, and kiosks and smart devices with touch-only controls.

What to do now:

• Include documents, PDFs and e-books in your accessibility scope, not just HTML pages. (See How to Test EPUB Accessibility.)
• Test native apps with VoiceOver and TalkBack, not just the mobile website.
• For any new interface type, ask early: how does someone use this without sight, without hearing, without fine motor control, or without speech?

6. Personalisation, carefully

One of the most promising directions is interfaces that adapt to the user: larger text, reduced motion, simplified layouts, captions on by default, or plain-language summaries, based on preferences people set once.

Operating systems already offer many of these settings, and the web can respect them through features like prefers-reduced-motion, prefers-contrast and user font-size settings. The risk is “accessibility mode” designs that hide content or give disabled users a lesser version of the product. Personalisation should add options, not replace a single accessible design.

What to do now:

• Respect user preferences the platform already exposes: reduced motion, contrast, zoom and text size.
• Never make an accessibility toggle the only way to reach an accessible experience.
• Test at 200% and 400% zoom, with Windows high contrast and with reduced motion enabled.

7. Accessibility gets measured like everything else

What gets measured gets maintained. Teams that sustain accessibility track it the way they track performance or security, with numbers that leadership actually sees:

• Open accessibility defects by severity and age
• Percentage of design system components that pass a full screen reader test
• Accessibility regressions caught in CI versus found after release
• Results from usability sessions with disabled participants

What to do now:

• Pick two or three metrics and report them monthly.
• Tag accessibility defects consistently in your bug tracker so they can be counted.
• Include disabled people in usability research, not only in compliance testing.

How accessibility professionals can prepare

If you work in accessibility, or want to, these are the skills I’d invest in:

1. Deep manual testing skill with at least two screen readers (for example NVDA and VoiceOver), keyboard-only testing and magnification. This is the part tools can’t replace.
2. Standards and law literacy: WCAG 2.2, EN 301 549, Section 508 and the EAA, well enough to explain to a product manager what applies and why.
3. Code literacy: enough HTML, CSS, ARIA and JavaScript to write a precise fix, not just report the problem.
4. Design collaboration: reviewing designs and annotating them before a line of code exists.
5. Using AI well: knowing where AI tools save time and where their output must be checked.
6. Credentials where useful: IAAP certifications such as CPACC and WAS, or the DHS Section 508 Trusted Tester programme, help show a baseline of knowledge, especially for freelance and consulting work.

Conclusion

The future of accessibility isn’t a single breakthrough technology. It’s a shift in how products get built: enforced by law, sped up by tools, designed in from the start and measured over time. The fundamentals stay the same: perceivable, operable, understandable and robust. What’s changing is that ignoring them is becoming expensive.

Start with the basics that matter today, WCAG 2.2 AA, accessible components and real manual testing, and you’ll be ready for whatever the next ten years bring.

Further reading

• What Is Digital Accessibility? A Practical Guide to WCAG, POUR and Testing
• Skip Links: A Complete Guide for Developers and Designers (WCAG 2.2)
• Audio-First Design Heuristics
• W3C: What’s New in WCAG 2.2
• W3C: WCAG 3 Introduction