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.
Primary WCAG references
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.
Primary WCAG references
- 1.4.3AAContrast (Minimum)
- 1.4.1AUse of Color
- 2.4.7AAFocus Visible
- 2.3.3AAAAnimation from Interactions
- 2.5.8AATarget Size (Minimum)
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.
Primary WCAG references
- 1.3.1AInfo and Relationships
- 2.4.6AAHeadings and Labels
- 1.1.1ANon-text Content
- 3.3.2ALabels or Instructions
- 2.4.4ALink Purpose (In Context)
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
- 2.1.1AKeyboard
- 2.1.2ANo Keyboard Trap
- 2.4.3AFocus Order
- 2.4.1ABypass Blocks
- 4.1.3AAStatus Messages
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.
Primary WCAG references
- WCAG 2.2AAQuick Reference (How to Meet WCAG)
- WAIAAPlanning Accessibility
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.