Web Accessibility Testing: A Practical Guide for Growth Teams

Web accessibility evaluation goes by several names: assessment, audit and testing. Conformance evaluation determines how well pages or applications meet accessibility standards, most often the Web Content Accessibility Guidelines (WCAG). In practice, a test answers questions like these:

• Can someone operate navigation, dialogs, menus and forms without a mouse?

• Can screen reader users identify headings, controls, errors and meaningful images?

• Can visitors zoom or use a small screen without losing essential functionality?

• Can users perceive text, focus indicators and instructions with sufficient clarity?

If you want the concept in a sentence, our accessibility glossary entry defines it. The rest of this guide is the how.

‍

Know your standard before you test

A test needs a yardstick. In the United States, which one applies depends on who you are.

Federal agencies and contractors. Section 508 governs federal information and communication technology. The U.S. Access Board says its ICT Testing Baseline for Web sets minimum testing criteria for Section 508 conformance and incorporates WCAG 2.0 Level AA requirements. The Baseline is not itself a test process or a tool. It identifies what to test so organizations can build their own documented, tool-agnostic process.

State and local governments. The Department of Justice’s Title II rule, published April 24, 2024, requires covered web content and mobile apps to conform to WCAG 2.1 Level AA, subject to stated exceptions and defenses such as fundamental alteration or undue burden.

Private businesses. The standard that courts and demand letters reference is usually WCAG, most often Level AA. Our guide to ADA website compliance covers what covered entities must do. For testing purposes, the practical move is simple: pick a WCAG version and level, write it down, and test against it consistently.

If you are unsure which version to target, aim at the most recent one your counsel and your customers’ procurement teams accept. It is far easier to test once against a higher bar than to retest later.

Step 1: Run the quick checks first

Before any tooling, spend 30 minutes on a page. W3C’s Easy Checks give you quick steps to assess a few aspects of a page’s accessibility. They are not definitive, and a comprehensive evaluation needs more, but they surface obvious problems fast and teach your team what to look for.

A useful first pass on your homepage and one deep page:

• Confirm every page has a meaningful title and a logical heading hierarchy.

• Check text contrast, zoom to 200% and inspect responsive reflow.

• Review image alternatives and ensure decorative imagery is not announced as important content.

• Tab through navigation, forms, menus and dialogs without a mouse.

• Confirm labels, error messages and required fields are clear.

• Write down what fails. These are your first tickets.

Step 2: Scan with automated tools

Automated testing scans a digital product against predefined rules. Its big advantage is repeatability: it can be run quickly and often throughout the product lifecycle. That makes it ideal for catching regressions every time code ships.

There are a few kinds of automated tools, and most teams end up using more than one:

• Browser scanners: WAVE or axe DevTools can identify common markup and ARIA defects.

• Continuous integration rules: Run automated checks on representative templates and changed components during development.

• Contrast tools: Check text, control and indicator contrast against the target success criteria.

• Manual developer inspection: Review accessibility tree, focus management and programmatic labels.

WebAIM suggests using browser tools such as WAVE and developer tools to inspect code, accessible names and accessibility properties, and disabling extensions that alter presentation so results are accurate. The W3C also maintains a list of web accessibility evaluation tools you can filter by need. For contrast alone, a dedicated contrast checker is faster than eyeballing.

What automated tools miss

Tools are fast, but they are partial. Web.dev notes that tools do not catch all accessibility errors, can report false positives, and that multiple tools may be needed for different products and roles. Section508.gov says automated tools identify issues at scale but provide only partial coverage of the Section 508 Standards, and that context-dependent requirements need human judgment.

A scanner can tell you an image has alt text. It cannot tell you whether the text is meaningful. It can see that a button has a name. It cannot tell you whether the focus order makes sense. Treat a clean scan as a starting line, never a finish line.

Step 3: Test with a keyboard

Keyboard testing costs nothing and finds some of the most damaging barriers. Many people who use screen readers, switch devices or voice control, along with people who simply cannot use a mouse, depend on keyboard operability.

Set the mouse aside and work through the page:

• Use Tab and Shift+Tab to reach controls in logical sequence.

• Confirm a visible focus indicator appears on every interactive element.

• Operate menus, dialogs, tabs and buttons using standard keys, including Enter, Space and Escape where applicable.

• Check that no component traps keyboard focus and that focus returns appropriately after a dialog closes.

• Submit forms with errors and confirm focus and instructions make the problem understandable.

Web.dev’s manual testing checklist covers keyboard traps, logical focus order and visible focus, and extends to contrast on gradients or images, heading and landmark structure, animation, zoom, labels, link text, image alternatives, language changes and plain language. It is a good template for your own test script.

Step 4: Test with screen readers and on mobile

Once the keyboard path works, repeat your most important journeys with a screen reader. Use the combinations your audience actually uses, on desktop and mobile, and check:

• Check heading and landmark navigation for logical order.

• Confirm links and buttons have clear names, roles and states.

• Verify images, tables and form controls are announced meaningfully.

• Test validation errors, live updates and successful submission announcements.

• Repeat core journeys on mobile with touch targets, screen reader gestures and magnification.

For mobile, test touch and responsive behavior on representative devices rather than only a resized desktop window. Our note on responsive design explains why layout behavior across screen sizes matters for both usability and accessibility.

WebAIM cautions that WAVE and other automated tools identify only some issues, so pages should also be tested with a keyboard, a screen reader and developer tools. Plan on learning the basics of one screen reader well rather than skimming several.

Step 5: Involve people with disabilities

Disabled users reveal barriers no checklist predicts. The W3C says involving them has significant benefits but cannot alone determine WCAG conformance, so it should be combined with other evaluation methods.

Think of it as two kinds of evidence. Standards-based testing tells you whether you meet the criteria. User testing tells you whether real people can complete real tasks. You need both.

The CMS Section 508 developer toolkit points the same way: it asks teams to involve assistive-technology users and people with disabilities as subject-matter experts during design, research and testing. For a commercial site, that can mean recruiting participants for your next round of usability sessions and giving them the checkout or sign-up task.