In 2025, plaintiffs filed 3,117 federal website accessibility lawsuits, a 27% increase from 2,452 in 2024, and website cases represented 36% of all 8,667 federal ADA Title III filings. The figures, reported by Half Accessible’s 2026 website accessibility litigation analysis, change the question for business owners. “How to make a website ADA compliant” isn’t a cosmetic redesign project. It’s an ongoing process of removing barriers from the pages, forms, menus, checkout flows, and content systems customers use.
A practical program combines WCAG-based design and development, automated scanning, keyboard testing, screen-reader review, template-level fixes, and continuous governance. Accessibility also improves everyday usability. Clear headings help people scan, descriptive links reduce confusion, labeled forms make submissions easier, and readable contrast supports visitors using a range of devices and conditions.
Table of Contents
- Understanding the Legal and Technical Baseline
- Auditing Your Current Website Accessibility
- Remediating the Most Common Design and Code Failures
- Securing High-Friction User Journeys and Forms
- Scaling Fixes Through Template-Based Remediation
- Establishing Ongoing Accessibility Governance
Understanding the Legal and Technical Baseline
The ADA is a civil rights law, not a website checklist. The law addresses discrimination, while WCAG provides the technical language teams use to evaluate whether digital content can be perceived, operated, understood, and interpreted by assistive technology. The Department of Justice has long interpreted the ADA as applying to websites operated by covered entities, with the DOJ’s rule text noting that it first articulated that interpretation in 1996. The same historical timeline records WCAG 1.0 in 1999, WCAG 2.0 in December 2008, WCAG 2.0 as an ISO/IEC international standard in October 2012, and WCAG 2.1 in June 2018. These milestones are summarized in Abledly’s ADA lawsuit statistics overview.
For a private business or nonprofit, the practical question isn’t whether a page carries an “ADA compliant” badge. The question is whether people with disabilities can use the website’s services on comparable terms. That means reaching navigation with a keyboard, understanding image content through appropriate alternative text, completing forms, recovering from errors, and operating interactive elements without relying on a mouse or visual cues alone.
Which standard should guide the work
The DOJ’s Title II web rule applies specifically to state and local governments. It was published in the Federal Register on April 24, 2024, became effective on June 24, 2024, and establishes WCAG 2.1 Level AA as the technical standard for covered public entities’ web content and mobile applications, as explained in the Department of Justice rule overview. The rule allows exceptions when conformance would cause a fundamental alteration or undue financial and administrative burdens, but covered entities still need to address WCAG 2.1 Level AA unless an exception applies, according to the DOJ’s final rule PDF.
WCAG 2.2 Level AA is a newer target, not an interchangeable label. It adds 9 new success criteria, and guidance from Accessibility.build’s WCAG 2.2 requirements guide describes Level AA as 55 total requirements, while also explaining the cumulative-count nuance created by the removed parsing criterion.
Practical rule: Treat WCAG 2.1 AA as the legal baseline where it applies, then evaluate WCAG 2.2 AA for a more durable design and development target. Don’t claim a permanent pass when your CMS, plugins, content, and third-party tools can change tomorrow.
Auditing Your Current Website Accessibility
Start with evidence, not assumptions. A polished interface can still contain unlabeled fields, keyboard traps, hidden focus states, or errors that assistive technology never announces. The audit should show which defects repeat across templates and which ones interrupt high-value tasks, especially forms, account access, and checkout.
Phase one uses automation for coverage
Run an automated scanner across representative page types and priority URLs. Tools such as axe DevTools, WAVE, Lighthouse, and browser accessibility inspectors can flag repeated patterns, including missing labels, empty controls, poor contrast, invalid attributes, and structural problems.
Automation is fast and repeatable. It can expose a theme-level defect across hundreds of pages, but it cannot judge whether alt text communicates the image’s purpose, whether focus follows a sensible sequence, or whether a complex widget makes sense to a screen-reader user.
WebAIM’s 2026 Million report found that 95.9% of one million home pages had at least one detectable WCAG 2 failure. That result supports automated testing as a first pass for finding broad patterns. It does not establish that a site is accessible or that a visitor can complete its key tasks.
Phase two tests real interaction
Manual testing should start with core templates and the tasks that matter to the business. Use the site without a mouse. Move with Tab and Shift+Tab, activate controls with Enter or Space, and use arrow keys where the interface requires them. Check that every interactive element has a visible focus state, that focus remains within an open modal until it closes, and that menus, forms, and checkout controls are operable from the keyboard.
Test with NVDA, VoiceOver, or JAWS as well. Listen for page titles, heading order, link and button names, form labels, status messages, and validation errors. Repeat the main tasks on mobile with the platform’s accessibility features, since responsive layouts and touch controls can create barriers that desktop testing misses.
Rank the remediation backlog by user impact:
- Blockers: A visitor cannot submit a form, complete checkout, open navigation, dismiss a modal, or recover from an error.
- Repeated component defects: The same inaccessible header, button, form field, or content module appears across multiple templates.
- Content failures: Images lack meaningful alternatives, headings are out of order, or links use unclear wording.
- Lower-priority exceptions: Isolated issues that do not stop a critical task but belong in routine maintenance.
A scanner export is an input, not a plan. Convert each finding into a record with the affected template, user task, owner, proposed fix, and retest requirement. That workflow turns an audit into a repeatable accessibility process instead of a one-time checklist.
Remediating the Most Common Design and Code Failures
The fastest progress comes from fixing recurring defects at the component and template level. Large-scale accessibility testing consistently identifies six common categories: low-contrast text, missing alternative text, missing form labels, empty links, empty buttons, and missing document language. Treat that pattern as a work queue. Correct shared styles, headers, buttons, and form components before spending time on isolated page-level warnings.
Fix the visual and content foundations
Contrast: Test body text, icons, buttons, placeholders, and focus indicators against their actual backgrounds. Brand colors may work in one context and fail in another. Keep the recognizable palette, then define accessible variants for text, links, controls, and surfaces. Record those choices in the design system so new templates do not recreate the same defect.
Alternative text: Write alt text for the image’s purpose, not every visible detail. A product image may need the product name and a feature that matters to the surrounding content. A decorative flourish should usually have empty alternative text so assistive technology skips it. In WordPress, add meaningful text in the media library and verify that the theme does not replace it with a generic label.
Document language: Set the correct language on the HTML document and check multilingual templates separately. Screen readers use this setting to choose pronunciation rules. An absent or incorrect value can make otherwise readable content difficult to understand.
Repair interactive names and structure
Form labels: Every input needs a programmatic connection to its visible label. Placeholder text disappears during entry and cannot replace a label. In custom code, associate the label and input directly. In WordPress, confirm that the form plugin generates accessible markup rather than placing visual text beside an unlabeled field.
Empty links and buttons: Give each control an accessible name that explains its action. An icon-only search control needs a name such as “Search,” and a close control needs a name such as “Close dialog.” Remove empty anchors from page builders, decorative links, and duplicate controls.
Headings and ARIA: Establish one clear page topic and a logical heading hierarchy. Choose heading elements for structure, not font size. Prefer native HTML controls, adding ARIA only when it supplies missing context or state. Incorrect ARIA can make a straightforward control harder for assistive technology to interpret.
Track each fix by component, template, owner, and retest status. That record turns recurring failures into an operating workflow. It also lets developers verify that a change to one shared component improves every affected page without creating a new barrier elsewhere.
Securing High-Friction User Journeys and Forms
A homepage scan can pass while a customer still can’t request a quote, book an appointment, purchase a product, or contact support. Accessibility failures become most consequential at the exact point where a visitor must take action, which is why forms, checkout paths, overlays, keyboard navigation, heading structure, color contrast, and PDFs frequently appear in legal-trend discussions. ADA Scan Pro’s 2025 litigation analysis connects those interaction-level barriers with the continuing volume of federal website accessibility filings.
Test the task from beginning to end
Take a real journey and document every state, not just the initial page. For a contact form, test field entry, required-field errors, invalid formats, successful submission, confirmation messaging, and the user’s ability to start over. Every error should identify the affected field, explain what needs correction, and remain available to a screen-reader user.
For a multi-step form or checkout, make the current step clear and preserve entered information when validation fails. Programmatically connect instructions to fields, use appropriate input types, and avoid forcing a user to infer requirements from color alone. If a session expires, explain what happened and provide a recovery path.
Control focus and dynamic content
When a modal opens, move focus into it. Keep keyboard focus inside while it’s active, provide a clearly named close control, and return focus to the trigger when the modal closes. Don’t let users tab into hidden content behind an overlay.
Dynamic updates need an accessible announcement strategy. A confirmation message, cart update, filtering result, or inline error should be exposed in a way that assistive technology can detect without requiring the user to hunt through the page. Third-party booking calendars, chat tools, payment widgets, and embedded forms deserve the same testing as first-party code. If a vendor’s widget creates a barrier, document the issue and pursue a fix or replacement instead of assuming the responsibility disappears because someone else wrote the code.
For contact-page planning, review the site’s website contact pages as a user would, then test the actual form implementation across keyboard and screen-reader workflows. The conversion path is the product experience. A technically attractive homepage can’t compensate for an inaccessible submission process.
Scaling Fixes Through Template-Based Remediation
Page-by-page cleanup stops scaling when the same header, form, navigation menu, modal, card, and footer are reused across a site. With dozens of accessibility errors often appearing on a homepage, the pattern points to shared templates rather than isolated pages. The different testing methods behind published audits should not be treated as one benchmark. They do support a practical conclusion: repeated defects require systemic fixes.
Correct the source, not every symptom
Inventory the design system and CMS components first. Identify the templates controlling the header, navigation, footer, buttons, forms, search, dialogs, product cards, post layouts, and reusable content blocks. Then correct the markup, styles, interaction states, and content fields where those components are generated.
A WordPress team might repair a button component once, update a form pattern in the theme or plugin settings, and fix the mobile menu’s focus behavior at its source. A custom development team might update a shared React component, design-system token, or server-rendered partial. Retest representative pages after each shared component changes, because one fix can affect different content types.
Use this workflow:
- Map repetition: Find the templates and modules affecting the largest portion of the site.
- Define expected behavior: Document keyboard interaction, focus visibility, accessible names, semantics, states, and error handling.
- Fix globally: Apply the correction in the theme, component library, CMS, or plugin configuration.
- Test samples: Retest representative pages, including long content, commerce, forms, and mobile layouts.
- Protect the release: Run automated checks before deployment and require manual QA for critical journeys.
A reusable template for faster workflows can standardize repeated remediation. The accessibility template must cover more than visual consistency. Include semantic structure, content guidance, keyboard behavior, and acceptance criteria so each new page inherits usable patterns.
The same review applies when selecting an ecommerce platform or CMS. Assess the best CMS for e-commerce for product filters, variant selectors, carts, checkout fields, account areas, and plugin compatibility. A platform’s feature list does not show whether every extension or custom theme will work with assistive technology.
Build accessibility into the component definition. A button is complete when users can find it, understand it, operate it, and perceive its state.
Establishing Ongoing Accessibility Governance
Accessibility work ends badly when no one owns what happens after launch. Content editors add images, marketers publish landing pages, developers update plugins, and third-party tools change their markup. A site that was carefully remediated can regress without a release and content process that checks for those changes.
Treat accessibility as a recurring quality standard. Assign responsibility for automated monitoring, manual testing, content review, vendor escalation, and remediation tracking. The owner doesn’t need to perform every task, but someone must know which task is due, what evidence exists, and who approves closure.
Build a repeatable operating rhythm
Use automated scans to catch recurring patterns after meaningful releases and content changes. Pair them with manual testing of core journeys, especially after changes to forms, checkout, navigation, popups, search, account areas, and embedded services. Keep a record of the tested URL or template, assistive technology and browser combination, observed issue, assigned owner, fix, and retest result.
Train editors on the failures they can introduce without touching code:
- Headings: Select heading levels for structure, not visual size.
- Links: Use descriptive link text that makes sense out of context.
- Images: Add meaningful alt text, or mark decorative images appropriately.
- Media: Provide captions and accessible supporting content where needed.
- Documents: Review PDFs and downloads before publishing them.
- Color: Don’t communicate status or instructions through color alone.
Choose a durable conformance target
Many organizations still use WCAG 2.1 AA as their immediate benchmark, while considering WCAG 2.2 AA for future-focused improvements. Level Access’ litigation guidance describes this broader shift toward governance, routine testing, and monitoring rather than a one-time remediation event. The practical choice depends on your audience, legal obligations, platform, budget, and ability to maintain the result.
Avoid overlay widgets that promise to make an inaccessible site compliant with a single installation. They may change some presentation or add controls, but they can’t reliably repair flawed source structure, inaccessible third-party workflows, meaningful alt-text decisions, keyboard interaction, or poor content. Use tools as part of a measured program, not as a substitute for design, development, and human QA.
For organizations that need a development partner, Blu Dragonfly’s web development services include custom WordPress website work and accessibility considerations that can be incorporated into discovery, design, development, quality assurance, and ongoing support. A collaborative team can connect accessibility with branding, content, forms, marketing pages, and the technical systems that keep the website running.
The durable definition of compliance is operational: users can complete important tasks, the team can explain how accessibility is tested, and new changes don’t recreate old barriers.
Blu Dragonfly LLC can review your existing website, identify accessibility issues across templates and conversion paths, and plan practical remediation for WordPress or a custom build. Visit Blu Dragonfly LLC to discuss an accessibility-focused website project that also supports your brand, content, marketing, and long-term digital growth.
Want your website checked for accessibility? See our ADA website compliance service.
Want your website checked for accessibility? See our ADA website compliance service.