Skip to main content

Resources

Accessibility Compliance Checklist

A practical walkthrough for teams getting their site audit-ready. Five sections, thirty checks — the ones that trip up real audits. Use it to scope the work, brief the team, and hand to a client or counsel.

Last updated · April 2026

Section 01

Scope the site

Before anything else, agree on what “the site” means, who owns it, and what counts as in-scope. Most accessibility programs stall because this was never written down.

  • Inventory every public URL

    Include marketing, help docs, blog, product pages, and any legacy subdomains. A sitemap or crawl export works.

  • Flag authenticated views that must also be accessible

    Customer portals and logged-in dashboards are rarely optional when a law or a contract applies to your org.

  • Note third-party embeds and who owns them

    Chat widgets, video players, consent banners, and booking tools live on your page even if someone else ships the code.

  • Pick an owner for accessibility decisions

    One name, not a committee. Escalation path from that person to legal and engineering is written down.

  • Agree on a sign-off process for material changes

    A new template, a redesign, or a launch should not go live without a scan and a reviewer.

  • Write the scope and owner into your accessibility statement

    A public page that names your target standard and contact point builds trust and, in many jurisdictions, is required.

Section 02

Design fundamentals

Most accessibility problems are born in design, not code. These checks catch the ones that compound across every page of the site.

  • Text meets WCAG contrast ratios (4.5:1 normal, 3:1 large)

    Apply the same rule to placeholder text, disabled states, and icons that carry meaning.

  • Every interactive element has a visible focus style

    Keyboard users need to see where they are. A default browser outline is fine; an invisible one is not.

  • Information is never conveyed by color alone

    Status, required fields, chart series, and form errors need a second cue (icon, label, text).

  • Animation respects the reduced-motion preference

    Wrap non-essential motion in a `prefers-reduced-motion: reduce` rule. Autoplay video and parallax are the usual suspects.

  • Body text is at least 16px by default

    Smaller than 14px is a user-testing failure; 12px mono is a contrast-plus-size trap.

  • Touch targets meet 24×24px minimum (WCAG 2.2)

    Buttons, links, and form controls on mobile. Spacing counts; adjacent targets must not overlap.

Section 03

Structure & semantics

Screen readers and search engines share a lot of DNA. Good structure helps both.

  • Every page has one h1 that names the page

    Not the company. The page. A visually-hidden h1 is fine when the visible design has a different header.

  • Heading levels cascade logically (no skipping h2 → h4)

    Screen-reader users navigate by heading. Out-of-order headings make them backtrack.

  • Landmarks are explicit: header, nav, main, footer

    Use the semantic HTML elements, not divs with role attributes.

  • Every image has alt text that serves its purpose

    Decorative images get alt="". Informative images get a description. Functional images describe the action.

  • Every form input has a programmatically bound label

    Either `<label for>` or wrapping `<label>`. Placeholder-as-label breaks autofill and screen readers.

  • Link text is meaningful on its own

    Lists of “Read more” and “Click here” are announced out of context by assistive tech.

Section 04

Keyboard & assistive tech

If someone cannot reach a feature with only a keyboard, it is not accessible. Test this yourself before a scan.

  • Every interactive element is reachable with Tab

    Menus, modals, carousels, and custom widgets included.

  • Focus order matches the visual reading order

    If the eye goes left-to-right, top-to-bottom, focus should too.

  • A skip-to-main-content link appears on Tab

    Keyboard users should not Tab through the entire nav on every page.

  • There are no keyboard traps

    Modals close with Escape. Carousels do not swallow Tab. Third-party embeds are the usual offenders.

  • Dynamic UI changes are announced to screen readers

    Use `aria-live` regions for toasts, validation errors, and progress updates.

  • Run at least one manual pass with a screen reader per release

    VoiceOver on macOS, NVDA on Windows, or TalkBack on Android. Automated tools miss cognitive and label issues.

Primary WCAG references

Section 05

Compliance posture

Accessibility is a program, not a one-off fix. These are the commitments you make public and keep on record.

  • Pick the target standard and write it down

    WCAG 2.2 Level AA is the modern default. See the coverage library for which regulation points at which version.

  • Publish an accessibility statement

    Name your target standard, known limitations, feedback path, and update cadence. We have one at /accessibility for reference.

  • Schedule scans on a recurring cadence

    Weekly or monthly full-site scans catch regressions before anyone complains.

  • Archive scan evidence — do not overwrite

    Immutable history is the record auditors and regulators actually want.

  • Define a remediation SLA per severity

    Critical within 7 days, serious within 30, and so on. Put it in writing; measure against it.

  • Brief legal counsel on the evidence you keep

    Your lawyer should know where the scan reports live and what they can prove.

TrustScans is not a law firm. This checklist is a plain-language starting point — consult counsel for jurisdiction-specific advice. For the regulation your site is held to, see the coverage library.

Start

See what’s on your site.

No credit card. No seat limits during beta. Enter your website address and get every WCAG violation across every page — graded, tagged, and ready to hand to whoever needs it.