Offering accessibility as an agency: scope, delivery and what to promise

Accessibility is easy to oversell because the result a client wants, a site that meets the law, is not something a vendor can hand over. WCAG 2.2 defines conformance for full web pages and for complete processes such as checkout, at a stated level, and it says that content added later by other people can affect the result. So the offer that holds up is one where the scope, the method and the outcome are written down separately. This guide covers what to sell, how to scope it, how to deliver it and what to say. It is general information, not legal advice: ask a lawyer about contract wording and about what a law requires of a particular client.

What an accessibility offer is made of

Most agency accessibility work falls into five services. They can be sold separately or together, and each one needs different things written down.

An audit is the usual first sale, because it turns "make us accessible" into a list. W3C's planning guidance says a detailed review of existing sites can create a baseline for future work and clarify how big the problem is.

Scope: what to write down before any work starts

A scope that names the standard, the pages and the exclusions protects both sides. Seven items cover most of it.

• Standard and level. W3C's interim repairs guide calls the latest version of WCAG at Level AA the generally accepted target, and notes that it may already be the client's policy or a legal requirement. Name the version and level exactly: a law, a buyer or a contract may name a different version. Our pages on which WCAG version to use, conformance levels and WCAG, the ADA and Section 508 help the client choose. WCAG itself advises against requiring Level AAA as a general policy for entire sites.
• Pages, templates and processes. Conformance is for full pages and cannot be achieved if part of a page is excluded. For a process, every page in it must conform, and WCAG's own example is an online store from the first page through checkout. Scope by template and by complete process, and list the URLs.
• Technologies and test environments. Name the browsers and assistive technologies you will test with. A WCAG conformance claim must list the technologies relied upon, and may list the user agents, including assistive technologies, used for testing.
• Exclusions. Embedded chat, booking and payment widgets, advertising, user comments and a legacy section due for removal are the usual ones. WCAG notes that content you do not control can affect the accessibility of content you do, and it describes a statement of partial conformance for such pages. Name each excluded item and say who contacts that vendor.
• The platform. The CMS, theme or app builder limits what can be fixed, and W3C's planning guidance asks whether the CMS supports the organization's accessibility commitments, so check early. Our pages for Shopify, WordPress, Wix, Squarespace and Webflow cover what each platform's own documentation and tools say.
• Ownership after launch. W3C's roles and responsibilities mapping, a draft, says writers, designers and developers each own different parts of accessibility, and that when it is left until late the work often falls on developers, outside their skillset. Write down who owns alt text, headings and documents on new content (usually the client's authors) and what guidance you provide.
• Acceptance and "done". W3C's planning guidance lists acceptance testing, making sure any agency-delivered website or component meets the desired level, among the example responsibilities inside a client organization. Expect the client to test your work, and agree the method in advance: the same sample, the same checklist, the same assistive technology. Define done as every in-scope finding fixed and retested, not as "no one will ever find another issue". Clients may also write accessibility criteria into requests for quotations and contracts, as W3C recommends; see accessibility in procurement.

Delivery: five phases

W3C describes planning and managing accessibility as activities that are not necessarily carried out in sequence and are ideally repeated over time. For a client project, five phases cover it.

1. Discovery

   Learn the client's key tasks, platform, who edits content and which obligations they believe apply. W3C's guidance on exploring the current environment includes cursory checks of key websites and user activities, and of the editing and publishing process. On obligations, point the client to our laws questionnaire and to a lawyer.

2. Baseline audit

   Test the agreed sample and record each failure against its success criterion. W3C's planning guidance notes that checks can happen at every stage, for example on color choices in mocked-up designs. For a new build, evaluate at key milestones and sprints.

3. Prioritize and fix

   W3C's interim repairs guide suggests starting with key tasks such as registration, search and checkout, and with repairs that are high-impact (on many pages, on frequently used pages, critical to a process or at Level A) or low-effort. It also describes a phased target: certain criteria in the next release and all Level A and AA criteria in the one after. The implement phase adds building accessible templates and components first. Fix a shared component once, not page by page.

4. Retest and hand over

   W3C's interim repairs guide says to validate solutions as early as possible and, if at all possible, to involve people with disabilities. Hand over the retest results, the dated test notes, content guidance for the client's authors and a draft statement.

5. Sustain

   W3C's guidance on the sustain phase says changing content can introduce accessibility issues, and recommends regular reviews, checks inside the publishing process and a consistent report format. Sell this as a retainer or as monitoring, so the end of the project is not the end of the testing.

What to promise, and what not to

Promise the work, the method, the standard and the date. Do not promise an outcome that depends on things the agency does not control.

The FTC's April 2025 final order against accessiBe required a $1,000,000 payment. The FTC had charged that claims its product would make websites WCAG-compliant were false or unsubstantiated, and the order bars the company from making such claims without evidence. The order binds accessiBe, not agencies, but if you resell or install a third-party product, a compliance claim you repeat to a client becomes yours to support (GotAlt's reading). See alternatives to accessibility overlays and overlays and the FTC.

A logo or badge is a claim too. WCAG says a conformance logo must come with the claim's required details: the date, the WCAG version, the level, the pages covered and the technologies relied upon. It also says conformance claims are not required, so for most clients a dated testing record is the better deliverable.

The statement and the handover pack

W3C's guide to developing an accessibility statement says a statement should contain at least a commitment to accessibility for people with disabilities, the standard applied (its example is WCAG 2.2) and contact information for people who hit a problem. It advises adding known limitations, the measures taken, technical prerequisites and the environments tested. It also advises plain language, such as "videos do not have captions" in place of a success criterion number, and says statements are not technical assessments or declarations of conformity, though they ideally point to the testing behind them, which adds verification and credibility.

For an agency, that points to a handover pack: the scope, the dated test notes, the open findings, content guidance for the client's authors and a draft statement. The client publishes the statement, so the client should approve every sentence of it (GotAlt's reading). W3C's planning guidance adds that a public statement identifying what works well and less well, explaining improvements to come and giving contact options can help gather feedback to prioritize repairs. If the client's buyers ask for a conformance report instead, the VPAT and ACR guide explains why a report records testing and does not replace it. Decide before launch who answers when a visitor reports a barrier; our guide to responding to accessibility complaints covers the next step.

What drives the effort

We quote no prices, because they vary with scope. In our reading, the factors that move the effort most are:

• the number of distinct templates and components;
• interactive features such as checkout, booking, maps and custom widgets;
• content volume: images needing alt text, documents, and video needing captions;
• limits set by the platform and by third-party embeds;
• the number of retest rounds.

W3C's guidance on budgets says needs depend on the accessibility goals and the extent of the work, including evaluations, testing with people, training and tooling. A narrow scope tested thoroughly is easier to defend than a wide one tested lightly, and it can grow in stages.

Check it yourself

Five free tools support an engagement:

• The WCAG audit checklist tracks all 55 Level A and AA success criteria in WCAG 2.2. Mark each one Pass, Fail or Not applicable, list the sample pages, add notes and export a CSV. Use it as the shared test log.
• The accessibility bookmarklet checks the page as your browser rendered it, including a staging site or a page behind a login, for alt text, headings, link names, form labels and contrast. Run it on each template before handover. It cannot tell whether a page works with a keyboard or a screen reader, so it supplements manual testing.
• The accessibility statement generator turns a short form into a plain-text draft statement, in your browser, to review and edit.
• The Which accessibility laws apply to me? questionnaire gives a client a sourced starting list. It is not legal advice.
• Scan my site for free runs rule-based checks on a client's pages as a first look. The report says what a scan leaves to a person, and the testing guide covers the manual checks.

Keep it checked

Between audits, the site changes. W3C's planning guidance says changing content can introduce accessibility issues, which is why it recommends regular review. GotAlt checks the pages you monitor every week. It compares the alt text of up to six images per page with the image itself, runs its rule checks, opens monitored pages in a browser for contrast and other checks that need a rendered page (see what we check), and reports what changed. Plans are from $69 a month. Audit my whole site from $69/mo.