Adding Accessibility to Web Design Proposals

An accessibility web design proposal should name the target, the pages in scope, the checks to be run, and who owns the work after launch. A single line that says accessibility is included does none of that work. It leaves the client guessing what will be tested and your team guessing what counts as done.

Write the proposal as a short list of checkable promises. Each line should name a task, the pages or templates it covers, and the evidence the client will receive.

Key takeaways

• Name WCAG 2.2 AA as the target, and name the pages and templates it covers.
• Run a baseline scan before design work starts, and keep the dated report as the starting point.
• Put handoff in the proposal, with an editor guide, a named owner, and a retest date.
• Keep maintenance as its own line, so new content gets checked after launch.
• Promise tasks, checks, and reports, not a legal outcome.

What an accessibility web design proposal should name

Start with the target and the boundary. The target line can read: "We will check the site against WCAG 2.2 AA." List the templates in scope, such as the homepage, a service page, a contact form, and a booking flow where the site has one. Then list what sits outside this job, such as archived documents, a third party booking widget the client controls, or captions for old videos.

Add a line on how the work will be checked. Say the site will get an automated scan and a manual pass with a keyboard and a screen reader on the key flows. A scan is a starting point, and a quick manual keyboard and screen reader check is part of good practice.

Use the table below as a shape for the scope section. The hours are example planning figures only, not Axeazy prices, not quotes, and not promises about any real project.

Scope line	Example planning time	What the client receives
Baseline scan and report	4 hours	A dated report listing pages checked and issues found by type
Keyboard and screen reader pass on key templates	6 hours	Notes on each key flow, with the steps that failed and the steps that passed
Fix pass on templates and shared components	8 hours	Code changes for the templates in scope, plus a note on what still needs human review
Handoff notes and editor training	2 hours	A plain language guide for the people who will add pages and images
Repeat check and short report	3 hours	A repeat scan, a manual pass on changed templates, and a short written report

Each row answers three questions: what happens, how much time is set aside in this example, and what arrives at the end. For a deeper look at agency tool costs beside agency time, see the pricing math for agencies at 10 client sites.

This article is general information, not legal advice. Ask a qualified attorney to review contract wording before it is sent.

Start with a baseline scan

A baseline scan is the report you take before design or fix work starts. Run it on a representative sample, not only on the homepage: the homepage, text heavy pages, pages with images or media, forms and transactions, login pages where the site has them, dynamic content such as popups, and navigation and search pages. That sample catches template problems early, when a fix in one template repairs many pages at once.

Keep the baseline report with its date, the pages checked, the tool used, and the findings grouped by type. When the fix pass is done, run the same sample again and compare the two reports. The client can then see what changed, what remains, and what needs a human decision.

Do not let the baseline report stand alone as the whole check. Open the key flows and press Tab through them without a mouse. Listen to one flow with a screen reader. Check that form labels read clearly and that error messages say what went wrong and how to fix it.

Plan the handoff

Handoff is where many good builds lose their gains. The site leaves your team in good shape, then a new editor uploads images without text alternatives or adds a popup that traps keyboard focus. A proposal that names handoff work gives the client a fair chance to keep the site working.

Put these items in the handoff section:

• Fixed code and final report together. Deliver both with the date, the pages checked, and the items that still need human review marked plainly.
• A short editor guide. Cover text alternatives for images, heading order, link text that makes sense on its own, form labels, and captions for new videos.
• A named owner on each side. Name the client side owner for new content, and your side contact for problems that owner finds.
• A retest date. Say what that retest covers: the same sample pages, plus new templates added since launch.

Add one line on approvals. Color changes affect brand and design, so put them in an approval step and name who signs them off. The same applies to heading order changes that move existing tags.

Keep maintenance in the proposal

New content reintroduces problems. A maintenance line in the proposal turns that fact into a plan instead of a surprise bill.

A maintenance line should name the rhythm, the sample, and the report. A plain version reads: a repeat scan after each release, a manual pass on changed templates, and a short monthly report listing the pages checked, the issues found, the fixes shipped, the items that still need human review, and the next retest date.

Maintenance also covers small decisions that pile up. A new form, a new landing page template, or a new third party widget each deserves a quick check before it goes live. Write that check into the maintenance line as a task, with an example time beside it.

How Axeazy helps with this exact issue

Axeazy scans a site for WCAG 2.2 AA problems using axe-core, then fixes the underlying code instead of painting a script over the page. For a site with a GitHub repository, fixes arrive as a real pull request with a visible code diff for review and merge. Every scan and fix is recorded with a date and time, giving the agency and the client a dated record of the work.

For WordPress clients, the free plugin applies 3 fixes instantly at render time: a skip link, the page language attribute, and an alt text fallback. Paid plans add weekly scans and other fixes. Color contrast is detected and a correct color is calculated, but a visible color change is never applied without owner approval. Read the honest scope on the capabilities page, and read the risk scoring method to see how findings are ranked.

Agencies can run this work across a portfolio from the agency plan page, which covers up to 10 client sites with a white label portal, bulk scanning, per client risk scoring, and white label reports and badge. Plan options are on the plan options page.

Start a proposal with facts. Run the free 60 second scan on the Axeazy home page on the client site before you write the scope lines, and use the dated report as the baseline the proposal refers to.

Last checked: October 26, 2026.

FAQ

How much time should accessibility add to a proposal?

It depends on the number of templates, the number of key flows, and the state of the current site. Use the scope table as a planning shape, and replace every hour figure with a figure based on the site in front of you. Those hours are example planning figures only, not prices and not promises.

Should a proposal promise a result for a client site?

No. A proposal should promise tasks, checks, and reports: a baseline scan, a manual pass on key flows, code fixes for the templates in scope, a handoff guide, and a dated record of what was found and fixed. Whether a site meets a legal standard is a question for a court or a qualified human auditor.

What belongs in the baseline scan report?

A baseline report should carry its date, the pages and templates checked, the tool used, and the findings grouped by type. It should also mark items that need human review, such as a label that reads poorly aloud. That report becomes the starting point for the fix pass and the measure for the retest after launch.

Who owns accessibility after handoff?

The client owns new content after handoff, and the proposal should name that owner by role. Your team owns the maintenance line the client buys: the repeat scans, the manual pass on changed templates, and the short report. Naming both owners prevents a gap where each side assumes the other side is checking.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.2, checked October 26, 2026
• Guidance on Web Accessibility and the ADA, checked October 26, 2026
• How to Write Accessibility Requirements in RFPs, checked October 26, 2026
• How to Perform a Web Accessibility Audit: Step-by-Step Guide, checked October 26, 2026