What Is Web Accessibility Testing and Why Does It Matter?
Web accessibility testing is the process of ensuring that websites and applications can be effectively used by all users, including people with disabilities. According to the World Health Organization, approximately 16% of the global population lives with some form of disability. This reality makes accessibility not just an ethical responsibility, but also a legal requirement and a sound business strategy.
The European Accessibility Act (EAA), the Americans with Disabilities Act (ADA), and Section 508 all mandate digital accessibility. Since 2025, all businesses operating in the EU must ensure their websites are accessible. Non-compliance can result in lawsuits, fines, and reputational damage.
Understanding WCAG 2.2 Standards
The Web Content Accessibility Guidelines (WCAG) 2.2 is the latest accessibility standard published by the W3C. It is built on four fundamental principles known as POUR:
1. Perceivable
Information and user interface components must be presentable to users in ways they can perceive:
- Provide text alternatives for non-text content
- Provide alternatives for time-based media
- Create content that can be presented in different ways
- Make it easier for users to see and hear content
2. Operable
User interface components and navigation must be operable:
- Make all functionality available from a keyboard
- Give users enough time to read and use content
- Do not design content in a way that causes seizures
- Provide ways to help users navigate and find content
3. Understandable
Information and the operation of the user interface must be understandable:
- Make text content readable and understandable
- Make web pages appear and operate in predictable ways
- Help users avoid and correct mistakes
4. Robust
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.
New Success Criteria in WCAG 2.2
WCAG 2.2 introduced nine new success criteria that address gaps in the previous version. The most significant additions include:
| Criterion | Level | Description |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Focused element must be at least partially visible |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | Focused element must be fully visible |
| 2.4.13 Focus Appearance | AAA | Focus indicator must have sufficient size and contrast |
| 2.5.7 Dragging Movements | AA | Functions requiring dragging must offer alternatives |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets must be at least 24x24 CSS pixels |
| 3.2.6 Consistent Help | A | Help mechanisms must be in consistent locations |
| 3.3.7 Redundant Entry | A | Previously entered information should not be re-requested |
| 3.3.8 Accessible Authentication (Minimum) | AA | Authentication without cognitive function tests |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | Authentication without even object recognition |
Conformance Levels: A, AA, and AAA
WCAG defines three conformance levels:
- Level A: The most basic accessibility requirements. Sites failing this level are inaccessible to many users.
- Level AA: The standard level required by most regulations. This is the minimum target for businesses.
- Level AAA: The highest accessibility level. While not feasible for entire sites, specific content can target this level.
Automated Testing Tools
axe DevTools
Developed by Deque Systems, axe is the most popular open-source accessibility testing tool. It runs as a browser extension and automatically detects accessibility issues on web pages.
Key features of axe:
- Zero false-positive rate as a core design goal
- Support for WCAG 2.0, 2.1, and 2.2 rules
- Integration with CI/CD pipelines via axe-core
- Chrome, Firefox, and Edge extensions
- Programmatic access through the axe-core npm package
Google Lighthouse
Built into Chrome DevTools, Lighthouse is a comprehensive auditing tool covering performance, SEO, and accessibility. The accessibility score ranges from 0-100 and includes checks for:
- Color contrast sufficiency
- Presence of alternative text
- Correct usage of ARIA attributes
- Form labels and associations
- Document language declaration
WAVE (Web Accessibility Evaluation Tool)
Developed by WebAIM, WAVE is a free tool that displays accessibility issues directly on the page using visual icons. It marks errors, warnings, and best practices with different colors and symbols.
Pa11y
Pa11y is a command-line accessibility testing tool that integrates easily into CI/CD workflows. It is ideal for creating automated test scenarios and running accessibility checks in build pipelines.
Automated testing tools can detect only 30-40% of accessibility issues. A comprehensive accessibility evaluation must always include manual testing alongside automated tools.
Screen Reader Testing
Screen readers are assistive technologies used by visually impaired users to access web content. The most common screen readers include:
NVDA (NonVisual Desktop Access)
A free, open-source screen reader for Windows. It is one of the most popular tools for accessibility testing. When testing with NVDA, pay attention to:
- Correct reading of page headings and structural elements
- Recognition of form field labels
- Announcement of dynamic content updates
- Logical reading order of table data
VoiceOver
Built into Apple devices, VoiceOver is used for testing on macOS and iOS. It works best with Safari and provides comprehensive gesture-based navigation on mobile devices.
JAWS (Job Access With Speech)
A commercial screen reader widely used in enterprise environments. JAWS works best with Internet Explorer and Chrome and offers extensive customization options.
Keyboard Navigation Testing
Keyboard accessibility is critically important for users with motor disabilities and screen reader users. Key aspects to verify during keyboard testing:
Essential Keyboard Interactions
- Tab: Move focus forward through interactive elements
- Shift + Tab: Move focus backward
- Enter/Space: Activate buttons and links
- Arrow keys: Navigate within menus and tab panels
- Escape: Close modals and dropdown menus
Keyboard Traps
A keyboard trap occurs when a user cannot navigate away from a component using the keyboard. This is one of the most serious accessibility violations. Pay special attention to:
- Modal dialogs and overlays
- Video players
- Rich text editors
- Date pickers and custom components
Focus Management
A visible focus indicator is essential for keyboard users. When customizing focus styles with CSS, use the :focus-visible selector to display focus rings only during keyboard navigation, avoiding unnecessary outlines during mouse interactions.
ARIA Roles and Attributes
Accessible Rich Internet Applications (ARIA) is a specification for adding additional semantic information to HTML elements. When used correctly, ARIA significantly improves accessibility.
Essential ARIA Roles
| Role | Use Case | Example |
|---|---|---|
| role="navigation" | Navigation regions | Main menu, breadcrumb |
| role="main" | Main content area | Page body |
| role="complementary" | Supplementary content | Sidebar |
| role="alert" | Important notifications | Error messages |
| role="dialog" | Dialog windows | Modal windows |
| role="tablist" | Tab groups | Tabbed interfaces |
ARIA States and Properties
- aria-label: Provides an accessible label for an element
- aria-labelledby: References another element as the label
- aria-describedby: References an element providing additional description
- aria-expanded: Indicates the expanded/collapsed state of a component
- aria-hidden: Hides an element from assistive technologies
- aria-live: Announces dynamic content updates
The first rule of ARIA: If a native HTML element or attribute serves the same purpose, do not use ARIA. For example, using
<div role="button">instead of<button>is the wrong approach.
Building an Accessibility Testing Strategy
An effective accessibility testing strategy requires a combination of automated and manual testing:
- During development: Linter rules and automated tests for early detection
- During code review: Accessibility checklist reviews
- During QA: Comprehensive manual tests and screen reader testing
- Post-launch: Regular audits and user feedback collection
- Ongoing: Usability testing with real users with disabilities
Conclusion
Web accessibility is not a one-time task but a continuous process. Achieving WCAG 2.2 compliance fulfills legal requirements and expands your audience reach. By building a comprehensive testing strategy that starts with automated tools and continues with manual testing and real user feedback, you can create web experiences that are truly accessible to everyone.
