Skip to main content :::
:::

How to Test Website Accessibility Before Launch

Add accessibility testing to your pre-launch workflow: run automated checks, then review keyboard access, focus, ARIA, and manual scenarios.

Summary

  • Start pre-launch accessibility testing with automated WCAG and best-practice checks.
  • Then add manual review for keyboard access, focus order, interaction states, ARIA, and content meaning.
  • Use DevCheck to run browser-based checks on local, staging, and authenticated pages before release.

Define the release flow you need to protect

Pre-launch testing should not be only a whole-site scan report. A more useful approach is to identify the main tasks affected by the release, such as registration, sign-in, search, checkout, form submission, file download, or payment.

Each task needs a clear starting point, success state, and failure state. That gives the team a way to judge whether an issue blocks users, instead of working through an unordered list of scan findings.

Round one: scan what automation can detect

Automated checks belong in the first round because they can quickly find explicit, repeatable, and regression-friendly issues: missing form labels, invalid ARIA, some contrast failures, heading structure problems, or unclear landmark usage.

DevCheck is useful because it runs in the current browser tab, including localhost, staging, authenticated pages, and states after interaction. That matters because many release risks exist before a page is publicly accessible.

Round two: complete the main task with keyboard only

Keyboard review is one of the easiest pre-launch checks to underestimate. Do not stop after pressing Tab a few times; complete the main task without a mouse.

If focus is invisible, order jumps unexpectedly, menus trap focus, dialogs lose focus after closing, or custom controls work only with a mouse, those issues usually need to be fixed before release.

Round three: confirm content, errors, and states make sense

Some issues cannot be fully judged by a scanner. Link text clarity, contextual alt text, helpful error messages, and whether state changes are visible or announced all need human judgment.

The goal is not a better score. The goal is to confirm that users can still understand where they are, what happened, and what they can do next across different ways of operating the page.

Which issues should block release?

Not every accessibility issue carries the same risk. A practical release decision looks at whether the issue blocks a main task, affects many users or critical scenarios, can be fixed at the component layer, or prevents people from understanding an error or leaving a state.

  • The main task cannot be completed without a mouse.
  • Focus is lost, invisible, or trapped inside a component.
  • Form errors rely only on color or do not give actionable next steps.
  • Important buttons, links, or fields have no accessible name.
  • A custom component exposes roles or states that do not match its behavior.

Next checks in this workflow

This guide is part of the DevCheck pre-release checking path. After this check, continue with the next tasks below.

  1. Run the first automated check

    What automated accessibility checks can and cannot find

    Use scan results to find machine-detectable issues while keeping the parts that still need human judgment visible.

  2. Review keyboard and focus path

    How to check keyboard focus path

    Check whether focus can move, whether the order makes sense, whether focus gets trapped, and whether the path matches the page context.

Related pages