Web Accessibility Testing Workflow: Check Keyboard Navigation, Forms, Contrast, and Screen Readers

Overview

Accessibility testing works best as a combination of automated checks, manual interaction, and assistive-technology testing. An automated scanner can identify patterns such as missing form labels, suspicious color contrast, duplicate IDs, or invalid ARIA usage. It cannot reliably determine whether a task is understandable, whether focus moves in a logical order, or whether a screen reader announcement makes sense. Those questions require a person to use the interface.

Use this checklist during component development, pull-request review, content migration, regression testing, and final release review. Test realistic flows rather than isolated screenshots: open the page, move through the navigation, submit a form, trigger validation, open a dialog, and recover from an error.

When evaluating a page against WCAG, record the relevant success criterion or internal requirement, but avoid treating a passing scanner as proof of full conformance. Requirements and browser or assistive-technology behavior can change, so verify the version of the guidance and tools used by your team.

Checklist by scenario

1. Keyboard navigation testing

Start with a page loaded at its default zoom and use the keyboard without a mouse. The exact keys may vary for custom widgets, but the following sequence exposes many common failures:

1. Press Tab repeatedly from the top of the page. Confirm that every interactive control receives focus and that the order follows the visual and functional reading order.
2. Check that the focused element is visibly identifiable. A subtle color change, browser-default outline hidden by CSS, or focus indicator visible only on part of a control is not sufficient for practical testing.
3. Use Shift+Tab to move backward. Confirm that focus does not jump unexpectedly or become trapped.
4. Activate links and buttons with the expected keyboard controls. Test menus, accordions, tabs, carousels, dialogs, date pickers, and other custom components.
5. Open each overlay, then attempt to move through its controls. Focus should move to an appropriate starting point, remain usable while the overlay is open, and return to a sensible element when it closes.
6. Look for keyboard traps. You should always be able to leave a component or continue to the next usable control without refreshing the page.

Also test at increased browser zoom and on a narrow viewport. A layout that works with a mouse at one screen size can become inaccessible when controls overlap, disappear, or require horizontal scrolling.

2. Forms and validation

• Every input should have a programmatically associated label. Placeholder text should not be the only label because it can disappear during entry and may have weak contrast.
• Group related controls, such as radio buttons, with an appropriate grouping label. Make required status and input expectations clear in visible text.
• Submit the form with empty fields, invalid formats, boundary values, and valid values. Check whether errors identify the affected field and explain how to correct it.
• Confirm that error messages are available to people who cannot see the position of a red border. Focus should move appropriately after submission, without making it difficult to review other fields.
• Preserve entered values when validation fails unless clearing them is necessary for safety. Test password fields, autocomplete behavior, date entry, and multi-step forms separately.
• Verify that instructions, labels, errors, and success messages are available in the same interaction model for mouse, keyboard, touch, and assistive-technology users.

3. Color, contrast, and visual presentation

Use a contrast checker as an initial signal, then inspect the interface manually. Check body text, links, placeholders, disabled-looking controls, icons that convey meaning, chart labels, focus indicators, and text placed over images or gradients. Do not rely on color alone for status, selection, errors, or required fields; add text, shape, position, or another perceivable cue.

Test hover, focus, active, selected, expanded, visited, and error states. A component can have acceptable default colors while losing its focus indicator or status distinction in another state. Review the layout with increased text size and browser zoom, and check whether content remains readable without clipping or overlapping.

4. Semantic HTML and screen readers

Inspect the page structure before adding ARIA. Use native HTML elements where they provide the required behavior: buttons for actions, links for navigation, headings for document structure, lists for grouped items, and form controls with labels. ARIA can describe custom behavior, but incorrect roles or states can make a working visual interface confusing to a screen reader.

Test a representative flow with a screen reader available to your team, such as VoiceOver, NVDA, or TalkBack. Listen for the page title, landmark regions, heading structure, link and button names, form labels, expanded or collapsed states, dialog names, and validation feedback. Navigate by headings or landmarks where supported. If the page is difficult to understand when the visual layout is removed, revisit its structure and accessible names.

5. Automated checks versus manual checks

Run automated checks early and repeatedly, but keep a short manual smoke test in every release checklist. For front-end work, this is often more useful than waiting for a large audit at the end of a project.

What to double-check

Pay particular attention to areas where CSS and JavaScript alter native behavior:

• Focus styling: Do not remove the outline without replacing it with a clearly visible equivalent. Test focus against every background and component state.
• Hidden content: Confirm that visually hidden text remains available where intended, while inactive panels and closed dialogs are not accidentally announced.
• Dynamic updates: Check whether loading states, validation messages, filters, toast notifications, and route changes are communicated without forcing users to search the page.
• Responsive layouts: Test orientation changes, narrow widths, increased text size, and reflow. Review any horizontal scrolling that is not essential to the content.
• Accessible names: Icon-only buttons need a meaningful accessible name. Avoid names such as “button,” “click here,” or a filename that does not describe the action.
• Third-party components: Treat widgets, embedded media, payment controls, and chat tools as part of the user journey. Test their keyboard and screen-reader behavior rather than assuming their documentation matches your implementation.

For a component issue, document the smallest reproducible example. Include the URL or branch, browser and operating system, assistive technology if used, steps to reproduce, expected behavior, actual behavior, impact, and a suggested severity. A practical template is:

Title:
Environment:
Steps to reproduce:
Expected behavior:
Actual behavior:
User impact:
Relevant WCAG or team criterion:
Suggested severity:
Evidence or recording:

Use severity consistently within your team. A keyboard trap, inaccessible primary action, or form that cannot be submitted deserves faster attention than a minor wording improvement, but the final priority should account for the affected workflow and release context.

Common mistakes

• Testing only the homepage: Accessibility defects often appear in authenticated areas, checkout flows, settings screens, empty states, and error paths.
• Using a mouse while claiming keyboard coverage: Keep the mouse and trackpad untouched during the keyboard pass, including when dismissing dialogs or correcting form errors.
• Replacing native controls unnecessarily: A styled button or select can require extensive keyboard, focus, state, and announcement work. Start with native HTML when it meets the design need.
• Adding ARIA without testing: Roles and states that do not match the actual interaction can create misleading output. Fix the underlying HTML and behavior first.
• Checking only default states: Test focus, hover, selected, disabled, loading, success, and error states. Accessibility problems frequently hide in transitions and conditional UI.
• Stopping after one automated pass: A scanner may miss a missing accessible name in context, a confusing reading order, or an interaction that cannot be completed without sight.
• Reporting vague defects: “Accessibility is broken” is difficult to act on. Record the exact control, steps, expected result, observed result, and user impact.

When to revisit

Repeat this workflow whenever a component, route, design system token, form, navigation pattern, or front-end dependency changes. Recheck after content migrations, responsive redesigns, authentication changes, major browser updates, and accessibility remediation. It is also useful before seasonal planning cycles when teams review release and regression processes.

Keep a small, versioned accessibility smoke-test checklist with the project. Update its WCAG references, browser matrix, screen-reader combinations, and automated tools at a defined review interval—such as every six months—or sooner when your standards or toolchain changes. Do not assume that a previously tested component remains unchanged if shared CSS or JavaScript has been modified.

For the next release, choose one realistic user flow and complete these steps: run an automated scan, perform the keyboard sequence, submit the key forms with invalid and valid data, inspect focus and contrast states, and listen through the flow with a screen reader. Log each issue using the template above, assign an owner, retest the fix, and keep the result with the release record. If layout behavior is the main concern, pair this review with a focused CSS Flexbox debugging workflow so responsive changes do not reintroduce focus, reflow, or visibility problems.