Web Accessibility Testing Checklist: A Repeatable Workflow for Developers

Overview

Accessibility testing for websites works best as part of the normal frontend development workflow rather than as a final inspection. A scanner can identify useful patterns, but it cannot judge every interaction, content choice, or change in context. Manual testing is necessary for questions such as whether focus moves logically, whether an error is understandable, or whether a custom control behaves as users expect.

Use this checklist at three points: while building a component, during feature review, and before production release. Start with representative pages and important user journeys, such as signing in, searching, completing a form, purchasing, uploading a file, or contacting support. Record the page, issue, expected behavior, observed behavior, severity, and owner so accessibility findings enter the same issue-tracking process as functional defects.

This checklist is a practical implementation aid, not a substitute for the applicable WCAG requirements, product requirements, or testing with people who use assistive technology. Standards, browser behavior, frameworks, and testing tools change, so verify details against current guidance when a project has a formal compliance target.

Checklist by scenario

1. Keyboard navigation and focus

• Navigate the complete task using only the keyboard. Use Tab, Shift+Tab, Enter, Space, and arrow keys where appropriate.
• Confirm that every interactive control can receive focus and that the focus order follows the visual and task order.
• Check that focus is visible against the surrounding background. Do not remove the browser focus indicator without providing a clear replacement.
• Test menus, dialogs, date pickers, tabs, carousels, comboboxes, and custom dropdowns—not just links and buttons.
• When a dialog opens, move focus to a useful control inside it; when it closes, return focus to the control that opened it.
• Make sure users can leave every component. A keyboard user must not become trapped inside a modal, carousel, or embedded widget.
• Check skip links or another efficient route past repeated navigation on pages with substantial shared content.

2. Headings, landmarks, and page structure

• Give each page a useful, descriptive title and ensure it changes appropriately between routes or views.
• Use headings to describe sections and maintain a logical hierarchy. Do not choose a heading level only to obtain a visual size.
• Use semantic elements such as nav, main, header, footer, and form where they match the content.
• Check that repeated landmarks have distinguishing accessible names when more than one exists, such as multiple navigation regions.
• Confirm that content hidden visually is also hidden from assistive technology when it is not meant to be read, and that visible content is not accidentally removed from the accessibility tree.

3. Forms, labels, and errors

• Associate every input with a visible label. Placeholder text is not a reliable replacement for a label because it disappears and may have weak contrast.
• Explain required fields in text and expose the required state programmatically where appropriate.
• Give instructions before the user needs them, including accepted formats, character limits, and password rules.
• When validation fails, identify the field, describe the problem in plain language, and provide a specific correction.
• Make errors discoverable without relying only on color, and consider placing a summary at the top that links to invalid fields.
• Preserve entered values when validation fails unless there is a clear security reason not to.
• Test autocomplete, input types, grouped controls, and status messages with a keyboard and a screen reader.

4. Color, contrast, and visual presentation

• Check text, icons, borders, focus indicators, and controls against their backgrounds. Test text over images, gradients, hover states, and disabled-looking states separately.
• Do not use color as the only way to communicate status, selection, required fields, errors, or chart meaning. Add text, shape, pattern, or another distinguishable cue.
• Zoom the page and increase text size. Look for clipped content, overlapping controls, hidden actions, and horizontal scrolling that prevents normal use.
• Test high-contrast or forced-color settings where they are relevant to your audience and platform.
• Review dark mode and alternate themes independently; a color token that works in one theme may fail in another.

5. Images, media, and dynamic content

• Write concise alternative text for informative images. For decorative images, use an empty alternative attribute so assistive technology can skip them.
• For charts, diagrams, or infographics, provide the important conclusion or data in nearby text or an accessible data table.
• Give videos captions and provide a transcript when the content needs one. Ensure media controls are keyboard accessible and labeled.
• Pause, stop, or hide moving content when it distracts from the task. Avoid content that starts unexpectedly with sound.
• Announce important asynchronous updates, such as a successful save or a failed upload, without moving focus unnecessarily.

6. Responsive behavior and touch

• Test narrow and wide layouts, orientation changes, increased text size, and browser zoom.
• Confirm that menus, dialogs, tables, tooltips, and sticky elements remain usable at small viewport sizes.
• Make touch targets usable without requiring precise tapping, and ensure controls are not placed so closely that accidental activation is likely.
• Check that content does not depend on hover. Any hover-revealed information should have an accessible keyboard and touch equivalent.
• Test with slow connections or delayed API responses. Loading, empty, success, and error states should all be understandable and operable.

7. Screen-reader smoke test

• Read the page from the beginning and confirm that the title, landmarks, headings, links, buttons, form labels, and status messages make sense out of visual context.
• Navigate by headings and landmarks. Missing or misleading structure often becomes apparent quickly through these shortcuts.
• Activate the main user journey and listen for changes after opening a menu, submitting a form, filtering results, or receiving an error.
• Check that custom widgets expose their name, role, value, state, and available actions.
• Repeat the test with at least one browser and screen-reader combination supported by your product. Results can differ between combinations, so treat one successful smoke test as evidence, not full coverage.

What to double-check

Run an automated accessibility tool against rendered pages, not only source templates. Automated checks are useful for repeatable regressions such as missing labels, invalid relationships, and some contrast failures, but a clean report does not prove that a task is accessible. Keep tool configuration in the repository where possible, review false positives consistently, and fail a build only for findings the team understands and can act on.

Inspect component states, not just the default state. For each reusable component, review loading, disabled, selected, expanded, invalid, success, empty, and error states. This is especially important for JavaScript interfaces, where a visually correct state may not be exposed to assistive technology or may leave focus in the wrong place.

Check the rendered HTML and accessibility tree in browser developer tools. Look for the element's accessible name, role, value, and state. If a control is built from a non-interactive element, ask whether a native button, link, input, or select would provide the required behavior with less code. ARIA can help when native elements cannot meet the design, but it does not automatically add keyboard behavior or correct focus management.

Include accessibility in code review. A useful review comment identifies the user impact and the expected behavior—for example, “the error summary should link to each invalid field and move focus to the summary after submission”—rather than simply requesting an abstract compliance fix. For broader workflow improvements, compare this checklist with the frontend development workflow and toolchain guide.

Common mistakes

• Relying on a single scan: scanners cannot complete tasks, understand content, or verify every custom interaction.
• Removing focus outlines: replacing a visible indicator with a subtle color change makes keyboard progress difficult to track.
• Using placeholder text as a label: users lose the instruction as soon as they type, and the control may lack a reliable accessible name.
• Applying ARIA without behavior: adding a role does not create keyboard support, focus handling, or state updates.
• Testing only the happy path: validation errors, empty results, permission failures, and slow responses are part of the experience.
• Checking desktop only: zoom, narrow screens, touch, and alternate themes expose different failures.
• Fixing symptoms in isolation: if the same component fails across the product, fix the shared component and add a regression test.
• Leaving accessibility until release: late fixes can require changes to content, interaction design, component APIs, and automated tests at the same time.

When to revisit

Run the full checklist before a production release, redesign, or major dependency change. Revisit the relevant parts whenever a team adds a new interactive component, changes navigation, introduces a form, changes authentication, modifies color tokens, or replaces a browser-facing library. Repeat a focused test after fixing a defect to confirm that the correction works in context and did not break another state.

Review the checklist before seasonal planning or a new delivery cycle. Confirm that the browser and assistive-technology combinations in your support matrix still match your users, that automated rules are maintained, and that the project’s accessibility target remains documented. Check current WCAG and platform guidance when requirements, product scope, or supported environments change.

For the next release, turn this article into a small test plan: choose two representative journeys, run the automated checks, complete the keyboard path, inspect responsive states, perform a screen-reader smoke test, and log every finding with an owner. Pair accessibility findings with the same release workflow used for API, deployment, and regression testing; related process guidance is available in the modern frontend development workflow guide. A short, repeatable review is more useful than an occasional large audit that the team cannot maintain.