Accessibility is the reason, but it is line 47
Many public-sector website RFPs are written for a redesign, with ‘must meet WCAG’ added near the end. Then the evaluation scores design concepts and price, and accessibility becomes a checkbox every bidder ticks.
If the April 2027 or April 2028 date is why the project exists, the RFP should say so in its scope, requirements, and scoring.
On April 20, 2026, the Department of Justice extended the Title II web and mobile app compliance dates. State and local government entities with a total population of 50,000 or more now have until April 26, 2027. Entities under 50,000, and every special district government, now have until April 26, 2028. The technical standard did not change: WCAG 2.1 Level AA. Source: the DOJ interim final rule extending the Title II compliance dates (91 FR 20902).
Scope: say what is actually in play
List every property the work covers, not only the main site. Include subdomains, department sites, document libraries, forms, and third-party tools. If you do not have that list, make inventory the first deliverable.
Separate the work clearly:
- Remediation of existing sites.
- Any new build or redesign.
- Ongoing monitoring and fixes after launch.
- Editor training.
Each has a different budget and timeline. Bundling them hides the trade-offs.
Requirements: name the standard and the evidence
Name WCAG 2.1 Level AA, which is the Title II standard, with a link to the WCAG 2.1 specification from the W3C. Then require evidence:
- Manual testing with keyboard and at least one screen reader, not only automated scans.
- Testing of components and templates, not sample pages alone.
- A defect log with severity, owner, and status.
- Accessible PDFs or HTML alternatives for required documents.
Questions that separate bidders
Show us a remediation plan you delivered
Ask for a redacted plan or a public case study, not a promise.
Who does the manual testing?
Named roles, and whether testers include people who use assistive technology daily.
What happens after launch?
Content drifts. Ask how the vendor keeps it accessible in month six, not just on day one.
How do you handle third-party tools?
Calendars, payment portals, and forms often fail. Ask how the bidder works with those vendors.
Promises that should worry you
- “Guaranteed compliance.” Nobody can guarantee a legal outcome.
- An overlay presented as the whole solution. Overlays do not fix the underlying code or content issues.
- “100% automated.” Many success criteria need human judgment.
Contract language that protects you
Ask counsel to include acceptance criteria tied to WCAG 2.1 AA, a remediation window for defects found after acceptance, and accessibility requirements for any subcontracted or licensed component.
A hypothetical: two ways to write the same RFP
Imagine a county issuing a website RFP. Version one describes a redesign in detail and adds “must comply with WCAG” as a line in the technical requirements. Every bidder agrees, and the award goes to the strongest design concept. Accessibility issues surface after launch.
Version two opens with the county’s Title II date, lists every property in scope, separates remediation from redesign, and gives accessibility its own scored section with evidence requirements. Bidders have to show how they test. The county can compare real approaches instead of identical promises.
A scoring rubric you can adapt
Give accessibility its own section and score it on evidence:
- Method: manual and automated testing described clearly, including assistive technologies used.
- Experience: public examples or redacted plans from comparable remediation work.
- Team: named roles responsible for accessibility, not a general statement.
- Content: how the bidder handles documents, media, and editor training.
- After launch: a credible plan for keeping conformance as content changes.
- Third parties: how the bidder works with vendors whose tools are embedded in the site.
Deliverables to name in the scope
- An inventory of in-scope properties, if you do not have one.
- An audit report against WCAG 2.1 AA with prioritized findings.
- A remediation plan with owners and dates.
- Fixed components and content, verified by retesting.
- Editor guidelines and training sessions.
- A handoff plan for ongoing monitoring.
Common RFP mistakes
- Scope limited to the main site. Department and vendor sites are left out, and so is the risk.
- One price for everything. Remediation, redesign, and support are bundled, so trade-offs are hidden.
- No acceptance test. The contract says “accessible” but never says how that will be checked.
- Documents ignored. Required forms and notices stay as inaccessible PDFs after launch.
Frequently asked questions
Should we require a specific CMS?
Only if you have a real reason. Accessibility depends far more on templates, content, and process than on the platform.
Can we score accessibility separately from design?
Yes, and you should. Give it its own weighted section with evidence requirements.
Is WCAG 2.2 required?
The Title II rule names WCAG 2.1 AA. Many teams build to 2.2 anyway; that is a choice, not the legal floor.
Will KWALL respond to RFPs?
Yes. If you are issuing one, tell us the due date when you get in touch.
How long should the evaluation of accessibility take?
Long enough to read the method and examples carefully. Some teams invite finalists to walk through how they would test one of the entity’s own pages.
Should we require bidders to audit our site before proposing?
Not as unpaid work. You can share known issues or a recent audit so bidders can scope accurately.
Can we reuse our last RFP?
Use it as a starting point, then rewrite scope, requirements, and scoring with Title II as the driver.
Next step
Drafting an RFP or reviewing responses? Tell us what you are working on.
