Web Accessibility Testing Workflow: Audit WCAG Issues Before Every Release

Overview

Web accessibility testing is the process of checking whether people with different abilities can understand, navigate, and use a website or web application. It should be part of feature development and release testing, not a final inspection performed only after the interface is complete.

No single tool can identify every accessibility problem. Automated accessibility testing is useful for detecting patterns such as missing alternative text, invalid labels, duplicate identifiers, and some contrast failures. Manual testing is still needed for interaction order, meaningful link text, keyboard traps, error recovery, dynamic updates, and whether content makes sense when read aloud.

Use this workflow for a new page, a substantial component change, a regression pass, or a pre-release audit:

1. Define the page or user journey being tested.
2. Run automated checks against representative states.
3. Test the complete journey with a keyboard alone.
4. Inspect focus, semantics, forms, contrast, zoom, and motion preferences.
5. Perform a screen-reader spot check.
6. Record, prioritize, fix, and retest each issue.

Test more than the default view. Include open menus, dialogs, validation errors, empty states, loading states, logged-in and logged-out views, responsive layouts, and any content generated by JavaScript.

Checklist by scenario

1. Automated scan

• Run a browser accessibility extension or an equivalent automated test in development and in the deployed test environment.
• Scan representative templates rather than only the home page.
• Review every result instead of treating the tool's output as a final verdict. Some findings require human judgment, and some problems will not be detected.
• Include interactive states such as expanded navigation, open dialogs, error messages, and authenticated screens.
• Run accessibility checks in the project's automated test suite where practical, particularly for shared components.

Automated results should produce actionable tickets with the affected URL or component, steps to reproduce, expected behavior, actual behavior, and a suggested severity.

2. Keyboard-only navigation

• Put the mouse aside and use Tab, Shift+Tab, Enter, Space, and arrow keys where appropriate.
• Confirm that every interactive control is reachable and operable.
• Check that the focus order follows the visual and task order.
• Verify that focus is visible against the surrounding background.
• Open and close menus, dialogs, accordions, date pickers, carousels, and custom controls.
• Make sure users can escape an overlay and do not become trapped inside a component.
• After closing a dialog or menu, confirm that focus returns to a sensible control.

3. Semantic HTML and structure

• Use one appropriate page heading and a logical heading hierarchy.
• Prefer native elements such as button, a, input, select, and details when they provide the required behavior.
• Check landmarks such as header, navigation, main content, complementary content, and footer.
• Ensure links describe their destination and buttons describe their action.
• Provide alternative text for informative images and empty alternative text for decorative images.
• Check tables for appropriate headers and relationships, especially when data is complex.

4. Forms and validation

• Give every form control a programmatically associated label.
• Connect instructions, hints, required status, and error messages to the relevant field.
• Do not rely on color alone to identify invalid or successful input.
• Preserve entered values when validation fails where the workflow permits it.
• Place focus on a useful summary or the first invalid field after submission, and ensure the error is announced appropriately.
• Test autocomplete, password fields, file uploads, date inputs, and custom controls with both keyboard and assistive technology.

5. Visual presentation and motion

• Check text and essential interface elements against their backgrounds at normal and enlarged sizes.
• Zoom the page and verify that content remains usable without unwanted horizontal scrolling for the intended layout.
• Confirm that content is not hidden behind sticky headers, banners, or fixed controls when focused.
• Test a reduced-motion preference. Animations should not be necessary to understand or complete a task.
• Check hover, focus, active, disabled, selected, and error states independently.

6. Screen-reader spot check

Choose one desktop and one mobile-oriented journey that matters to users, then test it with a screen reader available in your target environments. Listen to the page title, headings, landmarks, form labels, button names, dialog announcements, status messages, and error text. The objective is not to certify every browser and assistive-technology combination; it is to catch missing context and broken interaction patterns that visual testing can overlook.

What to double-check

Use the following WCAG-oriented reference when reviewing findings. The criterion numbers are useful for organizing tickets, but always evaluate the actual user impact and the complete success-criterion wording used by your project's chosen conformance target.

For each issue, record: page or component, user impact, reproduction steps, expected result, actual result, relevant criterion, severity, owner, and retest status. A practical severity model is blocker, high, medium, and low. A keyboard trap, inaccessible checkout step, or unusable authentication flow usually deserves higher priority than a minor labeling inconsistency on a secondary page.

Keep testing evidence with the release. Screenshots, short recordings, automated reports, and browser or assistive-technology details make regressions easier to investigate. Accessibility work also fits naturally into front-end quality workflows alongside JavaScript debugging, performance checks, and deployment review. For related engineering routines, see the web performance optimization checklist and the web app deployment guide.

Common mistakes

• Relying only on an automated score: A clean scan does not prove that a task can be completed with a keyboard or understood by a screen-reader user.
• Testing only the default state: Menus, dialogs, validation errors, and dynamic updates often introduce the most serious issues.
• Using ARIA to replace native HTML: Custom widgets require additional keyboard behavior, focus management, and state updates. Start with native elements where possible.
• Removing focus outlines: If a design needs a different focus treatment, replace the outline with an equally clear indicator rather than hiding it.
• Checking contrast only on static text: Review links, icons, borders, placeholders, disabled-looking controls, selected states, and focus indicators according to the applicable requirement.
• Testing only one viewport: Responsive navigation, sticky elements, dialogs, and tables can behave differently on narrow screens.
• Fixing symptoms instead of components: If the same button, dialog, or form field fails repeatedly, repair the shared component and add a regression test.
• Leaving accessibility until launch: Late fixes can require changes to markup, interaction design, content, and automated tests. Include accessibility acceptance criteria during development.

When to revisit

Run the full workflow before a major release, after a redesign, and whenever navigation, authentication, checkout, forms, content structure, or interactive components change. Run a focused regression test for every pull request that changes a shared component. Recheck after browser, framework, design-system, or testing-tool changes because rendering and interaction behavior can shift.

Review the checklist during seasonal planning cycles and whenever your team changes its target browsers, assistive-technology coverage, WCAG conformance target, or release process. Update criterion references, tool commands, and browser notes when the standards or tools used by your team change. The goal is a maintained testing habit, not a one-time accessibility badge.

Release-ready checklist: scan representative pages; complete the critical journey by keyboard; verify visible focus and escape behavior; inspect headings, landmarks, names, labels, and alternative text; test forms and errors; review contrast, zoom, reflow, and reduced motion; perform a screen-reader spot check; prioritize and assign findings; then retest the fixes in the deployed environment.