How to Test Website Accessibility

Define the scope before testing

Start by identifying what you are testing and which experiences matter. A representative scope may include the home page, navigation, forms, authentication, search, transactional flows, media, documents, and reusable components.

Also identify the accessibility standard or organizational requirement that applies to the review. For WCAG-based work, record the version and conformance level being evaluated so findings remain traceable.

Run automated accessibility checks

Automated testing is an efficient first pass. It can identify many issues in markup, accessible names, relationships, attributes, contrast calculations, and other machine-testable conditions.

Review each automated result in context instead of treating the number of findings as a conformance score. Confirm affected elements, remove false positives where appropriate, and prioritize findings according to user impact and remediation needs.

Test keyboard accessibility

Navigate the experience without a mouse. Use the keyboard to move through links, buttons, form controls, menus, dialogs, and other interactive components.

Review focus, navigation, and interactive behavior

Check menus, modal dialogs, disclosures, tabs, carousels, custom widgets, and dynamically updated content. Confirm that focus is not unexpectedly lost, hidden, or moved to an illogical location when the interface changes.

Repeated navigation mechanisms and page structure should also remain understandable and predictable.

Test forms, instructions, and errors

Inspect labels, instructions, required fields, grouping, validation, and error recovery. Users should be able to understand what information is expected and identify what went wrong when submission fails.

Do not rely only on placeholder text, color, or visual position to communicate essential information.

Review images and non-text content

Determine whether informative images have appropriate text alternatives and whether decorative images are handled so they do not add unnecessary noise. Complex visual information may require a more detailed accessible equivalent than a short alternative text.

Inspect headings, landmarks, and content structure

Review whether headings communicate the organization of the page, lists and tables use meaningful structure, and landmarks or semantic regions help users understand and navigate the interface.

Visual appearance alone does not establish programmatic structure, so inspect the underlying semantics as well as the rendered page.

Check contrast, zoom, reflow, and responsive behavior

Evaluate text and meaningful graphical contrast where applicable. Increase zoom and inspect narrow layouts to identify clipping, overlap, hidden content, horizontal scrolling, or controls that become difficult to use.

Do not assume that a responsive design is automatically accessible at high zoom or reduced viewport widths.

Perform manual and assistive-technology testing

Some accessibility questions cannot be reliably answered from source code alone. Structured manual testing helps evaluate purpose, context, interaction, reading order, meaningful labels, status communication, and other experience-level requirements.

Where the scope calls for it, test representative journeys with relevant assistive technologies such as screen readers. Record the browser, assistive technology, version, steps performed, expected behavior, and observed result so the test can be reproduced.

Record findings and accessibility evidence

A finding should be actionable. Capture enough information for another person to understand the problem and reproduce it: affected page or component, applicable requirement, observed behavior, user impact, evidence, and remediation guidance.

Evidence is especially important for manual decisions because it preserves why a result was classified as a failure, pass, or item requiring further review.

Remediate accessibility issues

Prioritize fixes according to user impact, severity, recurrence, and the importance of the affected journey. Fixing a shared component can resolve the same problem across many pages, so component-level remediation can be more effective than treating every occurrence independently.

Retest and verify the fix

Accessibility work does not end when a ticket is marked complete. Repeat the relevant automated or manual test against the updated experience and verify that the original issue is resolved without introducing a regression.

Keep the original finding, new test result, supporting evidence, and reviewer decision connected where possible. This creates a clearer record of what changed and what was verified.