Accessibility Testing and Evaluation

What Accessibility Testing Is

Accessibility testing is the process of checking whether people with disabilities can perceive, understand, navigate, and operate a website, application, or document. In practice it means comparing the product against a recognized standard, most often the Web Content Accessibility Guidelines, and observing whether real tasks can be completed with a keyboard, a screen reader, magnification, voice control, and other assistive technology.

Testing answers a narrower question than people often expect. It does not decide whether a product is good, and it does not by itself decide whether an organization has met a legal obligation. It establishes what barriers exist, where they are, and how serious they are, so that they can be fixed and the fix can be confirmed.

For what the guidelines contain and how their conformance levels work, see WCAG Overview. This page covers how accessibility is actually evaluated.

Four Kinds of Evaluation

Accessibility evaluation draws on four distinct activities, and a sound evaluation keeps them separate. Automated testing uses software to scan code for patterns that are known to cause problems. Manual technical testing is performed by an evaluator who inspects the product against each requirement of the standard, using the keyboard, browser tools, and judgment.

Assistive technology testing uses the tools people with disabilities actually rely on, such as screen readers and screen magnifiers, to confirm that content is announced, reachable, and operable in practice. User testing, sometimes called usability testing, observes people with disabilities attempting realistic tasks and records where they succeed, struggle, or fail.

Each activity finds problems the others miss. Automated scans are fast and consistent but shallow. Manual review is thorough but depends on the evaluator. Assistive technology testing reveals how the pieces behave together. User testing shows whether the product is usable, not merely whether it passes. Reports that blur these categories make it difficult to know what was actually checked.

What Automated Checkers Can and Cannot Do

Automated checkers are valuable for finding common, machine-detectable faults across many pages at once: images with no text alternative, form fields with no programmatic label, missing document language, empty links, and many contrast failures. They are well suited to catching regressions when a site changes, and they make a sensible first pass.

The World Wide Web Consortium's Web Accessibility Initiative states plainly that no tool alone can determine whether a site meets accessibility standards, and that knowledgeable human evaluation is required. Software can report that an image has a text alternative; judging whether that text is an accurate account of the image is left to a person. It can confirm that a heading element is present, but not whether the headings describe the content or follow a logical order.

Many requirements cannot be evaluated by software at all, including whether the reading order makes sense, whether instructions are understandable, whether a custom control behaves as its role implies, and whether a keyboard user can complete a process without becoming trapped. A clean automated result means that one category of problem was not detected. It does not mean that the product is accessible.

Keyboard Access and Visible Focus

Keyboard testing is one of the most revealing checks and requires no special software. The evaluator sets the mouse aside and moves through the page with Tab, Shift and Tab, Enter, the Space bar, and the arrow keys, attempting every task a visitor would perform.

Every interactive element should be reachable and operable from the keyboard, and focus should never become trapped inside a component with no way out. The order in which focus moves should follow the meaning of the page rather than jumping unpredictably between regions. Menus, dialogs, carousels, and other scripted components are the usual sources of failure.

The evaluator also confirms that the location of focus is always visible. A clear focus indicator is how keyboard users know where they are. WCAG 2.2 added a requirement that the focused element not be entirely hidden by other content, such as a sticky header or cookie banner, which is a common problem on modern sites.

Headings, Structure, and Reading Order

Assistive technology relies on the underlying structure of a page, not its appearance. Evaluators check that headings are marked up as headings, that their levels reflect the real outline of the content, and that lists, tables, and regions such as navigation and main content are identified in the code.

Structure testing usually combines inspection with assistive technology. A screen reader's list of headings or landmarks shows quickly whether a page can be navigated by structure, and reading the page in code order shows whether content that looks sequential on screen is presented in a sensible sequence.

The same questions apply to documents. For how structure is carried in PDF, Word, and slide files, see Accessible Documents.

Forms, Instructions, and Error Handling

Forms are where many accessibility barriers become decisive, because an inaccessible form can prevent a person from applying, registering, paying, or asking for help. Evaluators confirm that every field has a label that is visible and programmatically associated with it, and that required fields and format expectations are stated before the user submits.

Error handling receives particular attention. When a submission fails, the error should be identified in text, associated with the field concerned, and announced to assistive technology, and where possible the message should suggest how to correct it. Relying on a red border alone, or clearing the form after an error, fails many users.

Evaluators also examine the whole process rather than individual fields: time limits, multi-step flows, confirmation pages, and authentication. WCAG 2.2 added requirements addressing information that users are asked to enter more than once and login processes that depend on memory or puzzle solving.

Links, Buttons, and Custom Controls

Every link and control needs an accessible name that describes its purpose, and that name should match or contain any visible label so that voice control users can activate it by saying what they see. Links whose text reads only as click here or more are difficult to use out of context.

Custom controls built with scripting, such as tabs, accordions, sliders, and date pickers, are tested against the behavior their role implies. The evaluator checks that each control exposes its name, role, and current state to assistive technology and responds to the expected keys. A component that looks like a button but is announced as plain text is a frequent failure.

Target size is also part of this review. WCAG 2.2 introduced a minimum target size requirement so that small, closely spaced controls do not defeat people with limited dexterity or tremor.

Images, Color, and Contrast

Evaluators review each meaningful image to confirm that its text alternative conveys the same information or function, and that decorative images are marked so that assistive technology skips them. Charts, maps, and diagrams need particular care, because a short description rarely carries all of the information they present.

Color and contrast are measured rather than estimated. WCAG sets minimum contrast ratios for text and for essential graphical elements such as control borders and focus indicators, and evaluators use contrast analyzers to check them. They also confirm that color is never the only way information is conveyed, for example in required-field markers, chart legends, or status messages.

Zoom, Reflow, and Responsive Layouts

Many people with low vision enlarge content rather than use a screen reader. Evaluators test whether text can be enlarged substantially without loss of content or function, and whether the page reflows into a single column at high zoom so that reading does not require scrolling in two directions.

Responsive layouts help, but they introduce their own problems: navigation hidden behind menus that cannot be opened from the keyboard, content that disappears at certain widths, and fixed headers that consume most of the screen when magnified. Testing at several zoom levels and viewport widths exposes these issues. Evaluators also check that adjusting text spacing, as some users do to improve readability, does not cause text to be cut off or overlap.

Screen Readers and Other Assistive Technology

Screen reader testing confirms how the product is actually experienced by people who are blind or have low vision. The evaluator navigates by headings, landmarks, links, and form fields, completes key tasks, and listens for missing names, confusing announcements, content that is skipped, and updates that happen silently.

Results vary between combinations of screen reader, browser, and operating system, so evaluators typically test with more than one widely used combination and record which were used. A problem that appears in only one combination is still a real barrier for the people who use it.

Other assistive technology matters as well. Screen magnification, voice control, switch access, and alternative keyboards each place different demands on a product. Testing with these tools requires skill. An evaluator unfamiliar with a screen reader can easily misread a working interface as broken, or the reverse, which is one reason experienced assistive technology users are so valuable in evaluation.

Media and Mobile Content

Video and audio require their own checks. Prerecorded video with sound needs accurate captions, audio-only content needs a transcript, and visual information that is not conveyed in the soundtrack needs audio description or an equivalent alternative. Automatic captions should be reviewed for accuracy before they are relied on. The media player itself must be operable from the keyboard and by assistive technology.

Mobile websites and native apps are evaluated with the same principles, applied to touch interfaces. Evaluators test with the screen readers built into mobile operating systems, check orientation, gesture alternatives, and target size, and confirm that content remains usable when system text size is increased. For how the guidelines are applied outside the web, the World Wide Web Consortium publishes informative guidance known as WCAG2ICT.

Scope, Standards, and Sampling

Every evaluation should state what was tested and against which standard. The scope identifies the product, version, and the pages, screens, or processes included. The standard is normally a specific WCAG version and conformance level, often WCAG 2.1 or 2.2 at Level AA, or the standard named in an applicable law, contract, or policy.

Comprehensive evaluation of every page is rarely practical for a large site, so evaluators test a representative sample. The World Wide Web Consortium's WCAG Evaluation Methodology, known as WCAG-EM, describes a structured approach: define the scope, explore the product, select a representative sample, evaluate the sample, and report the findings. A good sample includes the home page, templates, common components, complete processes such as checkout or registration, and a selection of pages chosen at random.

Sampling has limits that should be acknowledged. Findings describe the sample, not every page, and a report should make that clear. Content that varies widely, such as documents posted by many different authors, may need its own sampling plan.

Prioritizing, Remediating, and Retesting

Evaluations typically produce many findings, and they are not equally urgent. A common approach is to rate each issue by its impact on users and by how widely it occurs. A barrier that prevents a person from completing a core task, such as a checkout button that cannot be reached by keyboard, ranks above a cosmetic inconsistency on a rarely visited page.

Useful findings describe where the problem occurs, which requirement it affects, how it was identified, and what a correct result would look like. Recurring problems in shared templates or components are especially worth identifying, because fixing the source corrects every page that uses it.

Remediation is not finished until the fix has been retested. Retesting confirms that the problem is resolved, that the fix works with assistive technology, and that the change did not introduce new barriers elsewhere.

Involving People with Disabilities

Technical conformance and real usability are related but not identical. A product can meet many technical requirements and still be confusing or tiring to use with assistive technology, and people with disabilities often identify barriers that expert reviewers do not anticipate.

The Web Accessibility Initiative encourages involving users with disabilities throughout design and development, not only at the end. Including participants with a range of disabilities and assistive technology, giving them realistic tasks, and compensating them appropriately produces findings that checklists alone cannot. User testing complements conformance evaluation; it does not replace it, because a small group of participants cannot represent every disability or every configuration.

Reports, Statements, and Ongoing Testing

An evaluation report should record the scope, the standard, the date, the methods and tools used, the assistive technology combinations tested, and the findings with their priority. That record allows others to understand what the results mean and to repeat the evaluation later.

Many organizations also publish an accessibility statement that describes their commitment, the standard they aim to meet, known limitations, and how users can report a problem or request information in another format. A statement is a communication tool. It is not evidence of conformance unless it is backed by current evaluation.

Accessibility is not a one-time achievement. New content, redesigns, software updates, and third-party components can introduce barriers at any time. Organizations that sustain accessibility build checks into content publishing and development, test periodically, and retest after significant changes. For how evaluation results are documented for technology purchasing, see VPAT and Accessibility Conformance Reports.

Why a Tool or Overlay Cannot Establish Compliance

Claims that a site is simply ADA compliant deserve caution. No testing tool, scan score, badge, or certificate can by itself establish that an organization has met its legal obligations. Whether and how a law applies depends on the organization, the circumstances, and the standard that the relevant law, regulation, agreement, or policy references, and those questions are legal ones rather than technical ones.

Accessibility overlays and automated widgets are sometimes marketed as a shortcut. They typically add a script that attempts to detect and alter problems in the browser, or a toolbar of display adjustments. They do not correct the underlying code or content, they cannot reliably supply information the author never provided, such as accurate image descriptions or correct form labels, and they may conflict with the assistive technology people already use.

Testing is different in kind. It examines the product as it actually is, identifies specific barriers, and supports fixing them at the source. Durable accessibility comes from that cycle of evaluation, remediation, and retesting, not from a script added on top.

Related AssistiveTechnology.org Resources

For what the guidelines are and how conformance levels work, see WCAG Overview. For how WCAG relates to specific United States laws, see WCAG vs ADA vs Section 508, and for the practical differences between the two most recent versions, see WCAG 2.1 vs 2.2. For documents in every format, see Accessible Documents. For how evaluation results are reported for procurement, see VPAT and Accessibility Conformance Reports. For a general orientation to the subject, see Digital Accessibility, and for further reading across topics, see Resources.

Request accessibility services

Authoritative Sources

World Wide Web Consortium, Web Accessibility Initiative: Evaluating Web Accessibility Overview, including Easy Checks, Selecting Web Accessibility Evaluation Tools, and Involving Users in Evaluating Web Accessibility.

World Wide Web Consortium: WCAG Evaluation Methodology (WCAG-EM) 2.0, W3C Group Note, for scope, sampling, and reporting.

World Wide Web Consortium: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, and Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT), W3C Group Note.

U.S. General Services Administration, federal Section 508 program: ICT Testing Baseline Portfolio and the Trusted Tester program, for consistent federal testing methods.

Last Standards Review

Last standards review: September 24, 2026. On that date the statement that no tool alone can determine conformance, the WCAG-EM 2.0 status and methodology steps, the WCAG 2.2 requirements described here, and the federal testing resources named above were verified against current World Wide Web Consortium and federal Section 508 program sources.

About This Page

This page provides general educational information about accessibility testing and evaluation. It is prepared by The Accessibility Clinic Inc. as educational information only. It is not legal advice, and it does not guarantee that any specific website, application, document, or product meets a particular standard or legal requirement. Organizations should evaluate their own obligations in light of their specific circumstances and consult qualified counsel when needed. Standards and regulations change; the last standards review date above indicates when the statements on this page were most recently verified against primary sources.