Accessibility Testing and Auditing
Accessibility testing checks whether people with disabilities can perceive, operate, and understand a digital product. An audit turns evidence from automated checks, manual interaction, assistive technology, and standards review into findings that teams can reproduce and fix.
itWeb development | OpenSkills.info
Intro
Accessibility Testing and Auditing
Accessibility testing examines whether disabled people can use a digital product and whether the product meets defined accessibility requirements. An accessibility audit is a structured evaluation with a stated scope, method, evidence, findings, and conclusion. Testing produces observations. Auditing connects those observations to requirements and records what was examined.
For web work, the usual requirements baseline is the Web Content Accessibility Guidelines, or WCAG. WCAG 2.2 organizes guidance under four principles: perceivable, operable, understandable, and robust. Its testable success criteria have levels A, AA, and AAA. A target such as “WCAG 2.2 Level AA” includes every applicable Level A and Level AA success criterion.
Conformance is broader than a passing scan. WCAG conformance applies to full pages, complete processes, and every relied-upon technology. A checkout flow cannot conform when its cart page passes but its payment step blocks keyboard use. A widget-level test is valuable regression evidence, but it is not a site-level conformance claim.
The evaluation system
An effective audit has five connected parts:
- Requirements define what counts as a pass. These can include WCAG, procurement standards, organizational policies, and product-specific acceptance criteria.
- Scope identifies the pages, states, user journeys, technologies, and conformance target under evaluation.
- Test methods combine automated rules, inspection, keyboard operation, viewport and zoom checks, and assistive-technology use.
- Evidence records the tested environment, steps, actual behavior, expected behavior, affected code or interface, and requirement mapping.
- Reporting and retesting turn findings into repair work, then confirm whether fixes resolve the barrier without introducing regressions.
These parts form a control loop. The scope selects representative content and complete processes. Test methods expose barriers within that scope. Evidence makes each result reproducible. Remediation changes the product. Retesting checks the changed behavior against the same requirement.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.w3.org/TR/WCAG22/
Supports
- WCAG 2.2 principles, success criteria, conformance levels, and normative definitions
- Full-page, complete-process, accessibility-supported, and non-interference conformance requirements
- Level AA requiring all applicable Level A and Level AA success criteria
- https://www.w3.org/WAI/test-evaluate/
Supports
- Evaluation as a combination of tools and knowledgeable human review
- Distinct resources for preliminary review, conformance evaluation, tool selection, user involvement, and reporting
- Automated tools not determining accessibility by themselves
- https://www.w3.org/TR/2014/NOTE-WCAG-EM-20140710/
Supports
- Defining evaluation scope, exploring a website, selecting representative samples, auditing samples, and reporting findings
- Inclusion of common pages, essential functionality, different page types, technologies, and complete processes
- Boundaries and documentation needs of sampled conformance evaluation
- WCAG-EM 1.0 publication on 10 July 2014
- https://www.w3.org/WAI/test-evaluate/preliminary/
Supports
- Preliminary checks for titles, headings, contrast, alternatives, keyboard access, forms, and media
- Need for human judgment about meaningful alternatives and page behavior
- https://www.w3.org/WAI/WCAG22/quickref/
Supports
- Filterable progression from success criteria to sufficient techniques, advisory techniques, and failures
- Use of techniques as implementation and testing guidance rather than the normative conformance basis
- https://www.w3.org/WAI/standards-guidelines/act/rules/about/
Supports
- ACT Rules as informative checks of specific aspects of WCAG or ARIA requirements
- Passed, failed, and inapplicable examples and partial-check boundaries
- WCAG success criteria rather than ACT Rules as the normative conformance basis
- https://www.w3.org/WAI/standards-guidelines/act/rules/
Supports
- Approved and proposed automated, semi-automated, manual, and linter rules
- Rule organization across WCAG guidelines and ARIA requirements
- https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/
Supports
- Browser keyboard behavior not being supplied automatically for custom ARIA widgets
- Focus movement, visible focus, keyboard conventions, and pointer-focus coordination
- https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
Supports
- ARIA roles not creating keyboard behavior or styling
- Need to test APG-derived code with supported browsers and assistive technologies
- https://www.w3.org/WAI/test-evaluate/involving-users/
Supports
- Disabled-user involvement as evidence about barriers and tasks rather than a conformance determination
- Limits on generalizing from a participant group to all people with disabilities
- https://www.ibm.com/able/toolkit/verify/automated/
Supports
- Automated checking as an efficient first verification layer
- Needs Review results requiring resolution before manual and screen-reader verification continues
- Automated checks covering only a subset of requirements and needing manual follow-up
- https://github.com/lukeslp/awesome-accessibility
Supports
- Discovery of axe-core, Pa11y, Accessibility Insights, Sa11y, and Editoria11y as accessibility testing and validation projects
- Wider accessibility testing ecosystem used for Awesome Links curation
- https://github.com/dequelabs/axe-core
Supports
- Open-source accessibility rules engine and integrations for automated testing
- Automated rule results requiring manual review for broader accessibility coverage
- Free Mozilla Public License distribution
- https://pa11y.org/
Supports
- Command-line and Node.js accessibility testing for one-off checks and automation
- Pa11y as a free open-source project
- https://accessibilityinsights.io/docs/web/overview/
Supports
- FastPass and Assessment workflows combining automated checks and guided manual testing
- Open-source, no-cost browser tooling for web accessibility evaluation
- https://sa11y.netlify.app/
Supports
- Visual in-page quality-assurance feedback for content authors
- Customizable, framework-agnostic checks and explicit limits on comprehensive code analysis
- Free open-source availability
- https://editoria11y.princeton.edu/
Supports
- In-context accessibility checking for content editors and content-managed pages
- Checks for alternative text, headings, links, tables, and other editorial patterns
- https://developer.chrome.com/docs/lighthouse/
Supports
- Accessibility audits available in Chrome DevTools, command-line, and Node workflows
- Reports that use failed audits as indicators for improvement
- Free open-source Lighthouse availability
- https://wave.webaim.org/
Supports
- Browser, online, API, and testing-engine accessibility evaluation modes
- Automated findings alongside facilitated human evaluation
- Free browser and online checks with paid API and enterprise options
- https://wave.webaim.org/extension/
Supports
- Local rendered-page evaluation of protected, dynamic, local, and sensitive pages
- https://www.siteimprove.com/platform/accessibility/web-accessibility-software/
Supports
- Proprietary platform for site scanning, prioritized findings, code checking, snapshots, and manual testing reports
- Enterprise accessibility workflow requiring commercial access
- https://www.tpgi.com/arc-platform/
Supports
- Proprietary platform combining page and flow scans, dashboards, manual engagements, developer integrations, and reporting
- Commercial access through a sales engagement
- https://www.browserstack.com/docs/accessibility/test-types
Supports
- Proprietary accessibility testing for workflows, assisted tests, screen readers, and site scanning
- Commercial BrowserStack platform access
- https://www.levelaccess.com/
Supports
- Proprietary platform combining automated scans, expert evaluation, remediation workflow, governance, and reporting
- Commercial access through a customized demonstration
- https://www.w3.org/press-releases/1999/wcag/
Supports
- WCAG 1.0 publication as a W3C Recommendation on 5 May 1999
- Checkpoints and priority levels establishing a shared evaluation baseline
- https://www.w3.org/press-releases/2008/wcag20/
Supports
- WCAG 2.0 publication as a W3C Recommendation on 11 December 2008
- Technology-neutral, more precisely testable guidance and supporting evaluation materials
- https://www.w3.org/press-releases/2014/aria/
Supports
- WAI-ARIA 1.0 publication as a W3C Recommendation on 20 March 2014
- Standardized semantics for dynamic and interactive web content exposed to accessibility software
- https://www.access-board.gov/ict/preamble.html
Supports
- Revised Section 508 final rule publication on 18 January 2017
- Required federal compliance date of 18 January 2018
- Coordination with W3C and international accessibility standards
- https://www.w3.org/news/2018/web-content-accessibility-guidelines-wcag-2-1-is-now-a-w3c-recommendation/
Supports
- WCAG 2.1 publication as a W3C Recommendation on 5 June 2018
- Expanded guidance for mobile, low vision, and cognitive and learning disabilities
- https://www.w3.org/WAI/news/2019-10-31/act-rules-format-is-a-web-standard-w3c-recommendation/
Supports
- ACT Rules Format 1.0 publication as a W3C Recommendation on 31 October 2019
- Shared format for automated and manual accessibility test rules
- https://www.w3.org/news/2023/web-content-accessibility-guidelines-wcag-2-2-is-a-w3c-recommendation/
Supports
- WCAG 2.2 publication as a W3C Recommendation on 5 October 2023
- Addition of nine success criteria addressing visual, physical, and cognitive accessibility
