ADA and your website: how to make your site more accessible, step by step

To make your website more accessible, test it the way people with disabilities use it: with only a keyboard, with a screen reader and at high zoom. Then run a free automated scan, fix contrast, alt text, headings, forms and media, and publish an accessibility statement with a way to reach you. The target is WCAG 2.2 Level AA. This is general information, not legal advice.

For the background on what the ADA and WCAG require, read our overview, website accessibility for business owners. This post is the hands-on companion.

Where the ADA stands right now

Private businesses (Title III). There is still no federal technical rule for business websites. Courts have generally treated websites as covered, and WCAG is the yardstick that plaintiffs, settlements and the DOJ point to. Seyfarth Shaw counted 3,117 federal website accessibility suits in 2025, up 27% from 2024, with New York, Florida and Illinois leading. UsableNet, which also counts some state court cases, tracked 5,114 digital accessibility suits in 2025. It found 64% targeted companies with under $25 million in revenue and 70% involved ecommerce. Many more claims start as a demand letter and settle before any suit.

State and local governments (Title II). In April 2024 the DOJ issued a rule requiring their websites and mobile apps to meet WCAG 2.1 Level AA. On April 20, 2026, an interim final rule pushed the compliance dates back one year:

The DOJ said it may propose changes to the rule during the extension.

The afternoon audit, step by step

Pick your five most important pages, including anything with a form, booking or checkout, and run each step on them.

1. Keyboard-only test

Put the mouse away. Use Tab to move forward, Shift+Tab to go back, Enter to follow links and press buttons, Space for checkboxes and buttons, arrow keys inside menus and radio groups, and Esc to close things.

• Can you see where you are at every step? A clear focus indicator is required. If focus disappears, the site has outline: none somewhere.
• Is the first Tab stop a "Skip to main content" link?
• Do dropdown menus open and close from the keyboard?
• Does a modal move focus inside it, keep focus there, and close with Esc, returning you to the button that opened it?
• Do sticky headers or chat bubbles cover the focused element?

2. Automated scan

Run at least one free tool on each page: WAVE (WebAIM's browser extension), axe DevTools (free extension) or the Lighthouse accessibility audit in Chrome DevTools. They quickly catch missing alt attributes, empty buttons, missing labels and low contrast. Just don't treat a clean score as a pass. Deque's own study of more than 2,000 audits found automated testing covered about 57% of issues by volume. The rest, like focus order and meaningful alt text, needs a person. For scale, the 2026 WebAIM Million found detectable WCAG failures on 95.9% of the top million home pages, with low contrast text on 83.9% of them.

3. Screen reader spot check

Spend 15 minutes with one screen reader:

• VoiceOver on Mac: press Cmd+F5 to turn it on. Control+Option+Right Arrow moves through the page; Control+Option+U opens the rotor of headings and links.
• VoiceOver on iPhone: Settings, Accessibility, VoiceOver. Swipe right to move, double tap to activate.
• NVDA on Windows: free from nvaccess.org. Press H to jump between headings, Tab for controls, and Insert+F7 for a list of links and headings.
• TalkBack on Android: Settings, Accessibility, TalkBack. Swipe right to move, double tap to activate.

Listen for buttons announced only as "button," images read as file names, form fields with no name, and menus that don't say whether they are expanded.

4. Color contrast

Color contrast rules under WCAG AA:

• 4.5:1 for normal text.
• 3:1 for large text (about 24px regular or 19px bold and up).
• 3:1 for UI components and meaningful graphics, like input borders, icons and focus rings.

Color should never be the only signal, so a required field shown only in red fails. Test any dark theme too; see dark mode website design.

5. Images and alt text

Every image needs an alt attribute, but not every image needs a description.

• Informative images: describe what matters in context, in a short sentence. Good alt text for a team photo might be "Our four technicians in front of the service van."
• Decorative images: use empty alt (alt="") so screen readers skip them.
• Logos: use the company name, such as "Acme Plumbing home" on a home link.
• Text in images: avoid it, or repeat the text on the page.

6. Headings, links, language and titles

• One h1 per page, then h2 and h3 in order. Don't pick headings for their size.
• Link text should make sense alone. "View pricing" beats "click here."
• The <html> tag needs a lang attribute, such as lang="en".
• Each page needs a unique, descriptive <title>.

7. Forms

• Every field has a visible label tied to it, not just placeholder text.
• Errors say what went wrong and how to fix it, appear in text next to the field, and are announced to screen readers.
• Use autocomplete values (name, email, tel, street-address) so browsers and password managers can fill fields.
• Avoid puzzle CAPTCHAs. Our guide to how CAPTCHA works covers lower friction options.

8. Video, audio and motion

• Video needs accurate captions; auto captions are only a start.
• Offer a transcript for podcasts and audio.
• Nothing should autoplay with sound. Moving content that lasts more than five seconds needs a pause button.
• Respect the reduced motion setting with the prefers-reduced-motion media query. Parallax and big scroll effects are the usual offenders; see CSS view transitions and scroll animations.

9. Zoom, reflow, mobile and target size

• Zoom the browser to 400% on a desktop window. Content should reflow into one column without sideways scrolling or hidden text.
• Zoom text to 200% and check nothing overlaps.
• WCAG 2.2 criterion 2.5.8 sets a minimum target size of 24 by 24 CSS pixels, or enough spacing around smaller targets.

10. PDFs and third-party widgets

Convert key PDFs (menus, price sheets, forms) to HTML, or make sure they are tagged with real headings. Then test embedded chat, booking, map and payment widgets. You still own what you ship, so ask vendors for accessibility documentation and add text alternatives, like an address next to a map.

Quick checklist

Platform quick fixes

• WordPress: Pick a theme tagged "accessibility ready," fill alt text in the media library, and keyboard test page builder sections.
• Shopify: Add product image alt text, keyboard test menus and filters, and check every app widget.
• Squarespace: Add alt text in image blocks and avoid text over busy photos.
• Wix: Run the built-in accessibility checker and review added apps.
• Webflow: Use the audit panel and keyboard test custom interactions.

Prompt for AI built and vibe coded sites

If your site came from Lovable, Bolt, v0, Replit, Cursor or Claude Code, an AI agent can do much of the work. Paste this in. (See also vibe coding a business website and securing a DIY AI built website.)

Audit and fix this codebase against WCAG 2.2 Level AA. Work through every page, layout and shared component. Make these changes:

1. Use semantic HTML landmarks: header, nav, main, footer, and section/aside where they fit.
2. Ensure exactly one h1 per page and a logical heading order with no skipped levels.
3. Give every img an alt attribute. Use alt="" for decorative images. Flag informative images where you are unsure of the right wording.
4. Give every form input a visible, programmatically linked label. Show error messages in text and link them to the field with aria-describedby; set aria-invalid on errors.
5. Add clear visible focus styles for all interactive elements. Never remove outlines without a replacement.
6. Add a "Skip to main content" link as the first focusable element.
7. Make menus, dropdowns and modals fully keyboard operable: open/close with Enter and Space, close with Esc, trap focus inside open modals, and return focus to the trigger when closed.
8. Replace any div or span used as a button or link with a real button or a element.
9. Check color tokens for contrast: 4.5:1 for normal text, 3:1 for large text and UI components. Adjust tokens rather than one-off colors.
10. Set the lang attribute on the html element.
11. Wrap animations, parallax and autoplaying motion in a prefers-reduced-motion check.
12. Make interactive targets at least 24x24 CSS pixels or give them enough spacing.
13. Use ARIA only where native HTML cannot do the job, and make sure any ARIA states (aria-expanded, aria-current) update correctly.

When done, give me: a list of every change by file, and a separate list of anything needing human judgment, such as alt text wording, video captions, link text and content structure.

Then add a safety net so new code doesn't undo the work:

Add automated accessibility checks to this project: install and configure eslint-plugin-jsx-a11y, and add Playwright tests with @axe-core/playwright that load each main route and fail on any WCAG 2.2 A or AA violation. Add a script to run them and explain how to run them before each deploy.

Review the diff. AI tools sometimes add ARIA that makes things worse.

Publish an accessibility statement

Add a footer-linked page stating your target (WCAG 2.2 AA), known gaps, and how to reach you by email and phone. Say how fast you will respond, then do it. The W3C has a free statement generator.

Keep it accessible

Sites drift. A plugin update or new widget can break what you fixed. Give content editors a short checklist: alt text, real headings, descriptive links, captions and no text in images. Rerun the keyboard test and an automated scan after redesigns, theme or plugin updates and new widgets, and do the full afternoon audit at least once a year. Good accessibility is also just good design, a theme we come back to in the art of UX and UI design.

If you want a second set of eyes, request a free website audit or get in touch.

Sources

• Federal Register: Extension of compliance dates for the ADA Title II web and mobile app rule (April 20, 2026)
• Seyfarth ADA Title III blog: Federal court website accessibility lawsuit filings bounce back in 2025
• UsableNet: 2025 year-end digital accessibility lawsuit report
• Deque: Automated testing study identifies 57 percent of digital accessibility issues
• Nexer Digital: The WebAIM Million report 2026, what it tells us
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C: Understanding success criterion 2.5.8, Target Size (Minimum)
• W3C: Understanding success criterion 1.4.10, Reflow
• W3C WAI: Accessibility statement generator