Free resource

SMB Website ADA Compliance Checklist

Twenty-five items grouped into five categories. Plain English. Use it as a print-and-hand-to-developer document, a monthly QA gate, or a pre-launch sign-off. No email required, no signup, no wall.

1. Navigation & Keyboard

Keyboard-only navigation works end to end.

Unplug the mouse. Use only Tab, Shift-Tab, Enter, and Escape. Confirm you can reach and activate every primary CTA, the main nav, the footer, and the contact form.

Focus indicator is always visible.

When you Tab to an element, a clear outline or highlight appears. Browser default is acceptable. Removing focus styles with outline:none without a replacement is not.

Skip-to-content link is the first Tab target.

Let keyboard and screen reader users bypass the nav on every page. <a href="#main-content" class="skip-link">Skip to main content</a> at the top of <body>.

No keyboard traps.

Tab in. Tab out. No modal, carousel, or widget should lock focus until an explicit dismissal. Test every interactive component.

Logical tab order.

Tab order should follow the visual order of the page. Floating CTAs and off-canvas menus often break this. Fix with DOM order or tabindex only as a last resort.

2. Content & Imagery

Every meaningful image has descriptive alt text.

Alt text describes what the image conveys, not what it is. A product photo's alt is the product name and any relevant detail, not "product image."

Decorative images have empty alt (alt="").

Spacer images, background icons, and pure decoration should not be announced to screen readers. Empty alt marks them invisible to assistive tech.

One H1 per page, matching the page's topic.

The H1 is what a screen reader user hears as the page's main heading. Do not use H1 for branding or decoration.

Heading hierarchy is sequential (no skips).

H1 then H2 then H3. Skipping from H1 to H3 breaks the outline screen readers rely on for navigation.

Link text makes sense out of context.

"Learn more" and "Click here" fail. Use text that describes the destination: "Read the 2026 compliance update."

3. Color & Contrast

Body text meets 4.5:1 contrast against its background.

Use a contrast checker (WebAIM is the standard). Below 4.5:1 for normal text fails WCAG 2.1 AA.

Large text (18pt+ or 14pt+ bold) meets 3:1 contrast.

Relaxed threshold for visibly larger text. Still not a blank check for low-contrast hero copy.

Links in body text are distinguishable without relying on color.

Underline or a non-color indicator. Color-blind users cannot tell a blue link from black body text.

Color is never the only way information is conveyed.

Error states need icons or text, not just red. Required fields need a label or asterisk, not just a color swap.

Focus and hover states also meet 3:1 against the adjacent color.

A focus ring that only shows 2:1 against the background is effectively invisible to low-vision users.

4. Forms & Inputs

Every form field has a visible, associated <label>.

Placeholder text is not a label. A label tied to the input with for and id is the minimum.

Required fields are marked with text, not just color.

Add the word "required" or a visible asterisk plus aria-required="true".

Error messages are announced and specific.

"Email address is missing" beats "Please fix the errors below." Attach errors to fields with aria-describedby.

Interactive targets are at least 44x44 CSS pixels.

Tiny buttons, checkboxes, and social icons fail WCAG 2.5.8. Easy fix: min-width: 44px; min-height: 44px;.

Viewport meta tag does not disable zoom.

Remove maximum-scale=1 and user-scalable=no. Low-vision users need to zoom.

5. Structure & Third-Party

HTML lang attribute is set on <html>.

<html lang="en">. Screen readers use this to pick the right pronunciation engine.

Semantic landmarks are used.

<header>, <nav>, <main>, <footer>. Screen reader users jump between them.

Embedded iframes have descriptive title attributes.

YouTube embeds, maps, and payment widgets need a title describing what they are.

Third-party widget issues are tracked and escalated.

Chat widgets, review carousels, and social embeds often carry their own accessibility failures. Document them and raise with the vendor. Do not try to patch vendor markup.

Accessibility is re-checked after every template or theme change.

A theme update can introduce a regression across every page. Put a quick keyboard + contrast spot-check into the launch checklist.

Want this checked on your actual site?

A free scan returns a homepage snapshot in 60 seconds. The $49 report covers up to 25 pages with before/after code fixes, per-page fix notes, and pre-written vendor emails.

Run Free Scan View Sample Report →

This checklist is provided for educational and operational use. It is not legal advice or a compliance certification. Automated and manual checklists together catch most accessibility issues, but some requirements can only be verified by manual testing with assistive technologies.