WCAG 2.1 AA covers about 50 success criteria across perceivable, operable, understandable, and robust principles. Roughly 30–40% are testable mechanically; the rest require human review. This post is a practical checklist organized by what actually matters on a law firm site.

The high-priority subset (cited most in demand letters)

These are the criteria plaintiff firms most consistently include in ADA Title III demand letters against firm websites. Cover these first.

1.1.1 Non-text Content (Level A)

Every image, icon, and graphic must have a text alternative. For practice-area imagery, attorney headshots, and decorative graphics: add alt attributes. Decorative images get alt="". Substantive imagery (charts, infographics) needs descriptive alt text.

Test mechanically: yes. Test on your site: search for <img without alt= in your CMS templates.

1.4.3 Contrast (Minimum) (Level AA)

Text against its background must have a contrast ratio of at least 4.5:1 (3:1 for large text). Light gray text on white backgrounds is the most common failure on attorney sites.

Test mechanically: yes.

2.1.1 Keyboard (Level A)

All functionality must be operable with a keyboard alone. The most common failures: dropdown menus that only open on hover, custom modal dialogs that trap focus or fail to focus, and "click anywhere outside to close" patterns that have no keyboard equivalent.

Test mechanically: partially. Most automated scanners detect static keyboard issues but miss dynamic-state failures.

2.4.7 Focus Visible (Level AA)

There must be a visible indicator of which element has keyboard focus. Many designer-built law firm sites explicitly remove the default focus outline (outline: none) without providing a replacement. This is a near-universal failure.

Test mechanically: yes.

3.3.2 Labels or Instructions (Level A)

Every form field that requires input must have a label or accessible instruction. Contact forms and intake forms are the most-cited surface. Placeholder-only labels (where the label disappears as the user types) fail this criterion.

Test mechanically: yes.

4.1.2 Name, Role, Value (Level A)

Every interactive element must have a programmatically determinable name, role, and value. Custom dropdown menus, "tab" widgets, and accordion FAQs built without ARIA frequently fail this.

Test mechanically: partially.

The forms-specific checklist

Contact forms and intake forms are the highest-stakes accessibility surface on a firm site.

  • [ ] Every input has an associated <label> (not just a placeholder)
  • [ ] Required fields are marked with text, not just color
  • [ ] Error messages are programmatically associated with the field
  • [ ] Error states announce to screen readers (use aria-live or aria-describedby)
  • [ ] Submit button is keyboard-operable
  • [ ] Captcha (if present) has accessible alternative

The PDF checklist

PDFs of attorney bios, retainer templates, intake forms, and practice descriptions are universally failure points on firm sites.

  • [ ] PDF has tagged structure (Acrobat → Tools → Accessibility → Make Accessible)
  • [ ] Every image in the PDF has alt text
  • [ ] Reading order is logical (Tags Panel)
  • [ ] Form fields (if interactive) are labeled
  • [ ] Document language is set
  • [ ] Title is set (not just filename)

The honest answer: most law firms have dozens of PDFs that fail several of these. Either remediate them, replace with HTML, or remove them entirely from the site.

What requires human review (don't trust the scanner)

These criteria need a person to evaluate. An automated scanner cannot definitively pass or fail them.

  • 1.1.1 alt text quality: a scanner sees that alt text exists; it can't evaluate whether the alt text actually describes the image meaningfully.
  • 1.3.1 info and relationships: structural markup is partially testable but conveying complex relationships (tables of practice areas, attorney directories) requires judgment.
  • 2.4.6 headings and labels: heading hierarchy is testable; whether the heading actually describes the content is not.
  • 3.1.5 reading level: can be estimated mechanically but assessing whether content is appropriate for the audience requires human review.

Setting up continuous monitoring

The point of automated scanning is not to replace human review but to catch the regressions a human review can't keep up with. Marketing teams update content; designers tweak templates; CMSs auto-add elements. Without continuous scanning, accessibility decays measurably between human audits.

SEO Score API's law-firm vertical runs continuous WCAG 2.1 AA scanning plus SEO and Core Web Vitals checks across your firm's full site. Try a free single-page scan on the page.

How often should we run scans?

Weekly for the homepage and top 3-5 practice-area pages. Monthly for the full site. After every CMS template change, run a fresh full-site scan within 72 hours.

Do we need to fix every issue our scan finds?

In an ideal world, yes. In practice, prioritize: Level A failures first, Level AA failures second, the high-priority subset above before anything else. Document what you've fixed and when; that audit trail is itself protective.

What if our CMS makes some fixes hard?

This is common with older WordPress builds and most law-firm-specific CMS products (Justia, FindLaw, LawLytics). Two options: pressure the vendor to remediate the template, or migrate. Most firms find that template-level remediation through the vendor takes 6–18 months; CMS migration takes 3–6. Neither is fast.

Want a continuous scan of your firm's site? Free single-page scan on the law-firms page →