# How to Test Website Accessibility Before Launch

Traditional Chinese version: [https://accesserty.com/ai/guides/accessibility-testing-before-launch.md](https://accesserty.com/ai/guides/accessibility-testing-before-launch.md)

Page version: [https://accesserty.com/en/guides/accessibility-testing-before-launch/](https://accesserty.com/en/guides/accessibility-testing-before-launch/)

Last updated: 2026-09-28

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.

## 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 steps

- [What automated accessibility checks can and cannot find](<https://accesserty.com/en/guides/automated-accessibility-checks-limits/>) — Use scan results to find machine-detectable issues while keeping the parts that still need human judgment visible.

- [How to check keyboard focus path](<https://accesserty.com/en/guides/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

- [Run individual checks: practical WCAG checklist](<https://accesserty.com/en/guides/wcag-testing-checklist/>)

- [Plan remediation and re-testing](<https://accesserty.com/en/guides/web-accessibility-remediation-plan/>)

- [Automated accessibility checks limits guide](<https://accesserty.com/en/guides/automated-accessibility-checks-limits/>)

- [Focus path review guide](<https://accesserty.com/en/guides/how-to-check-keyboard-focus-path/>)

- [Accessible authentication glossary page](<https://accesserty.com/en/glossary/accessible-authentication/>)

- [How do screen readers understand webpages?](<https://accesserty.com/en/glossary/screen-reader/>)

- [W3C WAI: Evaluate Accessibility Throughout Development](<https://www.w3.org/WAI/test-evaluate/>) — Guidance on early, ongoing evaluation with tools and human judgment. The article's release checks are practical suggestions, not a complete conformance assessment.

- [Accesserty DevCheck](<https://accesserty.com/en/devcheck/>) — Run browser-based checks on local builds, staging pages, authenticated screens, and interactive states.

- [Web accessibility checker](<https://accesserty.com/en/web-accessibility-checker/>) — Check real pages, authenticated states, and interactive states before release.

- [Understand WCAG check results](<https://accesserty.com/en/wcag-compliance-tool/>) — Review WCAG A/AA issue clues, severity, affected elements, and remediation hints.

- [Accessibility practice and maintenance guides](<https://accesserty.com/en/guides/>) — Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.