You’re a few weeks away from approving final designs and a build contract. The agency has a line item for an “accessibility sweep” in QA, and someone has already penciled in the launch date.
If you’re within a few weeks of approving a new site or redesign, the minimum you should require from any design team before accessibility becomes a launch-blocking risk is this: (1) A documented set of reusable accessible components (headings, buttons, forms, navigation, dialogs) with clear rules for content authors; (2) An explicit accessibility testing scope and timeline that starts at design and continues through development, not a single pre-launch audit; (3) Named ownership for fixing issues that appear during QA, plus a process for handling exceptions without slipping standards; and (4) A lightweight post-launch review cadence so new content and features don’t quietly undo the work. If a team cannot show you these commitments in writing before build, you are not buying a launch-ready design system—you are buying accessibility risk that will surface as delays, disagreements, or costly rework.
This is the point where accessibility is either locked in as part of how the site works, or set up to become a launch-blocking surprise.
What derails launches is rarely the existence of accessibility issues. It’s when you discover them, and who has the authority to fix them.
1. The real risk isn’t failing an accessibility check — it’s discovering it too late
On paper, the plan sounds safe: “We’ll make everything great, then run an accessibility pass before launch.”
In practice, this is how that story usually goes:
- Design is approved without clear patterns for headings, buttons, navigation, and forms.
- Development builds to the visuals and whatever assumptions the team carries about accessibility.
- Marketing locks in campaign dates and sales targets based on the promised launch.
- Two weeks before launch, someone runs an accessibility check. Forms can’t be used with a keyboard. The main navigation traps focus. Modal dialogs can’t be dismissed by screen reader users.
- Now you’re in a three-way argument between design, development, and marketing about what gets fixed, what slips to “phase two,” and whether launch moves.
The visible problem is a broken signup form or unreadable navigation.
The underlying problem is Workflow Debt: you allowed accessibility decisions to rely on ad hoc effort at the last minute instead of on defined patterns, ownership, and review points earlier in the project.
We’ve already covered what website owners miss when they only check accessibility at launch and what accessibility drift looks like after launch in other posts in the archive. This article fills in the missing middle: the commitments you should insist on before you approve designs or sign a build contract.
To make this manageable for a non-technical decision-maker, use one simple lens.
2. A simple lens: patterns, proof, people, and pulse
You don’t need to be an accessibility specialist to see whether your design team is about to create launch risk.
You need a way to interrogate the plan.
Use this four-part lens:
- Patterns – Do we have an accessible design system, or just pretty one-off mockups?
- Proof – What specific testing will be done, on what, and when? What evidence will we see?
- People – Who has the authority to say, “This isn’t shippable yet” when accessibility issues surface?
- Pulse – How will we keep accessibility from degrading once new content, campaigns, and exceptions start landing on the site?
Sample questions in each area:
- Patterns: “Can you show me the component library and the accessibility rules that go with it?”
- Proof: “When, specifically, will you test our forms and navigation with keyboards and screen readers?”
- People: “If QA finds serious accessibility issues a week before launch, who decides whether we fix them before going live?”
- Pulse: “After launch, who will review new landing pages or embeds so we don’t quietly undo what we’ve just paid for?”
This lens is how you compare agencies or internal teams without needing to read WCAG guidelines yourself. You’re not checking every technical detail; you’re checking for a real accessibility plan, not just an accessibility promise.
3. Patterns: insist on an accessible design system, not one-off mockups
If accessible patterns don’t exist before build, every page becomes a custom accessibility project.
That’s how you end up with:
- One form with clear labels and error messages, and another with placeholder-only labels that disappear when you start typing.
- One modal dialog that traps keyboard focus correctly, and another that leaves focus behind the overlay.
- Some pages with logical heading structure and others where the hero tagline is an H1 on one page and an H3 on another.
You can’t scale quality like that, and you definitely can’t guarantee a predictable launch.
The non‑negotiable component categories
At minimum, get commitments—and documentation—for these areas in your design system:
-
Typography and headings
- How many heading levels are we using?
- What’s the expected structure on a typical page (e.g., one H1, sub-sections as H2/H3)?
- How will content authors know which style to pick in the CMS?
-
Buttons and links
- Clear visual distinction between links and buttons.
- Focus states defined (not just hover).
- Disabled states and error states documented.
-
Navigation (desktop and mobile)
- How keyboard focus moves through the menu.
- How dropdowns open/close and announce themselves.
- How “skip to main content” or similar shortcuts are handled.
-
Forms
- Label placement and behavior (no labelless fields).
- Error message patterns, including how errors are announced.
- Required/optional field conventions.
-
Dialogs, modals, and disclosure controls
- How they receive and trap focus.
- How they are dismissed (Esc key, close button, clicking background).
- How “Show more” / accordions / tabs announce their state.
-
Media (video, audio, images)
- Rules for captions, transcripts, and alt text.
- When decorative images should be ignored by assistive tech.
Accessibility for these isn’t something you “add in dev.” It’s part of how the component works at all.
When teams say, “We’ll fix that in development,” they’re usually creating Workflow Debt. Every engineer implements the same interaction differently, every page becomes an exception, and you only find out which ones failed when QA is already behind.
What a real pattern-level commitment looks like
Ask your design team for these, before you sign off:
- A short, human-readable design system accessibility summary – one or two pages that describe how headings, buttons, links, navigation, forms, dialogs, and media are supposed to work and be used.
- A component library preview – even if it’s in progress, you should see how key components will look and behave, not just static page comps.
- Content author rules – guidance for whoever is putting words and images into the CMS: which heading levels to use, when to use buttons vs links, how to write alt text.
If a team can’t show you this, they’re asking you to trust that everyone will “remember to make it accessible” while under deadline pressure. That’s not a governance model; that’s a hope.
If you want a design and build engagement that starts from an accessible component library instead of retrofitting at the end, that’s exactly what our web design and development service is structured to operationalize.
4. Proof: define accessibility testing scope before anyone promises a launch date
The second lens is proof. What testing will actually happen, and when?
A single pre-launch audit is not a plan. At best, it’s a spotlight that reveals how much work you left until the last minute.
You want testing built into the Operational Consequence Chain: design → components → templates → real user flows.
Where testing should show up
At minimum, you should see:
-
Design review
- Early checks on color contrast, text size, and interaction ideas before they become expensive to change.
-
Component library QA
- Keyboard and assistive-tech testing on each reusable component (buttons, navigation, forms, modals) in isolation.
-
Template and key-flow QA
- Testing full page templates and the specific journeys that matter: lead-gen forms, checkout, account signup, search.
-
Pre-launch validation
- A final sweep to catch regressions, not to do all the work for the first time.
Tradeoffs you should see acknowledged
You cannot test everything with equal depth. That’s fine, as long as everyone is explicit about tradeoffs.
Expect a discussion something like:
- “We will do deep manual and keyboard testing on the main navigation, service detail pages, and all forms.”
- “We will rely on automated checks plus spot checks for basic content pages.”
- “We will not deeply test low-traffic legacy blog posts in this phase; we’ll focus on templates instead.”
Ambiguity is your enemy. Once you have a launch date in the calendar, ambiguous scope turns into emergency scope fights.
Questions to pin down testing scope and timing
Put these directly into your conversations and statements of work:
-
“Which tools and methods will you use for accessibility testing, and at which stages of the project?”
Look for a mix of automated tools plus manual keyboard and screen reader testing. -
“Which specific flows and templates will get deep manual testing?”
Your lead forms, account areas, and checkout/search journeys should be on that list. -
“How many rounds of accessibility testing are budgeted, and what happens if we find new issues during regression?”
You’re trying to avoid the ‘one and done’ audit that blows up when new defects appear. -
“What will you deliver as evidence—reports, issue lists, videos—so we can see proof of what was tested?”
-
“How will accessibility issues be tracked alongside other bugs in QA?”
Accessibility shouldn’t sit in a separate spreadsheet that no one feels responsible for.
If you want to deepen your own understanding of testing approaches and risk areas, the accessibility topic hub at accessibility articles is designed to reinforce this lens with individual posts on specific components and workflows.
5. People: name who can say “this isn’t shippable” when accessibility issues surface
When accessibility becomes a political issue at launch, it’s almost always because Ownership Fragmentation was baked into the project from the start.
Everyone cares. No one has authority.
You see patterns like:
- Design says, “Development implemented it wrong.”
- Development says, “We matched the approved designs.”
- Marketing says, “We have a campaign going live; we can’t move the date.”
- Legal says, “We can’t launch with this risk.”
Without clear decision rights, you negotiate accessibility under the worst possible conditions: late, stressed, and public.
A lightweight RACI for accessibility
You don’t need a 20-page RACI matrix. You do need a shared understanding of who does what.
Here’s a pragmatic sketch you can adapt:
-
Design lead
- Owns pattern-level accessibility decisions (e.g., heading structure, button styles, error states).
- Is responsible for ensuring the design system can be implemented accessibly.
-
Development lead
- Owns implementation quality and regression fixes.
- Is accountable for ensuring built components behave as specified.
-
Accessibility specialist or QA lead (internal or external)
- Is responsible for running tests and logging issues.
- Is consulted on tradeoffs and exceptions.
-
Product owner / business sponsor
- Is accountable for launch decisions when there’s a conflict between scope, date, and accessibility standards.
- Has the authority to say “We’re not shipping this flow until these issues are resolved.”
-
Content owners / marketing team
- Are responsible for following content-level accessibility rules (headings, alt text, link text) once they’re documented.
You want this level of clarity written down, not implied.
Sample commitments you can request
Ask your team or agency to put language like this into the project plan or SOW:
- “The design lead will document accessibility considerations for all components in the design system and review them with development before build.”
- “The QA lead will include keyboard and screen reader testing for agreed critical flows and report issues in the shared issue tracker.”
- “The product owner will decide, in consultation with design and development, which accessibility issues must be resolved before launch and which can be scheduled post-launch, with rationale.”
If your current project doesn’t have a named person who can veto a risky launch on accessibility grounds, you are relying on whoever shouts loudest when the first serious issue appears.
6. Pulse: set a review cadence so the site doesn’t drift the week after launch
Accessibility is not “done” on launch day. That’s the day your content and campaign machine starts trying to pull the site out of shape.
Without a pulse—a recurring review cadence—you get what we’ve described elsewhere as accessibility drift: small exceptions and urgent changes quietly move the site away from its original standards until you’re back in crisis territory.
If you want to see what that looks like in the wild, our post on what accessibility drift looks like after launch escalates the pattern with concrete examples.
You don’t need a heavy program to avoid that. You just need a few lightweight, explicit checkpoints.
A realistic cadence
Consider something like this:
-
Pre-launch
- One design-system review for accessibility (patterns).
- One component library QA pass (proof).
- One full-flow QA pass on critical journeys.
-
First 30–90 days after launch
- A 30-day review of new content types and landing pages created since launch.
- A 60- or 90-day review of any exceptions made under launch pressure (temporary workarounds, partial fixes).
-
Ongoing (quarterly or semi-annual)
- Quarterly checks on key templates and flows.
- Review of new features, third-party embeds, or design changes.
The key question is not “How often?” but “Who runs it, what’s in scope, and where do issues go?”
If nobody is named, and there is no documented rhythm, Workflow Debt builds up again. Each rushed campaign landing page, each quick embed, each “we’ll clean this up later” adds friction to your next redesign and risk to your next legal review.
If your team regularly spins up campaign pages or embeds third-party tools (checkout, forms, search), posts like what to review before moving checkout, forms, or search through a third-party embed and what to review when new landing pages introduce accessibility risk expand on specific areas that often escape any cadence at all.
7. What to put in writing before you approve designs or a build contract
Let’s turn the patterns–proof–people–pulse lens into something you can literally paste into a brief or contract.
You’re aiming for an accessibility plan, not just an accessibility promise.
Minimum written commitments
Before you approve designs or sign a build contract, ask for these items in writing:
-
One-page design-system accessibility summary (Patterns)
- Cover headings, buttons/links, navigation, forms, dialogs, and media.
- Note any known constraints or exceptions.
-
Defined accessibility testing scope and checkpoints (Proof)
- Which stages (design, components, templates, flows) get tested.
- Which tools and methods will be used.
- Which flows are considered “critical” for deeper manual testing.
-
Named roles and decision rights (People)
- Who owns pattern decisions.
- Who runs testing.
- Who decides what must be fixed pre-launch vs post-launch, and based on what criteria.
-
First-year review cadence (Pulse)
- When post-launch reviews will happen.
- What’s in scope (new templates, landing pages, embeds, key flows).
- How issues will be logged and prioritized.
You can add these as explicit sections in a statement of work or as an appendix to an internal brief. That’s usually enough to flush out whether a team truly knows how to build accessibly, or whether they were counting on “we’ll do a sweep at the end.”
When you compare partners, compare their plans, not just their language. Two teams can say “we take accessibility seriously.” The one that can show you patterns–proof–people–pulse in writing is the one that’s less likely to hand you an emergency three weeks before launch.
If you’d rather not assemble all of this governance yourself, our web design and development engagements are set up so these accessibility commitments are defined up front and integrated into how we design, build, and support a site, not stapled on afterward.
8. Diagnostic: three signals your design team is about to create launch-blocking accessibility risk
Use this quick self-check against your current project. If you see one of these signals, you’re looking at future Workflow Debt that will likely surface under deadline pressure.
Signal 1: Accessibility only appears as a future “QA” line item
If the only place you see accessibility mentioned is “QA: accessibility sweep,” and you can’t find it in the design system, component library, or content guidelines, you’re carrying hidden risk.
Ask:
- “Where are accessibility rules documented for our components and content authors?”
- “What did we check at the design stage, before build?”
If the answer is “we’ll figure that out in QA,” you should pause before approving the build plan.
Signal 2: Nobody can explain who will fix issues found during QA—or how that affects dates
When you ask, “If QA finds serious accessibility issues in our forms or navigation, who fixes them, and what happens to the launch date?” you should get a clear, confident answer.
If you get:
- “We’ll cross that bridge when we come to it,” or
- “We’ll see how many issues there are and decide,”
then you don’t have governance—you have a wish.
This is where Ownership Fragmentation turns technical bugs into political fights. Without defined decision rights, your launch plan is effectively “we’ll ship whatever’s easiest when time runs out.”
Signal 3: New content types and embeds are treated as unplanned exceptions
Your marketing team will want new landing pages, campaign microsites, and integrated tools—often faster than your original redesign was planned.
If those are handled as “we’ll just hack something together” with no accessibility review, you’ll recreate the same problems you just paid to fix.
Ask questions like:
- “When we add a new landing page template, who checks that it follows our heading, form, and button patterns?”
- “If we embed a third-party form, checkout, or search, who reviews its accessibility and what’s our fallback if it fails?”
Here, posts like what to review when new landing pages introduce accessibility risk and when detailed service explanations should stay visible instead of hiding behind ‘read more’ toggles expand how to handle specific patterns and content decisions that often become exceptions.
If your team can’t answer these questions without improvising on the spot, you’re on track to reintroduce accessibility risk as soon as the first post-launch campaign hits.
Treat these signals as reasons to stop and clarify, not as “it’s too late to change now.” It is cheaper to adjust scope and expectations today than to negotiate fixes under a live campaign deadline.
9. Choosing your next step: strengthen your current team or change the engagement
Once you’ve looked at your project through the patterns–proof–people–pulse lens, you’ll usually end up in one of two situations:
-
Your current team is willing but under-specified.
You see gaps in documentation, testing scope, and decision rights, but the team is open to tightening the plan. In this case:- Use the questions in this article to formalize commitments.
- Add the one-page accessibility summary, testing scope, roles, and cadence as addenda to the current SOW or project brief.
- Treat this as paying down Workflow Debt before it becomes an emergency.
-
Your current team resists clarity.
You ask for patterns, proof, people, and pulse, and get pushback like, “That’s overkill,” or “We don’t have time for that.” That’s a different decision:- Recognize that the team is effectively asking you to accept launch risk without a plan.
- Decide whether your risk tolerance, legal posture, and brand expectations can accommodate that.
- If not, be prepared to change the engagement, bring in an accessibility-focused partner, or renegotiate scope and dates.
If you want a partner that bakes these commitments into the design and build process from day one, not as a late-stage audit, our web design and development service is built to operationalize exactly that: reusable accessible components, defined testing scope, clear ownership, and a realistic post-launch pulse.
If you’re not ready to change vendors but want to raise the maturity of your accessibility governance, the broader accessibility archive at accessibility articles and the rest of the blog are designed to help you move from one-off fixes to predictable website operations.
And if you’ve realized that your current project cannot meet these commitments with the time and team you have, it may be time for a focused conversation about your launch risk. In that case, we’re available at contact page to talk through options grounded in your actual dates, contracts, and internal pressures—not abstract best practices.