Accessibility

This page covers what the platform does automatically to support visitors using assistive technology, what site administrators need to do at the content level, and how to publish an accessibility statement that meets the bar courts have credited as good-faith remediation.

No site is automatically "ADA compliant." The Americans with Disabilities Act applies to public accommodations, and the de-facto standard cited in DOJ guidance and most settlements is WCAG 2.1 Level AA. Conformance is a process, not a product. The items below are necessary baseline work — they are not a guarantee against legal action, but they are what plaintiffs' attorneys and the DOJ actually look at.

What the platform handles for you

These items are baked into the codebase — no admin action required:

  • Semantic HTML — heading hierarchy (H1–H6) and landmark elements (<main>, <header>, <footer>, <nav>) are used consistently throughout pages and the CMS-rendered output.
  • Skip-to-content link — keyboard users can press Tab once on any page to skip past the header navigation directly to the page content.
  • Reduce-motion support — animations and transitions automatically shorten when the visitor's OS preference is set to "Reduce motion" (Windows Settings > Accessibility > Visual Effects, macOS System Settings > Accessibility > Display > Reduce Motion). Honors WCAG 2.3.3.
  • Keyboard-visible focus indicators — all buttons, form fields, and links show a visible focus ring when navigated by keyboard.
  • Modal accessibility — dialogs trap focus, restore focus on close, support Escape to close, and announce themselves to screen readers via role="dialog" and aria-modal.
  • Form labels — every form field rendered through DataManager and the auth flows has a programmatic <label> association.
  • Configurable text scaling — the viewport allows up to 5x zoom, so visitors can use the browser's built-in zoom (Ctrl/Cmd +/-) without breaking layout.

What you need to do as an admin

The platform handles the structural work. Content choices are yours:

ItemWhy it mattersWhere
Always fill in image alt-textScreen readers announce the alt-text. Without it, a visually impaired visitor hears "image" or the filename.Every file upload field has an Alt-text input. Use it.
Use heading levels in rich-textScreen readers let users jump heading-to-heading. Bold-as-heading breaks that.Articles, pages, product descriptions — use the H2/H3/H4 dropdown in the editor toolbar.
Descriptive link textScreen readers can list all links. "Click here" tells the user nothing.Write "Read our refund policy" instead of "Click here for our refund policy."
Color contrast on theme choicesBody text needs at least 4.5:1 contrast with its background (WCAG AA). Large text needs 3:1.Site Config > Theme > Colors. Verify pairs at webaim.org/resources/contrastchecker.
Caption / transcribe video and audioRequired for deaf and hard-of-hearing visitors (WCAG 1.2.2).Upload captions with the media, or include a transcript in the page body.
Don't rely on color aloneColor-blind visitors can't distinguish red-error from green-success on color alone (WCAG 1.4.1).Pair color cues with icons, text, or shape — the platform's built-in form errors already do this.

Publish an accessibility statement

A published statement with a working contact is the single most-cited factor in courts dismissing or narrowing ADA web claims. Cases like Robles v. Domino's and Gil v. Winn-Dixie turned on whether the defendant had a documented remediation process. Yours should:

  • State what conformance level you target (WCAG 2.1 AA is the standard).
  • Acknowledge that conformance is ongoing and not perfect.
  • Provide a contact email and a stated response time.

How to review and customize it

A draft accessibility statement is seeded automatically alongside the Privacy Policy and Terms & Conditions, in the legal category at slug accessibility. It uses your site's configured support email (Site Config > Email) and the site name. Before going live publicly, review and tailor it.

  1. Go to Admin > Manager > Pages.
  2. Open the Accessibility page (slug accessibility).
  3. Verify the support email rendered in the body matches the address you actually monitor for accessibility reports. If you change the Site Config support email later, update this page's body too — page bodies are not auto-resynced from Site Config.
  4. Save the page after any review or edit. The page's Last updated timestamp auto-refreshes — that's your dated review record.
  5. The page is reachable at /accessibility and appears in the Footer's legal pages list automatically.
Set a calendar reminder to review and re-save this page at least once per year, and any time you ship a significant new feature, redesign, or third-party embed. The auto-tracked Last updated timestamp is what proves an ongoing remediation process — courts have credited that pattern in dismissals.

Pre-launch audit checklist

Run this before promoting a deployment to a public production URL. ~30 minutes total.

  1. Lighthouse Accessibility — open Chrome DevTools > Lighthouse, run the Accessibility audit on the home page, a product page, the cart, the checkout, an article page, and the sign-in page. Target a score of ≥95 per page. Lighthouse catches automated-detectable issues — about 40% of total issues — but the ones it does catch are usually quick wins.
  2. axe DevTools — install the free Chrome extension (Deque). Run on the same six pages. Confirm zero critical or serious violations. axe catches more than Lighthouse.
  3. Keyboard-only nav — unplug your mouse. Tab through the home page, add a product to cart, complete checkout, sign in, and submit a contact form. Every interactive element must be reachable, the focus ring must be visible at every step, and Enter/Space must activate buttons and links.
  4. Screen reader spot-check — Windows: Narrator (Ctrl + Win + Enter). macOS: VoiceOver (Cmd + F5). Listen through home, a product page, and the cart. Listen for unannounced controls, missing labels, or unexpected reading order.
  5. Color contrast — verify the configured theme's body-text-on-background pair at webaim.org/resources/contrastchecker. Both light and dark mode if both are enabled.
  6. Reduce-motion — Chrome DevTools > Rendering > Emulate CSS media feature prefers-reduced-motion: reduce. Confirm hover animations and transitions stop firing.
  7. 200% zoom — press Ctrl/Cmd + until the page is at 200%. Layout should remain usable; no critical content should be clipped or unreadable. WCAG 1.4.4.

Document anything you couldn't immediately resolve in the issue tracker so you have a written remediation log if a question is ever raised.

Why we don't ship an "accessibility button" overlay

Third-party widgets like AccessiBe, UserWay, and EqualWeb add a floating accessibility button that opens a panel of toggles (font size, contrast, dyslexia font, etc.). They market themselves as a one-click path to ADA compliance. The platform intentionally does not include one, and we recommend not adding one via Site Config > Code Inject either.

Overlays do not reduce ADA-lawsuit risk and may increase it. AccessiBe itself has been the defendant in class-action suits (Murphy v. Eyebobs, Martinez v. AccessiBe). UsableNet's annual ADA Web Lawsuit reports consistently show overlay-equipped sites are sued at the same or higher rate. Plaintiffs' attorneys publicly note that an overlay is now treated as an indicator the underlying site is broken for assistive tech.

The reasons:

  • Overlays don't fix the underlying HTML. Screen readers parse the DOM directly; an overlay's font-size slider doesn't add missing alt-text or landmark elements.
  • Browsers and operating systems already do most of what overlays offer, better. Ctrl/Cmd +/- scales the entire page (better than a per-site slider). OS-level high-contrast modes (Windows High Contrast, macOS Increase Contrast) are global. Browser extensions for dyslexia-friendly fonts are site-agnostic.
  • Some overlays interfere with assistive tech. Overlays that inject ARIA they don't understand have been documented to break screen reader output that was working correctly without the overlay.
  • Real conformance is structural. The line items in the audit checklist above — keyboard nav, alt-text, contrast, headings, labels — are what actually move the needle. None of those are something a button overlay can address.

If a specific feature would genuinely help your visitors (e.g. a font scale toggle for an older audience), it can be built natively into the theme without claiming compliance. Talk to your developer about scoping it as a real feature rather than dropping in a third-party widget.

References

  • WCAG 2.1 — w3.org/TR/WCAG21
  • DOJ Title III ADA web guidance — ada.gov/resources/web-guidance
  • WebAIM contrast checker — webaim.org/resources/contrastchecker
  • axe DevTools (Chrome extension) — Deque Systems
  • The A11y Project — a11yproject.com — practical patterns and checklists