Skip to main content :::
:::

How to Test Website Accessibility Before Launch

Plan pre-launch accessibility testing: choose tasks and states, combine scans with keyboard and assistive-technology checks, then record re-tests, untested scope and handover.

Last updated:

Summary

  • First select tasks, pages and states affected by the change, then plan the checks.
  • Then add manual review for keyboard access, focus order, interaction states, ARIA, and content meaning.
  • Repeat the same steps after fixes and retain untested items explicitly; release decisions need more than a clean scan.

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.

Prepare states and safe test data

For registration, do more than open the homepage: list the empty form, invalid input, corrected submission, success feedback and any actual session-expiry state. Record the URL, version, account permissions and how to reach each state.

Use an authorized test environment, test accounts and fictional data. Payments, email, orders and deletion have real side effects; use test mode or a controlled verification plan rather than repeated submissions to production.

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.

Re-test fixes and hand over the evidence

For each confirmed issue, record steps, expected and actual results, affected state and an owner. Re-test the same task and environment after the fix, then sample other pages using the shared component; do more than remove one line from a scan screenshot.

After fixing registration errors, enter the same invalid value again. Verify that you can locate the field, understand the message, correct it and identify the submission result. Mark screen-reader work not yet tested if it has not been done; an accessibility tree, simulated speech or keyboard-only test is not a substitute.

Hand over verified fixes, unresolved findings, review items and untested scope, plus dates, page versions, browser and assistive-technology versions. The release owner assesses unfinished work and alternatives; this process is not proof of full WCAG conformance.

Next checks in this workflow

Choose a follow-up task that applies to your page. PDF checks are needed only when documents are part of the task; a fix still needs retesting.

  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