ADA Compliance Training for Web Teams

Training teaches your team what to build. Automated scanning proves they did. Get both: free WCAG 2.1 curriculum below, plus a scanner that verifies every deploy.

How it works

1
Train the people who build

Developers, designers, and content authors each need role-specific WCAG 2.1 Level AA training. The curriculum below covers the essentials for each.

2
Scan every deploy

Trained teams still ship regressions. Automated scans of staging and production catch the violations plaintiff firms target, before they go live.

3
Close the loop with audits

Quarterly automated baselines and annual manual audits surface what training and automation miss. Use findings as teaching cases for the team.

See which training gaps are showing up in production. Free, no signup.

Why training matters more now than ever

3,948 ADA web accessibility lawsuits were filed in federal court in 2025, up 24% from the year before. Most of them cite the same handful of violations: missing alt text, unlabeled form inputs, low color contrast, keyboard traps, missing page titles, and broken heading hierarchy. Every one of those issues is introduced by a person building something, usually without realizing there's a rule about it. Training is how you stop introducing them.

On April 20, 2026 the DOJ extended the ADA Title II web compliance deadline by one year for state and local governments (to April 26, 2027 for larger entities, April 26, 2028 for smaller ones). That extension doesn't apply to private businesses under Title III, and it doesn't change the WCAG 2.1 Level AA target. If anything, it reinforces the target: the same standard applies to both tracks, and your team needs to know how to hit it. Full deadline breakdown here.

Role-based training: what each team needs

Developers

Semantic HTML first. Native buttons, native links, native form controls. Native elements get keyboard support, focus management, screen reader announcements, and assistive technology integration for free. Start there.

ARIA when no native element fits. The first rule of ARIA is "don't use ARIA." Second rule: when you must, use the most specific role and the correct set of state attributes. Know aria-label, aria-labelledby, aria-describedby, aria-expanded, aria-current, aria-live. Learn when each is appropriate.

Focus management. Interactive elements must be reachable by Tab and Shift+Tab, focus order must match visual order, and focus must be visible. Modals trap focus inside the modal; closing returns focus to the trigger. Route changes in SPAs should move focus to the new main content.

Forms. Every input has a <label> associated by for or wrapping. Error messages are announced and linked to the field via aria-describedby. Required fields are indicated in an accessible way, not just by color.

Custom components. If you must build a custom tab panel, dropdown, combobox, or dialog, follow the WAI-ARIA Authoring Practices patterns exactly. Most "simple" custom components fail accessibility because they miss one of the dozen small rules.

Designers

Color contrast. Text needs 4.5:1 against its background at normal size, 3:1 at large size. Interactive elements and meaningful graphics need 3:1. Run every design through a contrast checker before handoff.

Focus states. Every interactive element needs a visible focus style that meets 3:1 contrast against its surroundings. Default browser outlines are legal. Custom focus styles are nicer. Removing focus entirely is a violation.

Don't rely on color alone. Error states, required fields, and status indicators all need a non-color cue (icon, text label, or pattern).

Font sizes and spacing. 16px is a reasonable minimum for body text. Line height should be at least 1.5 for body copy. Users should be able to zoom to 200% without content clipping or becoming unusable.

Touch targets. Interactive elements should be at least 44x44 CSS pixels, with adequate spacing between adjacent targets. Small targets fail WCAG 2.5.5 (Target Size) in WCAG 2.2.

Content authors and marketers

Alt text on images. Describe the meaning of the image in context. If the image is decorative and adds no information, use empty alt (alt=""). If the image is a link, the alt text describes where the link goes.

Heading structure. One H1 per page. H2s for major sections. H3s for subsections within an H2. Don't skip levels. Don't use headings for visual styling.

Link text. Meaningful on its own. "Click here," "read more," and "learn more" fail when a screen reader user lists the links on a page. Prefer "read our 2025 accessibility report" over "click here."

Video and audio. Videos need captions. Audio content needs transcripts. Pre-recorded video with dialog or narration needs both captions and a transcript (or an audio description track).

PDFs. If possible, publish content as HTML instead of PDF. If PDF is required, it must be a tagged PDF with reading order, alt text, and form field labels. Scanned PDFs are not accessible.

Product managers and designers working on flows

Test every critical path with keyboard only. Can you sign up? Sign in? Reset a password? Complete a purchase? Submit a form? If any step fails, it's a blocker for some users.

Review error states. What happens when a user submits an empty form? Are errors announced? Are they linked to the fields? Can a screen reader user find them?

Watch for timed interactions. Session timeouts, carousel auto-play, and CAPTCHA all create accessibility issues if not done carefully. Users must be able to extend time, pause motion, and complete challenges without requiring specific sensory abilities.

Free training resources that don't waste time

  • W3C Web Accessibility Tutorials. The official guidance from the group that writes WCAG. Structured, practical, covers images, forms, tables, carousels, menus, and more.
  • MDN Web Docs Accessibility. Developer-focused reference on HTML semantics, ARIA, keyboard accessibility, and testing. Pairs well with the tutorials.
  • A11ycasts on YouTube (Rob Dodson). Short video lessons on specific accessibility patterns. Older but still accurate on fundamentals.
  • Deque University. Paid but high quality. Free trial covers the basics. Strong for enterprise developers who need certification-track material.
  • WAI-ARIA Authoring Practices Guide (APG). If you build custom components, this is the reference. Patterns for dialogs, tabs, combobox, tree view, and more.
  • Inclusive Components (Heydon Pickering). Book and blog. Deep treatments of accessible component design with reasoning, not just rules.

Formal certifications worth considering

IAAP CPACC (Certified Professional in Accessibility Core Competencies). Foundational, role-agnostic. Good for product managers, designers, and generalists. About $450 per exam.

IAAP WAS (Web Accessibility Specialist). Technical. Good for developers and QA. Requires the CPACC as a co-requisite. About $490 per exam.

IAAP CPABE (Accessible Built Environment Specialist). Physical accessibility rather than digital. Usually not relevant for web teams.

DHS Trusted Tester. Free certification from the US Department of Homeland Security on the Trusted Tester Process for Section 508 testing. Practical and free, but narrower scope than IAAP.

Training is necessary, not sufficient

Every accessibility professional has the same story. A company invests in training, the team gets enthusiastic, they fix a bunch of things, and six months later the next audit finds 80% of the original violations back. Not because training didn't work. Because there was no ongoing verification.

The pattern that actually holds up over time is training plus automated testing plus manual audits. Training establishes the baseline understanding. Automated testing in CI and pre-deploy catches the 30 to 40% of WCAG violations that are machine-detectable (the same ones plaintiff firms cite most often in demand letters). Manual audits quarterly or annually catch what automation can't see: confusing screen reader output, illogical focus order, inaccessible custom widgets, cognitive load issues.

Remove any one of the three and gaps open up. Training alone goes stale within a year. Automation alone catches what automation can catch, which isn't everything. Manual audits alone are expensive and point-in-time. Together they form a working program.

See what your trained (or untrained) team is actually shipping. Run a free WCAG 2.1 Level AA scan and start closing the gap between what's taught and what's in production.

Run Free Scan

Frequently asked questions

What is ADA compliance training?

Training that teaches employees how to identify and avoid accessibility barriers in the products, content, and services they create. Role-specific is better than generic: developers learn semantic HTML and ARIA; designers learn color contrast and focus states; content authors learn alt text, heading structure, and link text.

Who on my team needs ADA compliance training?

Anyone who touches the public-facing website or app. Developers, designers, PMs, content writers, marketers, customer support, and executives who evaluate third-party tools. Every team plays some role in accessibility, and training should be calibrated to what each team actually does.

How much does ADA compliance training cost?

Self-paced online: free to about $500 per seat. Live workshops: $1,500 to $5,000 per day. IAAP certifications: $450 to $645 per exam plus prep. Enterprise programs with ongoing coaching and audits: $25,000 to $150,000 per year. The W3C WAI tutorials and MDN accessibility docs are free and cover most of what a working web team needs.

Is ADA compliance training legally required?

The ADA doesn't explicitly mandate it, but training is strong evidence of good faith compliance effort and is commonly required by lawsuit settlements. Title II (post-April 2024) and Section 508 effectively require it through their broader compliance program language. In regulated industries (healthcare, government, education), state and federal rules often imply training obligations.

How often should we retrain?

Onboarding for every new hire who touches the site, annual refreshers for the team, and targeted updates when WCAG changes (like 2.2) or when new tools or design systems are adopted. Use accessibility incidents (a demand letter, customer complaint, or failed audit) as teaching cases.

Can training alone make us compliant?

No. Even well-trained teams ship regressions under deadline pressure, when third-party components are added, and when content authors upload media. Training plus automated scanning in CI plus periodic manual audits is the combination that actually holds compliance over time.