When you’re staring at three web design proposals, they can all look the same on accessibility:
- “WCAG 2.1 AA compliant”
- “Automated accessibility testing included”
- “Accessible, inclusive user experience”
On paper, everyone passes. Two years later, you’re the one fielding complaints about broken forms, unreadable modals, and campaign pages that don’t work with keyboards.
If you’re comparing web design proposals on accessibility, don’t ask “who mentions WCAG?” Ask “who shows me their governance?” A strong proposal will: (1) map accessibility standards to a design system with clear component coverage, (2) define who owns accessibility decisions at each stage of the project, (3) include human and assistive-tech testing beyond automated scans, and (4) spell out a post-launch review cadence and escalation path when something slips. If a proposal can’t show you those four things in writing, you’re not buying accessibility; you’re buying a risk you’ll have to own later.
This article gives you a concrete way to compare proposals on that governance, not just on compliance buzzwords.
We’ll use four governance lenses you can apply directly to the PDFs in front of you:
- Design system coverage
- Testing scope
- Ownership and decision rights
- Post-launch cadence
Use them like a scoring rubric, not a philosophy discussion.
1. The real decision: you’re not choosing a WCAG label, you’re choosing who owns accessibility drift
In most redesign RFPs, the implicit question is, “Who can give us a WCAG AA site?” That’s the wrong question.
The real decision is: When the site inevitably changes, who owns accessibility drift and how will they control it?
Because the site will change.
- New landing pages will be rushed for campaigns.
- New components will appear (“just add a carousel for this feature highlight”).
- Third-party tools will be embedded for booking, search, or chat.
If accessibility governance isn’t nailed down in the proposal, the default is simple: you own the mess.
We see the same Operational Consequence Chain play out over and over:
- Visible win: Redesign launches with a clean accessibility report.
- Drift: Marketing spins up new campaign pages, adds embeds, and tweaks forms without accessible patterns or re-testing.
- Operational drag: Support starts seeing complaints. Marketing and IT argue over which backlog owns the fixes.
- Strategic cost: Legal or leadership triggers an audit. The audit discovers systemic gaps and you’re suddenly funding remediation instead of new features or content.
That chain starts at the proposal stage. If accessibility is framed as a one-off hurdle to clear before launch, it will not survive real-world change.
A prior article, “What a Design Team Should Commit to Before Accessibility Becomes a Launch-Blocking Risk” expands this from a single-team perspective. Here, we’re turning that into a comparison tool for picking the right partner and scope.
Hold that mental model as we walk through the four governance lenses.
2. A quick read test: what strong accessibility governance sounds like in a proposal
Before you dive into details, give each proposal a 60–90 second skim using a blunt test:
Where does accessibility show up?
Strong governance:
- Has a dedicated “Accessibility” or “Accessibility and Compliance” section.
- References accessibility in Scope of Work, Design System, QA/Testing, and Post-launch Support—not just in one place.
Weak governance:
- Buries accessibility as a bullet under “Non-functional requirements” or “Quality”.
- Mentions “WCAG” only in a marketing preamble, not in the SOW itself.
What kind of language do they use?
Strong governance includes phrases like:
- “Accessibility acceptance criteria for components and page templates”
- “Assistive technology testing (screen reader, keyboard-only)”
- “Change review process for new components and patterns”
- “Accessibility exceptions and risk acceptance process”
Weak governance leans on:
- “As needed accessibility fixes”
- “We will strive for WCAG compliance”
- “Accessibility testing via automated tools” with no further detail
How concrete is the plan?
Strong governance:
- Names roles (e.g., “Accessibility lead,” “QA owner”), not just “the team”.
- Offers cadence (e.g., “quarterly accessibility review,” “review for each new component”).
Weak governance:
- Relies on “we’ll collaborate” and “we’ll review” with no who/when/how.
If you don’t see concrete roles, cadences, and component-level language in the quick skim, you’re looking at a compliance promise, not governance proof.
3. Governance lens #1 – Design system coverage: are components, states, and flows actually in scope?
Accessibility lives or dies at the component and pattern level.
A proposal that just says “we’ll design accessible pages” is not enough. You need to see what they’re designing and how standards map to those pieces.
What to look for in the SOW and design-system sections
Open each proposal’s sections often labeled:
- “Design System” or “Component Library”
- “Templates and Page Types”
- “UI Kit” or “Pattern Library”
Then ask:
-
Do they list components and patterns?
- Strong: Explicit list (e.g., buttons, inputs, form validations, tabs, accordions, modals, alerts, navigation menus, tables, cards, pagination, carousels) with language like “accessible states” or “focus management”.
- Weak: “We’ll design a modern component library” with no mention of accessibility or of specific UI patterns that typically break.
-
Do they mention interactive states and flows?
- Strong: “Focus states,” “error and validation messaging,” “success and failure paths,” “keyboard interaction patterns.”
- Weak: Only static mockups and visual states are mentioned.
-
Are key flows explicitly in scope? For your site, this likely includes:
- Multi-step forms (e.g., gated content, quote requests, job applications)
- Account login / portal gateways
- Search, filters, and results
- Checkout or booking journeys, if relevant
Strong proposals call out these flows and state that their designs and builds will meet accessibility criteria. Weak ones treat them as generic “pages”.
Why this matters for drift
If components and flows aren’t explicitly covered, three things usually happen later:
- Designers improvise new UI patterns mid-project without accessible behavior defined.
- Developers build one-off interactions that don’t match any documented accessible pattern.
- Marketing tools (forms, embeds, widgets) get dropped in without any pattern review.
That’s where Workflow Debt shows up: every new page or campaign becomes a special-case conversation about “whether this is accessible,” because no one can point to a standard pattern.
When you see vague component coverage, assume the future cost will land on your teams. You’ll be funding accessibility fixes piecemeal instead of investing once in a design system that bakes it in.
If you want a deeper view of what component-level commitments should look like from a single team’s perspective, the earlier post on design team commitments before accessibility becomes a launch-blocking risk expands this lens.
4. Governance lens #2 – Testing scope: beyond “we’ll run an automated scan”
Most proposals now say “we’ll run automated accessibility tests.” That’s table stakes.
Automated tools are useful, but they typically catch a subset of issues. The governance question for you is:
Who is responsible for choosing tests, running them at the right times, interpreting results, and re-testing after changes?
Read the QA / testing section for these elements
Look for headings like:
- “QA and Testing”
- “Acceptance Criteria”
- “Accessibility Testing”
Then grade each proposal on:
-
Types of testing
- Strong: Describes both automated and manual testing, with at least one assistive technology listed (e.g., screen readers, keyboard-only navigation). Mentions real user flows being exercised.
- Weak: Only says “automated scan” or names a tool and stops there.
-
Scope of testing
- Strong: Explicit about which templates, components, and flows are tested (e.g., “all core templates,” “multi-step forms,” “primary navigation”).
- Weak: “We will test the site for accessibility” with no detail.
-
Timing of testing
- Strong: Calls out testing at multiple stages—design review, development QA, pre-launch regression. May mention testing on a staging environment.
- Weak: Only at “final QA” or “before launch”.
-
Bug triage and acceptance criteria
- Strong: Defines severity levels or acceptance criteria (e.g., “All critical and major accessibility issues resolved before launch”). Describes who decides what gets deferred.
- Weak: “We will fix issues identified” without saying which issues must be fixed, or who decides what is considered “done”.
The hidden failure mode
We often review proposals where accessibility shows up as a single line under QA:
“Run automated accessibility scan and fix issues.”
Critical flows—multi-step forms, modals, accordions, third-party widgets—are either marked “assumed accessible” or not mentioned at all.
Two years later, those are the exact areas where:
- Users with assistive tech struggle.
- Support tickets pile up.
- Marketing is told “we can’t change that component” because it might break something.
That’s an Operational Consequence Chain in action: under-scoped testing today becomes recurring support and remediation work later.
When you compare proposals, treat “automated testing only” as a red flag, not a nice-to-have. If a vendor believes automation alone is sufficient, they’re signaling how they think about accessibility overall.
5. Governance lens #3 – Ownership and decision rights from discovery through post-launch
Accessibility governance is mostly about who decides what, when.
If a proposal is vague about ownership, it’s not an oversight; it’s an answer. By default, that answer is: you own it.
A simple ownership grid
Skim each proposal and map what you see into this grid. You don’t need a perfect RACI; you just need enough clarity to avoid arguments later.
| Stage | Key accessibility decisions | What strong proposals do | What weak proposals do |
|---|---|---|---|
| Discovery / Strategy | Which standards apply, risk tolerance, priority flows | Names an accessibility lead, clarifies standards and priorities | Says “we’ll align on requirements” with no owner |
| UX / Content Design | Patterns for headings, link text, form labels, error handling | Defines content and design responsibilities, provides guidelines | Says “we’ll design accessible pages” with no detail |
| Visual / UI Design | Color contrast, focus states, hover vs active states | Mentions accessibility reviews in design critiques | Treats accessibility as a separate check later |
| Development | ARIA use, keyboard support, semantic HTML | Assigns developers to follow patterns and documents decisions | Assumes devs “know” accessibility without any process |
| QA / Pre-launch | What counts as a blocking issue, what can be deferred | Defines acceptance criteria and who signs off | ”We’ll fix issues” with no one named as final decision-maker |
| Post-launch / Ongoing | Who reviews changes, who responds to issues, cadence of checks | Proposes a maintenance model or shared governance arrangement | Silent, or says “client team will handle content/accessibility” |
Now check each stage:
- Are there named roles? (e.g., “Project accessibility lead,” “Client content owner”)
- Are decision rights clear? (who can say “launch,” who can approve an exception?)
- Is your internal team expected to take on accessibility decisions you’re not staffed for?
One sharp distinction to keep in mind:
- Compliance promise: “We will deliver a WCAG 2.1 AA compliant website.”
- Governance proof: “Here is who will own accessibility decisions at each stage and how we will keep the site accessible as it changes.”
You want governance proof.
This is where that compression line applies: if a proposal can’t show you who owns accessibility decisions after launch, it’s already answered your question—you do. Decide if that’s a responsibility you actually want.
If you suspect your content operations are a major source of accessibility issues, the post on accessibility issues coming from content workflow, not the design system expands this ownership lens.
6. Governance lens #4 – Post-launch cadence: how accessibility stays aligned when the site changes
Launch is the easy part. Governance is how you avoid sliding backwards.
When you read the “Post-launch Support,” “Maintenance,” or “Ongoing Services” sections, look for:
1. Training and documentation
Strong proposals:
- Include training for content editors and marketers that covers accessibility basics in your actual CMS.
- Provide written guidelines: component usage rules, do/don’t examples, checklist for publishing new pages.
Weak proposals:
- Offer a generic handoff meeting.
- Assume your team already knows how to keep content accessible.
2. Change review and new components
Strong proposals explain:
- How new components are requested, designed, and tested for accessibility.
- How they’ll review significant changes (new templates, new embed types, major flows).
Weak proposals:
- Use vague phrases like “support for enhancements” or “minor updates” without any mention of accessibility review.
3. Periodic audits or check-ins
Strong proposals propose a cadence—quarterly or semi-annual accessibility check-ins, or a defined audit package.
Weak proposals are silent. That silence is not neutral. It means accessibility will only be revisited reactively, when there’s a visible problem or external pressure.
4. Escalation path when something slips
No matter how good the plan, something will slip.
Strong proposals describe:
- How issues are reported (tickets, support channel).
- How they are triaged (severity, impact).
- How quickly critical issues are addressed.
Weak proposals treat issues as generic “support items” without recognizing accessibility as its own risk class.
When post-launch cadence is missing, you accumulate Workflow Debt: every future change requires extra coordination and debugging because there’s no standard way to keep accessibility in step with design and content.
If you want to go beyond governance into how process and content shape the whole redesign, the article on content-first web design is a useful escalation path.
7. Red flags and tie-breakers: when proposals look similar on paper
Sometimes two vendors look equally strong at a glance. This is where sharper red flags and tie-breakers help.
Red flags to treat as hard problems, not details
-
Accessibility as an optional add-on line item
If accessibility shows up as “Add $X for accessibility” separate from the core scope, it’s being treated as a bolt-on, not a baked-in standard. -
Vague “as-needed” language
Phrases like “as-needed accessibility fixes” or “we will review as appropriate” are governance gaps. Who decides what’s “needed”? When? -
Reliance on third-party embeds with no governance
If critical flows are offloaded to third-party tools (checkout, booking, search), but the proposal simply says “client-provided embed” or “assumed accessible by vendor,” you’re inheriting that risk with no control. This is where the guidance in what to review before moving checkout, forms, or search through a third-party embed is a useful contrast. -
No mention of content workflow
If your team publishes frequently but the proposal ignores how editors will maintain accessible headings, alt text, link text, and forms, expect recurring issues. That’s exactly the pattern explored in the post on accessibility issues rooted in content workflow.
Tie-breakers when both vendors look competent
When two proposals meet your baseline, use these as tie-breakers:
-
Who names an accessibility owner on their side?
A vendor who names a role (even if part-time) is more likely to treat accessibility as ongoing work, not a sales promise. -
Who shows you sample governance artifacts?
Examples of component documentation, accessibility checklists, or training outlines are worth more than another paragraph of assurances. -
Who includes your team in the governance plan?
The best proposals clarify which decisions remain with the vendor, which move to your team, and how you’ll collaborate without creating bottlenecks.
When in doubt, choose the vendor who treats accessibility as shared governance, not a black-box service you “get” once.
8. Turning this into action: questions to send back to your shortlisted vendors
You don’t have to rewrite your RFP. You can send a short follow-up email to each vendor and see how they respond.
Here are questions you can copy, edit, and send:
-
Design system coverage
”Can you describe how accessibility standards will be mapped into the component library and page templates? Which components and interaction patterns will explicitly have accessibility criteria defined?” -
Critical flows
”Our highest-risk flows are [multi-step forms / gated content / account login / booking]. How will accessibility be designed, built, and tested specifically for those flows?” -
Testing scope and ownership
”Beyond automated scans, what manual and assistive-technology testing will you perform? Who is responsible for running those tests, and at what points in the project?” -
Acceptance criteria and triage
”How do you define accessibility acceptance criteria before launch? Who decides which issues must be resolved pre-launch versus can be deferred, and how are those documented?” -
Post-launch cadence
”What does your post-launch accessibility governance model look like? How often do you recommend reviews, and what’s included?” -
Content workflow and training
”What support do you provide to help our content and marketing teams keep new pages accessible (e.g., training, checklists, publishing workflow changes)?” -
Third-party tools and embeds
”How do you handle accessibility risk for third-party tools (forms, checkout, booking, search) that are embedded in the site? What do you expect from us vs. from those vendors?” -
Examples of governance in action
”Without sharing any private client data, can you show an anonymized example of how you document accessibility decisions, component patterns, or review cadences on a typical project?”
The quality and specificity of the answers will tell you more about governance than another slide about “inclusive design.”
If you want to see what it looks like when accessibility governance is built into a design and development engagement from the start, our web design and development services are structured around exactly these ownership and cadence questions.
9. When you realize the problem is bigger than this project
Sometimes, halfway through comparing proposals, you realize the issue isn’t which vendor is “best”—it’s that your organization doesn’t yet have a sustainable way to own accessibility at all.
Typical signals:
- You don’t know which internal team actually owns accessibility decisions after launch.
- IT owns infrastructure, marketing owns content, but neither has accessibility baked into their workflows.
- Legal has started asking about risk, but you don’t have a governance model to show them.
At that point, changing vendors won’t fix the underlying problem. You’re facing a Buyer Maturity Path moment: moving from “we need an accessible redesign” to “we need an accessibility governance model that survives redesigns.”
If you ignore that and just pick the cheapest or fastest proposal, the Operational Consequence Chain is predictable:
- The redesigned site “launches accessible” on day one.
- New campaign pages and embeds are created under deadline pressure without clear patterns or reviews.
- Support and sales start hearing from users who can’t complete tasks.
- Leadership triggers an audit, and you find yourself funding a surprise remediation project instead of the growth work you’d planned.
If that sounds familiar, step back from the vendor decision for a moment and look at accessibility as a governance project across your site. The articles collected under our accessibility topic hub are designed to help with that broader picture.
And if you want help pressure-testing your current proposals or designing a governance-first engagement—whether that’s for a redesign now or for stabilizing the site you already have—you can get in touch to talk through the tradeoffs before you commit.
Accessibility isn’t just a label you buy once. It’s a set of ownership decisions, standards, and cadences you either design on purpose—or inherit by accident.