Web accessibility testing is most effective when it is treated as a repeatable release check rather than a one-time scan. This guide gives developers a practical website accessibility checklist covering keyboard access, headings, forms, contrast, focus, dialogs, screen readers, and recurring review points.
Overview
Accessibility testing checks whether people can understand, navigate, operate, and submit information through a website using different input methods and assistive technologies. It is also closely connected to technical quality: clear document structure, descriptive links, usable forms, meaningful page titles, and correctly exposed interface states make a site easier to maintain and easier for search engines and other software to interpret.
No single browser extension or automated report can establish that a page is accessible. Automated tools are useful for identifying detectable issues such as missing labels, insufficient contrast, duplicate identifiers, or invalid ARIA patterns. Manual testing is still needed for interaction order, keyboard traps, focus behavior, error recovery, reading sequence, and whether the interface makes sense to a person using assistive technology.
Use the following process for a representative set of templates and user journeys. Test the homepage, navigation, search, account or checkout flows, content pages, modals, error states, and any feature added since the last review. Record the URL, component or step, observed behavior, expected behavior, severity, and a reproducible fix recommendation.
What to track
1. Page structure and reading order
Start with the page’s semantic structure before examining visual styling. Check that each page has a useful, unique title and that the main content is identifiable. Headings should describe the content that follows and progress in a logical hierarchy. Do not choose a heading level solely because it produces the desired font size; use CSS for presentation and heading elements for structure.
Review landmarks such as header, navigation, main content, complementary content, and footer. A repeated navigation region should have a clear accessible name when multiple regions could otherwise be confused. Check that link text describes its destination. Links such as “read more” or “click here” are difficult to distinguish when encountered out of context.
2. Keyboard accessibility testing
Put the mouse aside and complete the primary journey with a keyboard. Use Tab and Shift+Tab to move through controls, Enter or Space to activate them, and the arrow keys where a widget requires them. Test menus, accordions, carousels, date pickers, custom selects, tables, dialogs, and rich text controls rather than limiting the test to ordinary links and buttons.
Track whether every interactive control can receive focus, whether the focus order follows the task, and whether focus remains visible against the surrounding design. A user should never become trapped inside a component or lose access to content because focus moves to an unexpected location. When a dialog opens, focus should move into the dialog; when it closes, focus should return to the control that opened it unless there is a clear reason to do otherwise.
3. Focus, hover, and state changes
Inspect focus styles in every relevant state, including links on dark backgrounds, buttons inside cards, form controls, and elements with sticky headers nearby. Do not rely on color alone to communicate focus, selection, validation, or status. Hover-only information should have an equivalent keyboard-accessible behavior, and content that appears on focus should not disappear before a user can reach it.
For dynamic interfaces, observe what happens after an action. Does a filter update announce or otherwise expose the result? Does a loading state communicate that work is in progress? Does a successful save become clear without requiring the user to search the page? These questions are especially important for single-page applications where the URL, document, or visible content may not change in the usual way.
4. Forms and error recovery
Every form control needs a visible, programmatically associated label. Placeholder text is not a reliable replacement for a label because it can disappear and may not provide enough context. Group related controls, such as radio buttons, with an appropriate group label, and make required fields and input instructions clear before submission.
Submit incomplete and incorrectly formatted data deliberately. Check that errors are written in plain language, identify the affected field, explain how to correct it, and remain available after submission. The error should be exposed to assistive technology and focus should move in a predictable way, often to the first invalid field or to a concise error summary. Preserve valid input so the user does not need to start again.
5. Color and visual presentation
Use a color contrast checker as an indicator, then confirm the result in the actual component states. Check normal text, large text, placeholder text, icons that convey meaning, borders that identify controls, disabled or unavailable states, focus indicators, and text over images or gradients. A contrast pass for the default state does not guarantee a pass for hover, focus, error, or dark-mode variants.
Test zoom and responsive layouts. Content should remain readable and usable when text is enlarged or the viewport becomes narrow. Look for clipped labels, overlapping controls, horizontal scrolling that blocks tasks, and interfaces whose fixed elements cover the focused control. Also confirm that information is not lost when styles are disabled or when the page is viewed with a different text size.
6. Screen reader checks
Choose a supported browser and screen reader combination used by your team or audience, and document the combination because behavior can differ between environments. Navigate by headings and landmarks first, then move through links, buttons, form fields, tables, dialogs, and status messages. Listen for missing names, duplicated announcements, meaningless icon labels, incorrect roles, and state changes that are visible but not announced.
Do not add ARIA to compensate for missing native HTML. A real button usually provides more dependable keyboard and accessibility behavior than a styled div with a click handler. When custom widgets are necessary, test their complete interaction model: name, role, value, keyboard commands, expanded or selected state, focus movement, and update announcements.
7. A compact issue reference
| Area | What to check | Typical evidence |
|---|---|---|
| Keyboard | All tasks work without a pointer and there is no keyboard trap. | Tab sequence, activation method, escape behavior, focus destination. |
| Headings | Structure reflects the content and headings are meaningful. | Heading outline, page title, landmark navigation. |
| Forms | Controls have labels and errors identify a corrective action. | Label association, required state, error summary, preserved input. |
| Contrast | Text, controls, and important states remain distinguishable. | Contrast results for default, hover, focus, error, and dark themes. |
| Dialogs | Opening, interaction, dismissal, and return focus are predictable. | Focus enters the dialog and returns to the invoking control. |
| Screen reader | Names, roles, values, structure, and updates are exposed. | Announcements during navigation, submission, filtering, and loading. |
Cadence and checkpoints
Run a focused accessibility check during development, a broader regression pass before release, and a scheduled review after launch. A monthly or quarterly cadence is useful for sites that publish frequently, while high-change applications may need checks in every feature cycle. The right interval depends on release volume, component reuse, and the consequences of an inaccessible workflow.
At minimum, create checkpoints for:
- New templates, navigation systems, design-system components, and JavaScript widgets.
- Changes to forms, authentication, checkout, search, filtering, or account management.
- Content migrations that alter headings, links, tables, images, or embedded media.
- Responsive redesigns, new themes, dark mode, localization, and typography changes.
- Browser, operating-system, browser-extension, or screen-reader changes that affect the team’s supported test setup.
- Incidents or support reports describing a blocked task, missing label, lost focus, or unusable error state.
Keep a small regression suite for critical journeys. For each journey, record the starting URL, required data, keyboard steps, expected focus locations, expected announcements, and the evidence needed for sign-off. This turns accessibility from an informal opinion into a repeatable engineering check.
How to interpret changes
Compare results by component and user journey, not only by the number of automated warnings. A change from one release to the next may reflect a genuinely new defect, a newly tested template, a tool configuration change, or a browser and assistive-technology behavior difference. Preserve the testing environment and reproduction steps so the comparison remains meaningful.
Prioritize issues that block a primary task, affect many pages through a shared component, remove keyboard access, hide focus, prevent form recovery, or provide incorrect information to assistive technology. A small visual defect can deserve urgent attention when it makes a control impossible to locate or operate. Conversely, avoid treating every warning as equally important without confirming its effect in the rendered interface.
When a defect is fixed, retest the original failure and nearby states. A focus fix may affect scrolling; a label change may affect localization; a dialog repair may alter the return destination; and a contrast adjustment may create a problem in another theme. Update the regression notes with the fix, the tested environment, and any remaining limitation rather than marking the issue complete without evidence.
When to revisit
Revisit this guide and your checklist on a monthly or quarterly schedule, and immediately when a product or platform change affects interaction. Accessibility guidance, WCAG references, browser behavior, screen-reader output, design-system components, and testing tools can evolve. Treat this article as a process reference, then confirm the specific success-criterion interpretation and tool instructions relevant to your current project.
Before each release, choose representative pages and complete this short pass:
- Run an automated scan, then verify each meaningful result in the browser.
- Navigate the primary journey by keyboard from start to finish.
- Check headings, landmarks, link names, labels, errors, focus visibility, and dialog behavior.
- Test contrast and responsive presentation in every important visual state.
- Repeat critical steps with a screen reader and record unexpected announcements.
- Review open accessibility defects, retest resolved issues, and log any changed assumptions.
For a broader pre-launch review, combine this checklist with a technical SEO audit such as the technical SEO pre-launch checklist. Keep accessibility findings in the same release workflow as performance, crawlability, and functional defects. The result is not a claim that a site is permanently accessible; it is a maintained practice for finding barriers before they become part of the product.
