Web Accessibility Testing Workflow: WCAG Checks, Keyboard Audits, and Developer Tools

Overview

Accessibility testing is most reliable when it combines automated checks with human review. A website accessibility checker can identify common issues such as missing labels, duplicate IDs, invalid ARIA, and contrast problems, but it cannot fully judge whether a task is understandable or usable. Manual keyboard testing, screen-reader review, and realistic task testing are therefore essential parts of the process.

Use the workflow below as a practical WCAG checklist. It is designed for developers, QA professionals, content teams, and product owners who need a repeatable review rather than a one-time scan. Test representative pages and user journeys, including authentication, search, forms, menus, dialogs, checkout or payment flows, error states, and any workflow that changes content dynamically.

Before testing, define the target: the applicable WCAG version and conformance level for your project, the browsers and devices you support, and the page states that matter most. Record each finding with the URL, steps to reproduce, expected behavior, actual behavior, affected users or interaction mode, and a suggested fix. This makes accessibility work actionable instead of reducing it to a score.

Checklist by scenario

1. Start with semantic structure

• Confirm that each page has a descriptive and unique <title>.
• Use one clear main heading and organize content with logical heading levels.
• Use landmarks such as header, nav, main, and footer where they describe the page structure.
• Use native HTML controls for buttons, links, lists, tables, forms, and disclosures before reaching for custom elements or ARIA.
• Check that link text makes sense without relying only on nearby visual context.
• Verify that images have appropriate alternative text. Decorative images should not create unnecessary screen-reader output.
• Make sure form controls have programmatically associated labels, instructions, and error messages.

Inspect the accessibility tree in browser developer tools to see how the browser exposes names, roles, states, and values. This is often more useful than inspecting the visual DOM alone.

2. Run a keyboard accessibility test

Disconnect the mouse and complete important tasks with the keyboard. Use Tab, Shift+Tab, Enter, Space, and arrow keys where appropriate.

• Every interactive element should be reachable without a mouse.
• The focus order should follow a sensible reading and task sequence.
• Focused elements should have a visible indicator that is not removed by a global outline reset.
• Menus, dialogs, carousels, date pickers, and custom widgets should support expected keyboard commands.
• A keyboard user must be able to close overlays and return focus to the control that opened them.
• No component should trap focus unexpectedly or allow focus to disappear behind a modal.
• Skip links or equivalent navigation shortcuts should work when repeated navigation would otherwise be burdensome.

Keyboard accessibility testing is especially important after adding a JavaScript component. A control may look correct while lacking a focus target, keyboard event handling, or a usable focus-return pattern.

3. Review visual presentation and contrast

• Check text and essential graphics against their background in normal, hover, focus, disabled, and error states.
• Do not communicate meaning through color alone. Pair color with text, icons, patterns, or another clear cue.
• Zoom the page and test responsive layouts for clipped text, overlapping controls, and hidden content.
• Check text spacing, line wrapping, and reflow on narrow viewports.
• Verify that focus indicators remain visible against every background used by the component.
• Review motion, auto-updating content, and animations. Users should have a way to pause, stop, or avoid distracting movement when the interaction requires it.

Contrast tools are useful for individual color pairs, but they do not replace a complete visual review. Test the actual component states rather than a design token in isolation.

4. Test with a screen reader

Choose a supported browser and screen reader combination used by your audience or organization. You do not need to test every possible pairing at the beginning; start with a consistent combination, then expand coverage for important workflows.

• Navigate by headings, landmarks, links, form controls, and reading order.
• Confirm that controls announce an understandable accessible name and state.
• Check that dynamically inserted content, validation errors, and status messages are announced when necessary.
• Verify that dialogs identify themselves and that the user can locate their content and controls.
• Listen for repeated, irrelevant, or missing text caused by incorrect ARIA or duplicated labels.
• Complete a realistic task from start to finish without relying on visual clues.

Screen-reader testing should focus on outcomes. Ask whether a person can understand what changed, what is required, what went wrong, and what action is available next.

5. Use automated accessibility testing tools

Run an automated scanner against representative pages and states. Common options include browser auditing tools, extensions such as axe-based checkers, and web accessibility checkers that inspect a page for detectable issues. A simple comparison can help you choose the right role:

Use automated results to find and prevent regressions, not to declare a site accessible. Review each finding, remove false positives carefully, and add a manual test for issues that automation cannot evaluate.

What to double-check

Forms and validation

Test required fields, invalid formats, server-side errors, autocomplete behavior, and recovery from mistakes. Error text should identify the affected field and explain how to fix it. When validation occurs dynamically, confirm that the error is visible and available to assistive technology without forcing the user to search the page.

Dialogs, menus, and dynamic content

For a dialog, check opening, initial focus, keyboard navigation, closure, and focus return. For menus and disclosure widgets, confirm that the control exposes its expanded or collapsed state and that the content is reachable in the expected order. Test loading indicators, toast messages, filtered results, and infinite scrolling with both keyboard and screen-reader interaction.

Responsive and touch layouts

Review small screens, landscape orientation, increased text size, and browser zoom. Make sure controls do not become too crowded to operate and that important content is not available only through hover. Test touch targets and gestures where they are central to the experience, while preserving an alternative interaction method.

Content and language

Check that the document language is declared correctly and that changes in language within the page are identified where needed. Use plain, specific instructions, descriptive headings, meaningful button labels, and consistent terminology. Accessibility defects often come from content changes made after the original interface was tested.

Common mistakes

• Relying on a single score: An automated percentage cannot represent the full experience of navigating a site with a keyboard or screen reader.
• Using ARIA to repair everything: Incorrect ARIA can create a less accurate accessibility tree. Start with native HTML and add ARIA only when its role and state are understood.
• Testing only the home page: Forms, account areas, search results, and error states often contain different accessibility risks.
• Removing focus outlines: Replace a default focus style only when the replacement is equally clear in every state.
• Checking source but not behavior: Valid markup does not guarantee a usable interaction. Test the rendered page and the complete task.
• Fixing symptoms in isolation: If the same unlabeled component appears across the product, fix the shared component or design system rather than patching each page.
• Leaving accessibility until the end: Add automated checks to development and review component behavior before it spreads across the application.

When to revisit

Run a focused accessibility review before each major release, redesign, template change, or component-library update. Repeat the full workflow when navigation, authentication, forms, checkout, search, or other core journeys change. Also revisit after browser, framework, or testing-tool updates when those changes affect rendering, focus management, or accessibility-tree behavior.

Keep a small regression checklist in the repository or QA system. At minimum, include page structure, keyboard completion of critical tasks, visible focus, contrast states, form errors, dialog behavior, screen-reader announcements, and automated scan results. Assign each issue an owner and retest the exact scenario after the fix.

For the next release, choose three representative journeys and run this sequence: scan them automatically, complete them by keyboard, inspect their accessibility tree, test one with a screen reader, and record unresolved issues. That practical loop gives the team evidence to act on and a stable baseline to compare when the product changes.