Accessibility Testing Before Launch: A Practical QA Workflow
The scan is green. The design review passed. Two days before go-live, someone tries the checkout flow with a keyboard and gets stuck at the shipping form, because the continue button never takes focus. Now the choice is slipping the date or launching a known barrier into production. Accessibility testing before launch usually fails for a mundane reason: somebody ran one tool and treated the output as a test plan.
eight25 is an enterprise digital agency and certified Contentstack and Contentful partner. We build accessibility validation into the delivery pipeline rather than the week before launch: automated gates in CI, a component-level sweep, structured manual and assistive-technology passes, and a severity framework that says which defects actually block a release.
The Five-Stage Pre-Launch Accessibility Workflow
Accessibility testing works best as a pipeline that starts during development rather than as a final pre-launch check. Automated testing can catch many repeatable issues early, while keyboard, screen-reader, and journey testing cover problems automation cannot reliably evaluate. A useful test plan therefore looks less like a last-minute checklist and more like a sequence of gates, each with a named owner and a clear pass condition. The practical advantage is simple: defects found while components and templates are still being built are generally easier to correct than defects discovered after those patterns have propagated across the site.
| Stage | What it catches | Owner | Release gate |
|---|---|---|---|
| 1. Automated checks in CI | Machine-detectable WCAG failures, on every pull request | Engineering | Zero critical or serious violations to merge |
| 2. Component sweep | Defects in shared components, audited once in isolation | Engineering + QA | Each shared component passes its criteria before any template uses it |
| 3. Keyboard and focus pass | Focus order, keyboard traps, invisible focus, unreachable controls | QA | Every interactive template fully operable without a mouse |
| 4. Screen reader and journey testing | Names, roles, states, announcements, real task completion | QA + assistive-technology tester | Critical journeys completable with NVDA, JAWS, and VoiceOver |
| 5. Triage and sign-off | Severity classification, blocker vs. backlog, conformance record | Delivery lead | No open P0/P1 accessibility defects; conformance report drafted where required |
The ordering matters more than the contents. Stages 1 and 2 run continuously from the first sprint. Stages 3 and 4 run against a stable build in staging, typically two to four weeks out, which leaves room to fix what they find. Stage 5 runs in the same week as the go/no-go call.
Why a Green Automated Scan Isn’t a Pass
Automated tooling is a filter, not a verdict. How much it catches depends heavily on what “coverage” means and how the test is constructed. In one benchmark cited by the UK’s DWP Accessibility Manual, axe-core identified about 27% of a known issue set and axe-core plus Pa11y identified about 35%. Deque’s analysis of real-world audit data found substantially higher coverage when measured by the volume of accessibility issues rather than the number of WCAG success criteria. Either way, the conclusion is the same: automated results cannot establish accessibility or WCAG conformance on their own.
The gap isn’t random. Scanners are good at finding what’s missing and bad at judging whether what’s there is any good. A scanner tells you an image has no alt attribute. It won’t tell you the alt text reads hero-banner-final-v3.jpg. It flags a missing form label, but says nothing when the error message appears on screen and is never announced. It flags a missing form label, but says nothing when the error message appears on screen and is never announced. The WebAIM Million’s 2026 analysis found automatically detectable WCAG failures on 95.9% of the top one million home pages, averaging 56.1 detected errors per page, up 10.1% from 2025. The same six categories accounted for 96% of detected errors and have remained the most common categories for seven consecutive years. And because the study only measures automatically detectable issues, the harder problems still sit outside that result. Those are the easy ones, still unfixed. Everything harder sits below the detection line entirely.
| Check | Machine-testable | Requires a human |
|---|---|---|
| Alt attribute present | Yes | Whether the alt text describes the image’s purpose |
| Form input has a label | Yes | Whether errors are announced when validation fails |
| Contrast ratio of static text | Yes | Contrast over video, gradients, or state changes |
| Heading elements exist | Yes | Whether heading order reflects the real document structure |
| ARIA attribute is valid | Yes | Whether the ARIA describes what the component actually does |
To be fair to the tooling: automation is the only part of this that scales to every page on every commit, which is exactly why it belongs at the front of the workflow. The mistake teams make is treating it as the whole of it.
Stages 1 and 2: Automated Gates and the Component Sweep
Put the gate in the pull request. A quarterly accessibility report tells you what shipped broken three months ago, which is interesting and useless. The practical setup is axe-core driven through Playwright, asserted against the same rendered DOM your integration tests already exercise, with the build failing on critical and serious violations.
| Manual keyboard + assistive-technology passes | Keyboard operability, focus behavior, accessible names and states, announcements, reading order, and real task completion | More time-intensive than automated checks; basic keyboard QA can be performed broadly, while reliable screen-reader and assistive-technology testing requires deeper accessibility expertise. |
| Lighthouse CI | Per-PR snapshot and trend visibility | Runs fewer audits than axe; a weak choice as the primary gate |
| Tool | Role in the pipeline | Honest limitation |
| axe-core (via Playwright) | Primary CI gate; rules mapped to WCAG 2.0/2.1/2.2, Section 508, EN 301 549 | Detects a meaningful subset of machine-testable issues; cannot establish overall WCAG conformance or reliably judge contextual meaning, logical flow, or complete task operability. |
| Pa11y | Scheduled CLI sweeps across URLs or user journeys | Uses accessibility testing runners such as HTML_CodeSniffer and axe-core; particularly useful for repeatable command-line and CI coverage across multiple pages. |
Stage 2 is where the economics change. In a component-based front end every page is an assembly, so a defect in the button or the modal ships on every page that uses it. One fix repairs all of them. Auditing the twenty or thirty shared components in isolation, before templates compose them, is a far cheaper unit of work than auditing four hundred pages afterwards.
The artifact that makes this enforceable is a per-component definition of done: the criteria that component must satisfy, and how each one gets verified. A modal isn’t finished when it looks right. It’s finished when focus moves into it on open, returns to the trigger on close, can’t escape while it’s open, and announces itself. You can test that sentence. You can’t test “make the modal accessible.”
Stages 3 and 4: The Manual Passes That Find the Real Defects
Manual testing has a reputation for being unbounded, which is often a scoping problem rather than a reason to avoid it. A structured keyboard pass and assistive-technology pass across representative templates and critical journeys can uncover classes of defects that automated tools cannot reliably evaluate. The goal is not to test every possible combination; it is to cover the interactions and journeys where failure carries the greatest user and business impact.
A keyboard pass is one of the lowest-cost manual checks in the workflow and can be incorporated into ordinary QA with appropriate accessibility training. Move through each template without a mouse and confirm that focus remains visible, follows a logical sequence, reaches every interactive control, never becomes trapped, and is handled deliberately when modals, route changes, or dynamically inserted content change the interface. Single-page applications deserve particular attention because a visual route change does not automatically guarantee that keyboard focus or assistive-technology context moves with it.
The screen reader pass is where scope discipline matters, because you can’t test every combination. Test the ones your users actually run.
| Combination | Why it’s on the list | Priority |
|---|---|---|
| NVDA + Chrome/Firefox (Windows) | NVDA was the most commonly used desktop/laptop screen reader in WebAIM’s 2024 survey at 65.6%. As a primary screen reader, it led JAWS among respondents in Europe and Asia. | High-priority Windows combination | Required |
| JAWS + Chrome (Windows) | JAWS remained the leading primary desktop/laptop screen reader overall at 40.5% and was particularly prominent among North American respondents, where 55.5% named it their primary screen reader | High-priority combination for North American enterprise audiences |
| VoiceOver + Safari (macOS/iOS) | The native screen-reader/browser combination for direct testing of Safari and iOS web accessibility | High priority where Apple-device traffic is material |
| TalkBack + Chrome (Android) | Android mobile web | Conditional on traffic share |
Work in journeys as well as pages. A page-by-page sweep can generate a long list of isolated findings while still missing barriers that emerge between steps. Identify the three to five journeys carrying the greatest user and business impact – for example, search to product to cart to checkout, or resource to gated form to confirmation – and complete them end to end with keyboard and appropriate assistive technology. In eight25’s delivery model, an accessibility defect that prevents completion of a critical journey is treated as release-blocking until it is remediated or explicitly escalated through the agreed governance process.
Sample the remaining site by template and content pattern rather than testing every URL indiscriminately. If ten templates power four hundred pages, those templates provide the starting sample, supplemented by pages with unique interactive behavior, materially different content states, embedded third-party experiences, or variations likely to affect accessibility
Stage 5: Severity Triage and What Actually Blocks a Launch
Most teams have no written answer to the question that decides go/no-go: which of these defects stops the launch? Without a severity framework agreed in advance, that call gets made at 4pm on launch day by whoever is most senior in the room, which is how known barriers ship.
Most teams have no written answer to the question that decides go/no-go: which findings stop the launch? WCAG defines conformance requirements, but it does not prescribe a universal P0-P4 release-severity system. That decision needs a delivery framework agreed before launch. On enterprise cutovers, eight25 uses a P0-P4 model tied to critical journeys, WCAG impact, affected reach, available workarounds, and remediation ownership, with accessibility findings entering the same bug-intake and release-governance process as other production risks.
| Severity | Definition | Launch decision |
|---|---|---|
| P0 | Blocks task completion for assistive-technology users on a critical journey: keyboard trap, unlabeled checkout control, focus lost on route change | Blocks launch |
| P1 | Significant WCAG A/AA failure affecting an important journey or high-use template, but with an available workaround | Normally blocks release; any exception requires documented review by the organization’s designated accessibility, product, legal/compliance, and delivery owners as appropriate |
| P2 | A/AA failure on a low-traffic template, or a single content instance | Ships; enters the post-launch queue |
| P3–P4 | AAA items, cosmetic focus styling, best-practice improvements | Backlog |
Documentation matters, but documented acceptance should not be confused with accessibility conformance or legal compliance. Where an organization chooses to release with a known accessibility defect, the decision should identify the affected users and journeys, the accountable owner, the remediation deadline, and any interim mitigation. Regulatory or legal obligations may require remediation regardless of the internal severity label, so higher-risk exceptions should be reviewed by the appropriate compliance or legal stakeholders.
Right-Sizing the Workflow: How Much Testing Is Enough
Running the full five stages on a twelve-page marketing microsite wastes budget, and pretending otherwise is why teams quietly abandon accessibility programs six months in. The honest answer is that the right scope depends on what you’re exposed to, and most of the disagreement we see in scoping conversations is really a disagreement about that.
| Site profile | Proportionate scope | Reasonable to skip |
|---|---|---|
| Low-risk marketing site, tight component set | CI gate, component sweep, keyboard pass on every template, one AT spot-check of the primary journey | Page-by-page manual audit; formal conformance report |
| Public-sector or regulated | All five stages, external audit, documented conformance report | Nothing |
| E-commerce or high-litigation sector | All five stages, journey testing weighted to cart, checkout, search, and account | Exhaustive page-level audit, if templates and journeys are fully covered |
The exposure side of that judgment has moved. Seyfarth Shaw identified 3,117 federal website-accessibility lawsuits in 2025, up 27% from 2024 and representing 36% of federal ADA Title III filings. Separate industry trackers that also include state-court litigation put the broader 2025 digital-accessibility total above 5,000, although federal and state datasets use different methodologies and should not be treated as a single standardized series. On the public-sector side. The DOJ’s Title II rule sets WCAG 2.1 AA as the standard; in April 2026 the deadlines moved out a year, to 26 April 2027 for state and local government entities serving populations of 50,000 or more and 26 April 2028 for smaller onesDOJ’s April 20, 2026 Interim Final Rule extended the deadlines to: April 26, 2027: population 50,000+ The dates moved. WCAG 2.1 AA still applies, to the same scope of content.
One thing not to treat as a substitute for this workflow is an accessibility overlay. An overlay cannot replace remediation of underlying markup, focus management, semantic structure, form behavior, and other source-level accessibility defects. The distinction matters commercially as well as technically: in 2025, the FTC finalized an order requiring accessiBe to pay $1 million after alleging that claims about its automated product making websites WCAG-compliant were false, misleading, or unsubstantiated. The safer model is to make accessibility part of the design, component, engineering, and QA system rather than adding a compliance layer at the end.
Where Teams Get This Wrong
The failure is almost never technical difficulty; it’s the calendar. Accessibility testing gets scheduled after code freeze, in the same week as performance testing and content QA, at the exact point in the project when there’s no time to fix anything structural. Findings arrive, get reclassified as “phase two,” and ship anyway.
The second failure is ownership, and it’s the reason the stage table above has an Owner column at all. Accessibility gets assigned to everyone, which means the automated gate is somebody’s side project, no one owns the keyboard pass, and nobody has ever opened a screen reader. Developers need enough fluency to run a keyboard check and read an axe report; QA needs real manual and assistive-technology depth. Those are different skill levels, and pretending one covers both is how green dashboards coexist with unusable checkouts. If you can’t name the person who owns each of the five stages, you don’t have a workflow, you have a hope.
The third is testing the CMS instead of the output. The third failure is testing the CMS instead of the rendered experience. A well-designed content model can require fields such as alternative text and constrain which structures editors are allowed to create. Platforms including Contentful and Contentstack provide validation and structured-content capabilities that can support those guardrails. But the authoring layer governs only part of the system: accessibility still depends on how the front end renders that content and how components behave in the browser. But the authoring layer only governs what authors add. It says nothing about what the front end renders.
eight25’s delivery model puts QA inside the delivery pod rather than treating it as a final-stage handoff. Accessibility checks can therefore be addressed at the component and content-model level, alongside performance, functional QA, migration validation, and launch readiness. That matters particularly on large enterprise CMS programs: when a recurring accessibility defect originates in a shared component or authoring pattern, the higher-leverage move is to correct the system producing the defect rather than repeatedly fixing individual pages downstream.Non-technical publishers hand-picking H1/H2/H3 is a structural accessibility risk that no amount of pre-launch testing permanently fixes. The general move is to fix whatever keeps producing the defect.
Frequently Asked Questions
How do you test a website for accessibility before it launches?
Run five stages in sequence: automated axe-core checks gating every pull request, a component-level audit of shared UI elements in isolation, a manual keyboard and focus pass across every template, screen reader testing of your three to five critical user journeys with NVDA, JAWS, and VoiceOver, and a severity triage that defines which defects block the release. Run accessibility validation in layers: automated checks in development and CI, component-level testing of shared UI, manual keyboard and focus testing, assistive-technology testing across critical journeys, and documented severity triage before release. Automated tools are valuable because they can test repeatable rules continuously, but they cannot establish WCAG conformance on their own. Manual testing remains necessary for issues involving meaning, focus behavior, interaction, announcements, reading order, and real task completion.
Is automated accessibility testing enough to pass a WCAG audit?
No. Automated testing is an important part of WCAG validation, but no automated scanner can determine full conformance. In one benchmark cited by the UK’s DWP Accessibility Manual, axe-core detected about 27% of a known issue set and axe-core plus Pa11y detected about 35%; other studies report different figures depending on what is being measured. The important limitation is qualitative: automation can identify many rule-based failures but cannot reliably decide whether alternative text conveys the right meaning, whether focus behavior makes sense through a journey, or whether a user can successfully complete a task with assistive technology. They identify missing attributes but can’t judge whether alt text is meaningful, whether reading order makes sense, or whether a keyboard user can operate a menu,which is where most real barriers and most litigation live.
How long does pre-launch accessibility testing take?
There is no universal duration because testing scope depends on template count, component complexity, interactive states, supported devices, critical journeys, and the number of defects discovered. As a planning benchmark, eight25 typically scopes a focused pre-launch keyboard and journey-level assistive-technology pass separately from remediation, with considerably more time reserved where accessibility validation has not been running throughout development. Teams that introduce automated and component-level checks earlier generally enter launch QA with a much smaller defect surface than teams testing accessibility for the first time at code freeze. The variable isn’t the testing. It’s what you find. Teams running automated gates from sprint one finish validation in days; teams testing for the first time at code freeze routinely need weeks.
Which accessibility defects should actually block a launch?
Anything that prevents an assistive-technology user from completing a critical journey: keyboard traps, unlabeled form controls in checkout, focus lost on route change. WCAG A/AA failures on high-traffic templates should also block, unless formally accepted with a named owner and a dated remediation commitment. Lower-severity single instances and AAA items belong in the post-launch queue.
How do I find an agency that takes accessibility testing seriously?
Ask to see the artifacts rather than the intent. A partner doing this properly can show you a component-level definition of done mapping WCAG criteria to verification method, their CI gate configuration and failure thresholds, a written severity framework covering what blocks a launch, and named assistive-technology testing in the delivery plan rather than a line item labelled “accessibility audit.”Ask to see the artifacts rather than the intent. A partner with a mature accessibility process should be able to show how WCAG requirements map into component acceptance criteria, what automated checks run during development, how severity affects release decisions, who owns manual keyboard and assistive-technology testing, and what evidence is retained at sign-off. A scan report alone tells you that automation ran; it does not demonstrate that the rendered experience, critical journeys, or assistive-technology behavior were manually validated.
Building an Accessibility QA Workflow That Holds
If your team is planning a launch and accessibility is still a line item scheduled after code freeze, move the decision upstream. eight25 helps enterprise teams build accessibility into the delivery model during discovery: which checks run continuously, which components need explicit acceptance criteria, who owns keyboard and assistive-technology validation, what findings affect release readiness, and what evidence stakeholders will need at sign-off. The result is a workflow designed to find accessibility defects while the system is still economical to change, rather than during the final days before launch.