Accessibility requirements for a website RFP

Why the contract matters

The Justice Department’s ADA Title II rule says a state or local government’s web content and mobile apps must meet WCAG 2.1 Level AA, including content someone else provides for it. The Department’s own fact sheet gives the example of a county parks page built and updated by a local web design company: it still has to meet the standard. The same goes for the calendars, payment systems and reservation tools you embed.

Accessibility that is written into the RFP gets designed in from the start. Accessibility that isn’t becomes a change order after launch, usually at a higher price. Nonprofits are not covered by Title II, but the same contract terms protect you and the people you serve. (The deadlines are on our ADA Title II page.)

What to require

1. A named standard, applied to everything

Require WCAG 2.1 Level AA at minimum, and ask for WCAG 2.2 Level AA. 2.2 includes everything in 2.1, and W3C encourages using the latest version. Name the version and level; “ADA compliant” on its own means nothing testable. Apply it to every deliverable:

• Templates, components and every page the vendor builds or migrates
• Mobile apps
• PDFs, forms and other documents the vendor creates
• Third-party tools the vendor provides or recommends
• The editing screens your staff use, so staff with disabilities can do their jobs

2. An Accessibility Conformance Report

An Accessibility Conformance Report (ACR) documents how a product meets an accessibility standard, criterion by criterion. Most are written on the Voluntary Product Accessibility Template, or VPAT, from the Information Technology Industry Council. Ask for one with the proposal for any platform or product, and again before acceptance for what the vendor builds for you.

Make sure it reports against WCAG 2.1 AA or 2.2 AA. The federal Revised 508 Standards still incorporate WCAG 2.0, so a report written only for Section 508 can skip the 2.1 criteria the Title II rule requires. Read the terms closely. Section508.gov explains that “partially supports” means the product does not conform, and “not evaluated” means nobody checked.

3. Testing with assistive technology

Require the vendor to test with automated tools, by hand, and with the assistive technology people actually use: keyboard only, zoom to 400%, and at least one screen reader on desktop and one on mobile. Ask them to test your top tasks end to end, such as paying a bill or applying for a permit, and to share the results. Better still, ask how they include people with disabilities in testing. Reserve your right to test independently before you accept the work.

4. Acceptance and a remediation warranty

Make conformance a condition of final acceptance. If testing finds a problem, the vendor fixes it at no cost within a set time. Then add a warranty: for a period after launch, the vendor corrects any nonconformance in what it delivered. Require that updates and replacements during the contract never lower the level of conformance you accepted.

5. Documents and third-party tools

Spell out that documents the vendor produces are accessible, and that any plugin, form builder, map, chat or payment tool it proposes comes with its own ACR. If a tool doesn’t conform, you want to know before you pick it, not after residents complain.

6. Training and handoff

Sites stay accessible when the people who post content know how. Require training for your editors, written guidance for the templates and components delivered, and the final test results and conformance report as part of the handoff.

7. A person who is accountable

Ask who will be responsible for accessibility on your project and what their experience is. Section508.gov’s sample clauses require that the people doing the work have the knowledge to meet the standard, with documentation on request.

Sample contract language

The clauses below are a starting point, adapted from the federal sample language on Section508.gov. Have your attorney or purchasing office fit them to your rules. Bracketed values are yours to set.

Red flags in proposals

• “ADA compliant” with no standard named. If they can’t say which WCAG version and level, they aren’t testing against one.
• An overlay as the plan. A widget doesn’t make a site conform, and the FTC made one of the best-known vendors pay $1 million for claiming it did. More in our article on overlays.
• Automated scans only. A score from a scanner is a start, not proof. W3C says tools can’t determine accessibility on their own.
• A weak conformance report. Years old, for a different version of the product, “supports” on every line with no notes, or full of “not evaluated.”
• Accessibility as an add-on. An optional line item, or a “phase 2” after launch.
• Silence on documents, third-party tools and training. That is where most sites slip after launch.
• A demo they can’t do by keyboard. Ask finalists to show their work using only a keyboard, then with a screen reader. It takes 10 minutes and tells you more than the proposal.

Score it, don’t just check it

Section508.gov notes there are several ways to build accessibility into a solicitation, as a requirement or as an evaluation factor. Do both: make conformance mandatory, then give points for the strength of the testing plan, the quality of the conformance report and the live demo.

This article is a plain-language summary, not legal advice. Sources: ADA.gov fact sheet on the Title II web rule, Section508.gov sample contract language, Section508.gov ACR Issue Detail Supplement, W3C WCAG overview.