A Guide to Website Accessibility (WCAG) for Freelance Developers

Turn accessibility requests into testable deliverables#

Ask which users, pages and complete tasks the client needs to support, then name the accessibility target and acceptance process in the Statement of Work (SOW). This gives the build a clear scope and the client evidence of what works at handoff.

Clients ask for "ADA compliant" because they want accessibility and they want coverage. You can deliver accessibility without pretending you control their entire legal exposure. Move the conversation from "compliance" (a legal outcome) to web accessibility requirements (a buildable, testable deliverable).

The U.S. Department of Justice notes that "existing technical standards provide helpful guidance" for website features, including WCAG and the Section 508 Standards (DOJ web guidance page dated March 18, 2022). That gives you a solid standard to reference as a developer. A standard, not a promise.

The freelancer-safe translation (what you write into the SOW)#

A Statement of Work (SOW) defines "project scope, deliverables, timelines, and responsibilities between parties." Use it as intended. Convert vague language into bounded, testable commitments:

The evidence pack you ship (so acceptance stays clean)#

Ship a lightweight proof bundle alongside the release so everyone signs the same reality:

On the contract side, have baseline risk controls ready to drop in: Limitation of Liability (caps the amount of damages one party can recover from another), Indemnification (shifts risks or potential costs from one party to another), Termination (notice requirements, termination rights, and consequences of ending the contract), Governing Law (which state or country's laws apply), Jurisdiction (which court or legal system has authority), and Dispute Resolution (the process for dealing with disputes arising out of the agreement).

What does "website accessibility" (and "ADA compliant website") actually mean for developers?#

Website accessibility means you build sites so people with disabilities can actually use them, not just view them. You now have a way to translate "ADA compliant" into SOW-ready acceptance criteria. Next, you need a technical definition you can build to, test, and explain to non-technical stakeholders without absorbing legal risk you cannot control.

The W3C's WAI framing is the safest mental model. Design and develop so people can perceive, understand, handle, and interact with the web. In practice, that means the experience still works across different ways people handle and consume content.

"ADA compliant website" vs. "WCAG compliance" (what you can promise)#

Clients often use "ADA compliant" as shorthand for "we don't want accessibility problems." Treat that as a legal label, not a technical specification.

Distinguish the ADA statute from regulations issued under it. DOJ guidance points private-sector businesses to WCAG, while the Title II web rule for state and local governments specifies WCAG 2.1 AA. Match the client’s applicable requirement and procurement terms, then write a measurable engineering commitment rather than a guarantee about litigation outcomes.

Use this translation:

Define the terms in kickoff (so scope stays real)#

Lock these definitions into your kickoff doc and SOW so you do not inherit unbounded legal risk:

• WCAG Success Criteria are the requirements within WCAG that teams test against. WCAG defines three conformance levels (Level A, AA, AAA), and each level has its own Success Criteria.
• ARIA (WAI-ARIA) is a W3C standard that defines a way to make web content and web applications more accessible, especially for dynamic content and advanced controls. Translate that into dev tasks: correct semantics first, ARIA only when needed, predictable focus order, and no keyboard traps.
• Accessibility is a team sport. Section 508 guidance explicitly emphasizes that developers work together with designers and content creators. Content creators also usually write better alt text because they know what the image needs to communicate.
• Accessibility statement is a public-facing page that states your commitment to accessibility. Include your commitment to accessibility, contact info for problems, any known limitations, and the environments you tested. If you're applying a specific accessibility standard, say what it is. This protects users and keeps expectations aligned.

Which WCAG version and level should you build to in 2026-and when does it become "legal"?#

For new builds in 2026, WCAG 2.2 Level AA is often a practical technical target-unless a client's written policy requires a different version/level. Put the exact version and level in the SOW. Once you define accessibility in developer terms, you still need a crisp decision that holds up when procurement, legal, or a VP asks, "So what exactly are we building to?"

WCAG 2.2 was first published as a W3C Recommendation on October 5, 2023, with a later Recommendation dated December 12, 2024. It adds nine success criteria relative to WCAG 2.1 and removes the obsolete Parsing criterion. Name the exact target; an older regulatory or procurement version may still require its own checks even when you build to 2.2.

Pick the level like an operator (risk, scope, proof)#

WCAG success criteria come in A, AA, AAA. Many client conversations land on AA because it creates a meaningful bar without turning the project into a research lab.

Treat AAA as a special case. WCAG itself warns you here: "It is not recommended that Level AAA conformance be required as a general policy for entire sites."

Two contract moves reduce legal risk immediately:

• Bind the commitment to in-scope deliverables. Example: "Marketing site templates and components listed in Exhibit A," not "the entire web presence."
• Bind the work to the tested release at handoff. Deliver the agreed evaluation and remediation results for that release. Reserve a conformance claim for satisfaction of the full applicable requirements; future content changes require separate review.

When does it become "legal" (and what you should promise)#

Accessibility laws often focus on outcomes and duties, not a single WCAG version by name. Your job is to avoid promising global "legal compliance," and instead promise documented alignment to a chosen WCAG target.

Safe operator rule: you are not selling "ADA compliance" everywhere. You are selling WCAG conformance work to an agreed target (for example, WCAG 2.2 AA when appropriate, or whatever version/level the client requires), plus test methods and documentation that a professional can defend.

The "5-Gate Accessibility Delivery System" (your mental model before tactics)#

Treat accessibility like compliance operations: gated, traceable, and defensible, not a vague "we'll try." Once you pick a WCAG target (based on the client's required version/level), you need a delivery model that keeps scope clean, verification repeatable, and the paper trail obvious.

Here's the operator mental model. Every gate produces an artifact you can point to later. If a gate stays vague, the project turns into infinite remediation and you end up "owning" the client's accessibility compliance posture forever.

The gates (what you decide, what you document)#

Gate 1: Scope (SOW). Define what you evaluate and what you do not. WCAG-EM (W3C's evaluation methodology) starts with "define the scope of your evaluation," and it includes selecting a representative sample when it's not feasible to evaluate every page.

Put that into your Statement of Work (SOW) using nouns, not vibes:

• In scope: named templates, components, and critical journeys (checkout, signup, contact).
• Out of scope by default: third-party widgets, embedded iframes, client-authored CMS content, and anything that changes outside your release process (unless explicitly included).

Gate 2: Standard (WCAG target + interpretation rules). Specify the WCAG version/level you're targeting and write down your assumptions: supported browsers, breakpoints, and assistive-tech expectations for testing. WCAG says "success criteria are written as testable criteria for objectively determining" conformance, so your rules must make tests reproducible.

Gate 3: Verification (hybrid testing + mapping). WCAG says testing involves "a combination of automated testing and human evaluation." Use automation to scale and humans to validate behavior:

• Automated checks: WAVE (it can identify many WCAG errors and also "facilitates human evaluation," which makes it useful for guided review), plus other automated checkers as appropriate.
• Manual: keyboard-only pass, focus order, visible focus, and a screen reader smoke test.
• Every finding maps to a WCAG Success Criterion. No orphan "bug vibes."

Gate 4: Sign-off (report + known issues register). Deliver a conformance-style report in a consistent format (W3C provides a recommended report template for WCAG evaluations). Include a known-issues register that separates fixed, not fixed (out of scope), and deferred. This becomes your audit trail and stops scope creep from rewriting history.

Gate 5: Change control (maintenance triggers). Accessibility is maintained, not achieved once. Content or feature changes can invalidate prior results. Put explicit retest triggers in writing and schedule when testing occurs (Section508.gov frames this as planning when accessibility testing will happen). That way your work stays current instead of quietly expiring.

What should be in scope (and out of scope) for accessibility so you don't get stuck owning the whole internet?#

Scope accessibility around what you can control, ship, and retest, then put the boundary in writing so "accessibility compliance" doesn't turn into an unlimited obligation. With your gating model in mind, this section turns "Scope" into language you can defend when a client adds pages, plugins, or "one more flow" after launch.

Scope what you can actually test (templates, components, journeys)#

WCAG evaluations work best when you define a target you can fully evaluate. WCAG-EM scope includes "all web pages, web page states, and functionality" within that target. So pick units that stay stable: templates/components and critical user journeys, not "every URL that ever exists."

Sampling can support an evaluation, but it does not establish that every untested page conforms. Include representative templates, important states and every step of complete processes within the evaluation scope. Report the sample and limits; if checkout includes address entry, delivery choice, payment and confirmation, test the whole process rather than only the payment widget.

Practical default:

• List in-scope templates by name (Homepage, Product Detail, Checkout, Contact, Account, Blog Article).
• List in-scope components (Header/nav, modal, carousel, filters, form fields, error summary, pagination).
• List in-scope journeys (signup, checkout, password reset, contact submission), including key states (empty, error, success).
• Tie acceptance criteria to a named standard for those deliverables (for example, the WCAG version/level you and the client choose-e.g., WCAG 2.2 AA or WCAG 2.1 AA, as appropriate) and to WCAG Success Criteria (which are "testable criteria for objectively determining" conformance).

Exclude (or explicitly price) the landmines: third-party, content, and change#

Contract exclusions do not change WCAG conformance rules. Conformance covers full pages and complete processes, including third-party content; a passing component cannot establish that the whole checkout conforms. If uncontrolled third-party content prevents conformance, document the issue and assess whether a statement of partial conformance is appropriate. That statement is not a claim that the page conforms.

Use this to structure scope, not to argue.

Boundaries for semantics and interaction (so nobody "forgets" who owns what): You are making the ownership line explicit, so nobody "discovers" it at launch.

• Dev owns: headings/landmarks, keyboard focus order, form labels, error handling, ARIA patterns where needed, screen reader support for implemented UI.
• Client owns: alt text and meaning (WAI notes the "text alternative needs to be determined by the author" based on context), captions/transcripts, final copy approvals, and any brand decisions like allowing contrast adjustments.

SOW paste block (hard boundary checklist):

• In-scope templates/components/journeys: [list].
• Standard: Conformance efforts performed against WCAG (version/level) for in-scope deliverables, verified via the agreed test plan.
• Third-party items present: [list]. Treated as third-party constraints where you can't control remediation; any related issues are documented as such.
• Client content responsibilities: alt text, media alternatives, copy approvals.
• Post-handoff: regressions from CMS edits/plugins/features sit outside this SOW unless covered by a maintenance agreement.
• Accessibility statement owner: Client (you can draft as an add-on).

How do you prove a site is accessible (without pretending automated tools equal compliance)?#

Combine automated checks with manual evaluation against the named criteria. A keyboard and screen-reader smoke test is a useful starting point, not a complete Level AA evaluation. Record applicable criteria, tested states and unresolved failures so a finished test plan is not confused with a passing conformance result.

W3C puts the core truth plainly: "Testing the success criteria would involve a combination of automated testing and human evaluation." And separately: "no tool alone can determine if a site meets accessibility standards." Treat every automated report as a fast signal, not a certificate.

A baseline verification stack (what many teams run every release)#

Automated sweep (fast fail detection): Run automated web accessibility evaluation tools across the in-scope templates and key states (for example, WAVE). Use these tools to surface likely failures and create a baseline you can rerun after fixes. WAVE frames this correctly: it "identif[ies] many... WCAG errors, but also facilitates human evaluation."

Manual content + keyboard pass (non-negotiable): Review the content, and walk the critical flows using only a keyboard. Check for things like:

• Visible focus on interactive elements.
• A focus order that follows the intended reading/visual order.
• No keyboard traps (especially in modals and menus).
• Menus, dialogs, and form errors that stay usable without a mouse.

Screen reader spot check (reality check): Use a screen reader as part of manual testing, and document what you used in your report (example: VoiceOver + Safari on macOS, or NVDA + Firefox on Windows). Validate things like:

• Accessible names and labels (buttons, inputs, links).
• Headings and landmarks for navigation.
• Key changes that are understandable when handling with a screen reader.

For an illustrative form test, leave a required email field empty and submit using only the keyboard. Check that the error identifies the field, provides useful correction guidance, and is available to a screen reader; then correct the value and complete submission. Capture the page state, browser/assistive-technology version and expected versus actual behavior in the issue record. Retest the same path after the fix, including any dialog or confirmation state.

Deliverables clients can review (and you can point back to later)#

Give the client a clean packet:

Make it audit-ready by default. Store automated reports, manual test notes, issue tickets, and sign-off emails in one shared "accessibility conformance file." It will not guarantee outcomes, but it will keep your practice consistent and easy to retest.

Want a quick next step for "website accessibility for developers"? Try the SOW generator.

What to write into the contract: acceptance criteria, responsibilities, and liability limits#

You reduce accessibility legal risk by translating "ADA compliant" into written, testable acceptance criteria (often anchored to WCAG), then tying sign-off to documented testing records. Once you have that documentation, your contract should make those artifacts the finish line, not a vague promise.

Section508.gov gives you the operational principle: when you write a Statement of Work (SOW), you should "clearly define your criteria." For accessibility work, that means you define (1) which standard you build to, (2) how you test, and (3) what "Done" means.

Convert "ADA compliant" into acceptance criteria you can actually deliver#

Use ADA language for the business, and WCAG language for the engineering. ADA.gov points to WCAG as a technical standard that provides guidance for web accessibility, so anchor your build and your tests there.

Here is contract-ready language you can adapt:

Retain automated outputs, manual test observations, issue fixes and the tested release identifier together. A client can accept a remediation report with remaining failures, but that acceptance does not turn those failures into WCAG conformance.

Assign responsibilities for changes, testing and contract risk#

In many projects, you won't fully control all client-managed content or third-party components-so write that reality into the SOW.

• Client responsibilities: clearly define what the client owns (including content and third-party components), what they need to provide on time for testing, and what happens to schedule and acceptance if inputs or approvals slip.
• Change control: state that new pages, features, plugins, theme edits, or content changes may trigger re-testing, because changes can invalidate prior test results.

Then add baseline legal safety rails (run these by a lawyer in the governing jurisdiction):

• Limitation of liability: agree the recoverable-loss categories and any cap. Its effect depends on governing law and the contract; it does not guarantee that no other duty or claim applies.
• Indemnification: define the covered claims, notice, defense control and cost allocation. Keep the responsibility proportionate to the work and content each party controls.
• Governing law and jurisdiction: choose the contractual law and dispute forum, while recognizing that mandatory accessibility duties may still apply to the client’s services.

Cross-border reality check: what changes by country/program, and how to confirm safely#

Accessibility obligations change by market and buyer type, so you stay safe by confirming the applicable policy in writing and scoping your delivery to an auditable standard. Once your contract defines "Done" as testable WCAG acceptance criteria, you need one more system. A repeatable way to handle cross-border work without guessing which law applies.

What actually changes (and why your client type matters)#

Think in two tracks: procurement-driven requirements (often explicit) vs general legal exposure (often interpreted through case law and regulator guidance).

Here are the high-signal regimes you will run into:

Don't guess: install a "confirm locally" step (and ship procurement-friendly artifacts)#

Make this a standard step in your intake and SOW workflow:

• Ask, in writing: "Which policy or standard are you held to (procurement requirement, regulator guidance, internal accessibility policy)?"
• If they cannot answer, propose a default: engineer to WCAG Success Criteria for in-scope deliverables (version/level agreed in writing) (as a project standard, not a legal claim) plus an optional specialist audit tailored to their jurisdiction/program.

Then reduce friction (and protect yourself) with two artifacts:

• One-page "Accessibility Approach" appendix in the SOW: scope boundaries, target WCAG level/version, test methods (automated plus manual), and your evidence pack (test plan, results, known-issues register).
• Draft accessibility statement template for the client's legal/compliance team to approve. You provide structure and inputs, they own the legal positioning.

Finally, handle "client in one country, users in another" cleanly. Specify Governing Law and Jurisdiction for the contract, and offer an upgrade path (for example, a regional audit add-on) without implying the site becomes "compliant everywhere." If a client demands a guarantee of legal compliance, refuse the guarantee and sell what you can control: WCAG-aligned engineering plus documented verification.

The safe default: ship WCAG as a gated, documented service, not a vague promise#

Treat "ADA compliant" as a translation problem, not a promise you can safely guarantee. At this point you have the definitions, the test approach, and the scope boundaries. Now you turn it into an ops system: WCAG 2.2 AA (or WCAG 2.1 AA) + explicit scope + explicit tests + sign-off artifacts.

MDN frames WCAG as recommendations developed by W3C's WAI, and it notes WAI recommends using the most recent version (WCAG 2.2) to drive the best possible accessibility. ADA.gov also positions WCAG (and the Section 508 Standards) as existing technical standards that provide helpful guidance. That combination gives you a professional anchor without turning your SOW into a legal guarantee.

Your next-project implementation: the 5-Gate system (kickoff to sign-off)#

Put this directly into your kickoff doc and Statement of Work (SOW). The goal: every gate produces an artifact. No artifact, no progress, no ambiguity.

• Gate 1: Scope. List the pages, states, templates and complete user processes to evaluate, with the sampling approach and limits.
• Gate 2: Standard. Name the applicable WCAG version/level, relevant procurement requirements and supported test environments.
• Gate 3: Verification. Build and remediate, then run the automated and manual evaluation plan. Map findings to criteria and record remaining failures; make a conformance claim only when its requirements are satisfied.
• Gate 4: Sign-off. Deliver the tested release identifier, results and known-issues register for written acceptance of the agreed work.
• Gate 5: Change control. Name who reviews CMS changes, plugins, new features and third-party updates, which changes trigger retesting, and the schedule or maintenance agreement covering those tests.

Legal rails to insert (risk control, not legal theater):

Copy/paste freelancer checklist (ship this every time)#

• WCAG target named (2.1 AA or 2.2 AA) plus WCAG Success Criteria mapping for key flows
• In-scope templates/components listed; third-party tools listed as exclusions
• Test plan defined (keyboard + screen reader + automated) and automated tool(s) named (for example, WAVE)
• Acceptance/sign-off process written plus known-issues register included
• Contract includes: Limitation of Liability, Indemnification, Termination, Governing Law, Jurisdiction, Dispute Resolution

If you want accessibility work to run like an ops system, package it as a repeatable compliance pack: scoped, gated, and audit-ready, like a reconciliation pack finance teams expect. That posture keeps deals moving and keeps your risk contained.