What is Web Accessibility?

94.8% of websites still fail basic accessibility standards. That means most of the web is built in a way that actively blocks 1.3 billion people from using it.

Web accessibility is the practice of designing and building digital experiences that work for everyone, including people with visual, auditory, motor, and cognitive disabilities.

It covers WCAG compliance, assistive technology support, inclusive design, and legal obligations under the ADA, Section 508, and the European Accessibility Act.

This guide covers everything: what the standards actually require, where sites fail, how testing works, and why the business case is stronger than most teams realize.

What Is Web Accessibility?

Web accessibility is the practice of designing and building websites so people with disabilities can use them without barriers. It covers every layer of the stack: markup, visual design, interaction patterns, and content.

About 1.3 billion people, or 16% of the global population, live with some form of disability (WHO, 2024). That’s not a niche audience.

Disabilities that affect web use fall into 5 categories: visual, auditory, motor, cognitive, and speech impairments. These range from permanent conditions like blindness to temporary ones like a broken wrist or situational ones like bright sunlight on a phone screen.

Accessibility is not the same as usability. Usability asks whether a site is easy to use. Accessibility asks whether it can be used at all. A site can score well on usability benchmarks and still be completely unusable for someone relying on a screen reader or keyboard navigation.

The web was built to be open to everyone. Tim Berners-Lee put it plainly: “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Accessibility is the technical commitment that makes that possible.

What Are the WCAG Guidelines and Why Do They Matter?

The Web Content Accessibility Guidelines (WCAG) are the international standard for accessible digital content, published by the W3C through its Web Accessibility Initiative (WAI). WCAG 2.2 is the current version, published October 5, 2023.

Every WCAG requirement maps to one of 4 core principles, known as POUR: Perceivable, Operable, Understandable, Robust. If content fails any one of those, it fails accessibility.

Conformance comes in 3 levels: A (minimum), AA (standard), and AAA (highest). Level AA is the legal and practical benchmark for most organizations. It’s what the ADA, Section 508, and the European Accessibility Act reference.

What Are the POUR Principles?

Perceivable: users must be able to sense the content, whether through sight, sound, or touch.

Operable: all functionality must work via keyboard, not just a mouse. This covers focus management, skip links, and time limits on interactions.

Understandable: content must be readable and predictable. Error messages, form instructions, and navigation patterns must make sense to the user.

Robust: content must work with current and future assistive technology. This is where semantic HTML and correct ARIA usage become critical.

What Changed in WCAG 2.2?

WCAG 2.2 added 9 new success criteria to address gaps that 2.1 left unresolved, especially for users with cognitive disabilities, low vision, and motor impairments (W3C, 2023).

For organizations targeting Level AA, 6 of those 9 criteria apply directly. The key additions are:

• Focus Not Obscured: keyboard focus indicators must remain at least partially visible, even when sticky headers or floating elements are present
• Dragging Movements: any drag interaction must have a single-pointer alternative
• Target Size (Minimum): interactive elements must be at least 24×24 CSS pixels
• Redundant Entry: forms cannot ask users to re-enter information already submitted in the same process
• Accessible Authentication: login flows cannot require cognitive function tests (like CAPTCHAs) without an accessible alternative

One criterion was also removed. Success Criterion 4.1.1 Parsing was dropped because modern browsers handle malformed HTML consistently, making it redundant.

If you were already WCAG 2.1 AA compliant, the gap to 2.2 compliance is relatively small. Most teams with moderate issues can close it in 4 to 8 weeks (AllAccessible, 2025).

What Are the Legal Requirements for Web Accessibility?

Web accessibility is no longer just best practice. In most major jurisdictions, it carries legal weight. The specific law depends on where you operate and who you serve.

2,014 ADA website accessibility lawsuits were filed in the first half of 2025 alone, a 37% increase compared to the same period in 2024 (EcomBack, 2025).

What Does ADA Compliance Mean for Websites?

The Americans with Disabilities Act (ADA) Title III applies to public-facing websites. Courts have consistently ruled that commercial websites are “places of public accommodation” covered by the law.

The Department of Justice finalized its ADA Title II rule in April 2024, formally requiring state and local government websites to conform to WCAG 2.1 Level AA by April 2026. Courts in Title III cases apply the same standard to business websites.

E-commerce accounts for 69% to 77% of all digital accessibility lawsuits (Seyfarth Shaw and UsableNet, 2025). Online stores are dense with dynamic components such as product filters, carousels, and multi-step checkouts, each one a potential WCAG failure point.

One important note: accessibility overlay widgets do not prevent lawsuits. In 2024, over 1,000 businesses were sued despite having overlay widgets installed, accounting for more than 25% of all cases (UsableNet, 2024). In January 2025, the FTC fined overlay provider accessiBe $1 million for false advertising related to compliance claims.

What Is the European Accessibility Act?

The European Accessibility Act (EAA) entered enforcement on June 28, 2025. It covers most digital products and services sold in the EU, including websites, mobile apps, and e-commerce platforms.

The EAA references EN 301 549 as its technical standard, which maps to WCAG 2.1 Level AA. Organizations serving EU markets must comply, regardless of where they are headquartered.

Microenterprises (fewer than 10 employees, annual turnover under 2 million euros) are exempt, but most commercial operations are not.

Other relevant laws by jurisdiction:

• Section 508: applies to US federal agencies and their contractors; references WCAG 2.0 AA, with WCAG 2.2 adoption expected
• Equality Act 2010: UK legislation requiring digital services not to discriminate against disabled users
• AODA: Canada’s Ontario accessibility standard requiring WCAG 2.0 AA compliance for large organizations

Who Benefits from Web Accessibility?

The honest answer is everyone, not just users with permanent disabilities. This is the curb-cut effect applied to the web: features built for users with disabilities consistently improve the experience for everyone else too.

About 72% of adults with disabilities own a smartphone (DDIY, 2024). That means most disabled users are already on the same devices as everyone else, just with different needs.

Permanent, Temporary, and Situational Needs

Accessibility barriers don’t only affect people with permanent conditions.

Permanent: blindness, deafness, motor impairments, cognitive conditions like dyslexia or ADHD.

Temporary: a broken arm prevents mouse use. Eye surgery recovery affects reading. A new medication may impair concentration.

Situational: watching a video without headphones in public. Using a phone in direct sunlight. Holding a baby with one hand while trying to navigate a site.

One in six people globally will be over 60 by 2030 (WHO). Age-related changes in vision, hearing, and fine motor control mean that accessible design increasingly serves the general population, not a subset of it.

The Curb-Cut Effect in Practice

Specific accessibility features that benefit all users:

• Captions on video help people in noisy environments and non-native speakers
• Keyboard navigation benefits power users who never touch a mouse
• High color contrast improves readability in bright light
• Clear error messages in accessible forms reduce frustration for all users, not just those with cognitive impairments
• Logical heading structure makes both screen readers and skim-readers more efficient

Captions are probably the clearest example. Originally designed for deaf and hard-of-hearing users, they are now used by the majority of people watching video on social media, most of whom have no hearing impairment at all.

What Are the Most Common Web Accessibility Barriers?

The WebAIM Million report is the most comprehensive annual analysis of web accessibility on the open web. It scans the top one million homepages for WCAG failures. The 2025 findings are not encouraging.

94.8% of homepages had detectable WCAG failures, with an average of 51 accessibility errors per page (WebAIM, 2025). The 2026 report shows that number increased to 56.1 errors per page.

What Does the WebAIM Million Report Show?

The same 6 failure types have dominated every year since WebAIM began tracking:

• Low color contrast text: found on 79.1% of homepages in 2025, averaging 29.6 instances per page
• Missing alt text: 55.5% of pages had images without alternative text
• Empty links: links with no descriptive text, which screen readers cannot interpret
• Missing form labels: input fields without associated labels
• Missing document language: 15.8% of homepages lacked a declared HTML lang attribute, preventing assistive technology from processing language correctly
• Empty buttons: buttons with no accessible name

These aren’t complex issues. None require deep technical knowledge to fix. They persist because accessibility is treated as an afterthought rather than a build requirement.

What Are the Most Frequently Failing WCAG Criteria?

Low contrast alone accounts for roughly 30% of all accessibility errors detected by automated tools, according to Deque’s automated coverage analysis. It’s also one of the most fixable issues at the design system level if color contrast ratios are built into token definitions from the start.

JavaScript-heavy single-page applications create a separate class of problems that automated scanners mostly miss: focus traps in modal dialogs, missing ARIA live regions for dynamic content updates, and broken tab order after DOM manipulation.

PDFs are another consistent problem area. Most PDF documents are generated without accessibility tagging, making them completely unusable for screen reader users. UK Gov research found this is especially prevalent in public sector documents, where PDFs are the default format for official publications.

How Is Web Accessibility Tested?

No single method catches everything. Solid accessibility testing combines 3 approaches: automated scanning, manual testing, and user testing with people who have disabilities. Each one catches what the others miss.

Automated tools like axe-core find on average 57% of WCAG issues in real-world pages (Deque, 2024). That’s useful coverage, but it means 43% of issues still require human judgment.

What Do Automated Accessibility Tools Catch?

Automated scanners are fast and consistent. They run against the rendered DOM and flag structural failures like missing labels, insufficient contrast ratios, and absent alt attributes.

The most widely used tools:

• axe-core: open-source engine from Deque, powers axe DevTools and Google Lighthouse; prioritizes zero false positives
• WAVE: browser extension from WebAIM; visual overlay makes it easy for non-developers to interpret results
• Google Lighthouse: built into Chrome DevTools; runs axe-core as its accessibility engine but covers a subset of axe’s full rule set

For development teams, integrating axe-core into a CI/CD pipeline catches regressions before they reach production. This is a better investment than running a one-off scan at the end of a project.

What automated tools cannot catch: whether alt text is actually descriptive, whether error messages are meaningful, whether focus order makes logical sense, or whether a drag interaction is intuitive for a motor-impaired user.

How Does Screen Reader Testing Work?

Screen reader testing is the most direct way to experience what blind and visually impaired users encounter. It requires navigating the entire site by keyboard and audio only, no mouse, no visual reference.

The major screen readers by platform:

• JAWS: most widely used by professional screen reader users on Windows; paid, enterprise-grade
• NVDA: free, open-source Windows screen reader; the most common choice for accessibility testing in development
• VoiceOver: built into macOS and iOS; Apple’s native accessibility solution
• TalkBack: Android’s built-in screen reader

A basic screen reader test covers: page title, heading structure, skip navigation links, form label associations, image alt text, link text clarity, and modal focus management. Most of these cannot be verified any other way.

Took me a while to get comfortable with NVDA. The learning curve is real. But there’s genuinely no substitute for hearing exactly what a blind user hears when they land on a page for the first time.

What Is an Accessibility Audit?

An accessibility audit is a structured evaluation of a website against WCAG 2.1 or 2.2 Level AA. It covers the full interaction surface, not just the homepage: templates, user flows, interactive components, and documents.

A proper audit produces an issue log with severity levels (critical, serious, moderate, minor) and remediation guidance. Many audits also produce a VPAT (Voluntary Product Accessibility Template), which is required for US federal procurement and enterprise sales.

What Does an Accessibility Audit Cover?

The scope is usually defined by page templates, not individual URLs. A site with 500 pages and 8 templates requires auditing those 8 templates plus critical user flows like checkout, login, search, and account management.

A full audit combines 3 testing methods:

• Automated scanning of all templates to flag structural issues
• Manual keyboard and screen reader testing of interactive components
• Review of documents (PDFs, Word files) for accessibility tagging

The deliverable typically includes:

• Issue log with WCAG success criterion reference, severity, affected element, and recommended fix
• Conformance statement indicating current WCAG level achieved
• VPAT if required for procurement purposes

When to commission an audit: before a site launch, after a major redesign, when a legal complaint is received, or when regulatory deadlines are approaching (the EAA enforcement in June 2025 triggered a significant surge in audit demand across EU-facing businesses).

Spot-Check vs. Full Audit

Spot-check: covers a sample of pages, fast and low-cost, suitable for a quick health check or initial scoping.

Full audit: covers all templates and user flows, production-ready issue log, required for VPAT generation or legal defense documentation.

A spot-check is not a compliance document. Don’t treat it as one. Organizations that receive ADA demand letters and then submit a spot-check report as evidence of compliance have had poor outcomes in court.

BBC, for example, publishes a detailed accessibility conformance report for its website and media player, updated annually. That kind of documented, ongoing audit process is what regulators and courts actually want to see.

What Is an Accessibility Statement?

An accessibility statement is a public-facing page that declares a site’s current conformance status, known limitations, and how users can report problems. It is the primary communication channel between an organization and disabled users who encounter barriers.

For public bodies in EU member states, an accessibility statement is legally required under the Web Accessibility Directive and now the European Accessibility Act (EAA, enforced June 2025). For US federal agencies, OMB memorandum M-24-08 mandates it. For private businesses, it is considered best practice and increasingly expected by enterprise and government procurement officers requiring a VPAT.

What Must an Accessibility Statement Include?

Required fields per W3C guidance:

• The accessibility standard applied (e.g., WCAG 2.2 Level AA)
• Current conformance status: fully conformant, partially conformant, or non-conformant
• Known limitations, described in plain language (not WCAG criterion numbers)
• A contact method for users to report barriers
• Date of the last review or audit

Saying “videos do not have captions” communicates the issue clearly. Saying “WCAG SC 1.2.2 was not met” does not (W3C, WAI).

The W3C provides a free accessibility statement generator at w3.org/WAI/planning/statements/ that produces a downloadable, customizable template. It takes about 15 minutes to complete for a site with no major conformance gaps.

Where Should an Accessibility Statement Live?

Placement follows a consistent convention. Footer links are the most common location, alongside privacy policy and terms of service. W3C recommends linking from at least 3 locations: the footer, a sitemap, and an About or Help page.

Key point: the statement page itself must be accessible. It’s not unusual for accessibility statement pages to have the same barriers as the rest of the site. Capital One’s accessibility statement is a frequently cited real-world example, stating its commitment to WCAG and ARIA specifications and providing a direct contact path for users who need help.

How Does Web Accessibility Affect SEO?

Accessibility and SEO share a significant number of technical requirements. The practices that make content usable for screen readers often make it easier for search engine crawlers to understand and rank as well.

WCAG-compliant websites gained 23% more organic traffic and ranked for 27% more keywords compared to non-compliant sites, based on a study of 10,000 websites by AccessibilityChecker.org and Semrush (2025).

Where Accessibility and SEO Directly Overlap

73% of websites showed an increase in organic traffic within 3 months of implementing accessibility improvements, according to research by AccessibilityChecker.org and BuiltWith across 847 domains.

The specific overlaps that produce measurable ranking signals:

• Alt text on images: required by WCAG 1.1.1 for screen readers; also how Google indexes visual content for image search
• Heading hierarchy: used by 71.6% of screen reader users to navigate pages; also gives Google the content structure it uses for featured snippets
• Video captions and transcripts: required for deaf users; also provides indexable text that search engines cannot extract from audio
• Semantic HTML: ARIA landmark roles help screen readers and reduce cost of retrieval for search engine NLP
• Keyboard-navigable layouts: tend to have cleaner URL structures and more logical content hierarchies, which search engines reward

What Do Engagement Metrics Show?

Accessible websites show 22% lower bounce rates and 27% longer session duration compared to inaccessible sites (TheEEDigital, 2025). These are behavioral signals Google uses to evaluate content quality.

ClickAway Pound research found that 71% of users with access needs leave a site they find difficult to use without complaining. They simply leave.

Legal & General redesigned their website with accessible HTML structure, proper alt text, and accessible forms. Their SEO traffic increased by 50% after the accessibility overhaul (TestParty, 2025).

What Is the Business Case for Web Accessibility?

The global disability market represents approximately $13 trillion in annual disposable income, including the extended network of friends and family who factor accessibility into their own purchasing decisions (Return on Disability, 2024).

That’s not a niche. That’s the largest underserved market in consumer spending.

Revenue and Market Access

Forrester Research found accessibility improvements yield $100 in return for every $1 invested, making it one of the highest-ROI initiatives in digital operations (Forrester, 2024).

Concrete market access numbers:

• 61 million Americans live with disabilities, with estimated $490 billion in annual US disposable income
• 71 million Baby Boomers increasingly need accessible features to shop online, controlling $548 billion in discretionary spending (Accessibility.Works)
• Cart abandonment on inaccessible sites: 69%. On accessible sites: 23% (TestParty, 2025)

Tesco invested £35,000 in accessibility improvements to their online grocery platform. Annual online sales reached £13 million after the changes (TestParty, 2025).

Cost of Retrofitting vs. Building In

Organizations that build accessibility in from the start spend 67% less on compliance than those who retrofit it after launch (TestParty, 2025).

The math on legal risk is also straightforward. A single ADA lawsuit settlement typically ranges from $5,000 to $75,000 for a small business. For large enterprises, it can exceed $350,000 per case, not including remediation costs.

Teams integrating accessibility testing into CI/CD pipelines spend 23% less on total development costs compared to teams that test separately (TestParty, 2025). Catching a missing label at the component level takes minutes. Finding a broken tab order after a major release takes days.

Brand Reputation and Procurement Advantage

92% of disabled consumers report feeling more favorable toward brands that demonstrate a genuine accessibility commitment (TestParty, 2025). That translates into repeat purchases, word-of-mouth referrals, and community-level loyalty that competitors without accessible products don’t get.

Accessibility is also a direct procurement requirement. US federal agencies cannot purchase software or digital services without a VPAT. Enterprise procurement teams increasingly ask for accessibility conformance reports as part of vendor evaluation, especially post-EAA in Europe.

How Is Accessibility Built Into Design Systems?

A design system solves accessibility problems once, thoroughly, and distributes those solutions across every product that uses the system. This is why IBM, the UK Government, and Microsoft invest heavily in making their design systems accessible at the component level rather than auditing each product separately.

All IBM Carbon components follow the IBM Accessibility Checklist, which is based on WCAG AA, Section 508, and European EN 301 549 standards (Carbon Design System, 2024).

What Are ARIA Roles and When Are They Used?

ARIA (Accessible Rich Internet Applications) is a set of attributes that add semantic meaning to HTML elements when native HTML alone is insufficient. It’s the primary tool for making custom user interface components accessible.

Use ARIA when:

• A native HTML element doesn’t exist for the pattern (e.g., tab panel, combobox, tree view)
• Dynamic content updates need to be announced to screen readers via aria-live regions
• A custom button or control is built from a non-semantic element like a div

Don’t use ARIA when: a native HTML element already communicates the right role. A <button> is already a button. Adding role="button" to it is redundant. Adding it to a <div> without keyboard event handling is incomplete and often worse than no ARIA at all.

The W3C ARIA Authoring Practices Guide (APG) provides reference patterns for every common component: tabs, dialogs, accordions, comboboxes, and more. It is the authoritative source for correct keyboard behavior and ARIA attribute usage.

What Is the Shift-Left Accessibility Approach?

Shift-left means catching accessibility issues at the design and development stage, not after launch. The earlier a problem is found, the cheaper it is to fix.

In Figma, accessibility annotations document focus order, ARIA roles, heading levels, and landmark regions before a component is built. GitHub’s design system team built a set of Primer A11y Presets, accessibility annotation templates that prompt designers to fill in component-specific details during design reviews (GitHub Blog, 2024).

The GOV.UK Design System tests all components with real users who have disabilities before publishing them. Carbon mandates full keyboard testing for every component state. These practices mean that accessibility quality is baked in before a single line of production code is written.

What Is Digital Accessibility for Mobile Applications?

72% of mobile user journeys have accessibility barriers (AccessibilityChecker.org, 2025). Mobile-specific failures are distinct from web failures and require different testing tools and methods.

The EAA, which entered enforcement in June 2025, explicitly covers native mobile applications in banking, e-commerce, transport, and telecommunications across the EU. Mobile apps are no longer a separate compliance question from websites.

Platform-Specific Accessibility APIs

Each mobile platform has its own accessibility layer. Web standards like ARIA do not map directly to native apps.

iOS: VoiceOver is Apple’s built-in screen reader, used by 71% of mobile screen reader users. The Accessibility Inspector in Xcode identifies missing labels, focus issues, and contrast failures. Apple’s Human Interface Guidelines specify a minimum touch target size of 44×44 points.

Android: TalkBack is Google’s screen reader, used by 28% of mobile screen reader users. Android Accessibility Scanner flags common issues. Google Material Design specifies 48x48dp as the minimum touch target. BrailleBack adds braille display support on top of TalkBack.

WCAG 2.2 Level AA requires interactive targets of at least 24×24 CSS pixels for mobile web. For native apps, platform-specific minimums apply (Apple: 44pt, Android: 48dp). Always meet the higher threshold to satisfy both the platform guideline and WCAG.

Common Mobile-Specific Failures

Mobile accessibility audits consistently surface the same categories of failures:

• Unlabeled buttons and icons that VoiceOver announces as “button” with no description
• Gesture-only interactions with no single-pointer alternative (violates WCAG 2.5.7)
• Orientation locked to portrait, preventing users who mount devices in landscape from using the app (violates WCAG 1.3.4)
• Small touch targets that cause accidental activations, especially for motor-impaired users
• CAPTCHA-style authentication without an accessible alternative (violates WCAG 3.3.8 in WCAG 2.2)

React Native and Flutter abstract platform differences, but the mapping between their accessibility APIs and the underlying iOS and Android layers is not always 1:1. A prop that works correctly on iOS may behave differently on Android. Testing on real devices with actual screen readers is non-negotiable. Simulators don’t replicate real assistive technology behavior accurately enough to rely on for compliance validation.

Mobile app accessibility requires the same 3-method testing approach as web: automated scanning in the build pipeline, manual screen reader testing before each release, and user testing with people who have disabilities for major feature launches.

FAQ on Web Accessibility

What is web accessibility?

Web accessibility is the practice of designing websites and digital tools so people with disabilities can use them. It covers visual, auditory, motor, and cognitive impairments. The goal is barrier-free access for all users, regardless of ability or assistive technology.

What does WCAG stand for?

WCAG stands for Web Content Accessibility Guidelines, published by the W3C. It is the international technical standard for digital accessibility. WCAG 2.2 is the current version, organized around four principles: Perceivable, Operable, Understandable, and Robust.

Is web accessibility legally required?

Yes, in most major jurisdictions. In the US, the ADA covers public-facing websites. The European Accessibility Act entered enforcement in June 2025. Section 508 applies to US federal agencies. Non-compliance carries real legal risk, with over 2,000 lawsuits filed in H1 2025 alone.

What is WCAG Level AA?

Level AA is the mid-range WCAG conformance level and the legal benchmark for most organizations. It satisfies all Level A and AA success criteria, including minimum color contrast ratios, keyboard navigation, and consistent site navigation across pages.

What are the most common web accessibility failures?

According to the WebAIM Million 2025 report, the top failures are low-contrast text (79.1% of pages), missing alt text, empty links, unlabeled form fields, and missing document language declarations. These same six issues have dominated every annual report since 2019.

What assistive technologies do disabled users rely on?

Screen readers like JAWS, NVDA, and VoiceOver convert content to audio. TalkBack and BrailleBack serve Android users. Keyboard-only navigation, switch controls, and voice input tools are also common. Accessible design must work across all of them, not just one.

How do I test a website for accessibility?

Use a three-method approach: automated tools like axe-core or WAVE catch around 57% of issues. Manual keyboard and screen reader testing catches what automation misses. User testing with disabled participants provides the most reliable validation of real-world usability.

Does web accessibility improve SEO?

Yes, measurably. WCAG-compliant sites gain 23% more organic traffic and rank for 27% more keywords than non-compliant sites (AccessibilityChecker.org and Semrush, 2025). Alt text, heading structure, semantic HTML, and captions directly benefit both screen readers and search engine crawlers.

What is an accessibility audit?

An accessibility audit is a structured evaluation of a website against WCAG 2.1 or 2.2 Level AA. It combines automated scanning, manual testing, and screen reader review. The output is an issue log with severity ratings and a VPAT for procurement purposes.

What is inclusive design?

Inclusive design is a methodology that considers the full range of human diversity from the start of a project. It goes beyond disability compliance. Designing for edge cases, such as motor impairment or cognitive load, consistently produces better experiences for all users.

Conclusion

This conclusion is for an article presenting web accessibility as a technical, legal, and commercial reality that no serious organization can afford to sidestep.

WCAG conformance, inclusive design, and assistive technology support are not separate initiatives. They are the same work, approached from different angles.

The POUR principles give structure. Screen reader testing reveals what automated tools miss. A published accessibility statement builds trust with users who need it most.

A web accessibility checklist is a practical starting point, but sustained compliance requires accessibility to be embedded in your design system, your build pipeline, and your team’s review process.

Digital inclusion is not a feature. It is the baseline.