If you’re asking how to make your website ADA compliant, treat accessibility as a remediation and verification program, not a badge, scanner score, or widget. For a U.S. business, first identify which legal framework applies, then use a current technical standard such as WCAG 2.2 to organize the work, fix barriers in the customer journeys that matter most, and verify the fixes with both automated and knowledgeable manual testing. If you need the legal and standards side in more depth, start with our ADA website compliance guide.
TL;DR: How do you make your website ADA compliant?
- Identify the right rule set first. The Americans with Disabilities Act, Section 508, state and local-government rules, contracts, and other frameworks do not all apply to the same organizations.
- Use WCAG 2.2 as a practical technical target. It gives you testable accessibility criteria, but it is not a magic legal certificate for every private website.
- Fix real user journeys before polishing low-risk pages. Navigation, forms, checkout, booking, account access, search, downloads, and other critical tasks deserve priority.
- Combine automated and manual testing. A clean scanner report can still miss keyboard traps, confusing focus order, bad labels, unusable dialogs, and task failures.
- Assign ownership after remediation. Accessibility can regress when content, plugins, templates, forms, or third-party tools change.
The useful goal is not to make a dashboard turn green. It is to remove barriers that stop people with disabilities from getting information, understanding controls, completing tasks, and communicating with your business.
Start with the right accessibility target
The phrase “ADA compliant website” gets used as if it describes one universal checklist. It does not. The U.S. Department of Justice says Title III applies to businesses open to the public and that inaccessible website features can limit access to the goods, services, and privileges those businesses offer online. DOJ also says it does not provide one detailed technical web standard for Title III and points to standards such as WCAG as helpful technical guidance. See the DOJ Guidance on Web Accessibility and the ADA.
That distinction matters. A private retailer, a local government, a federal contractor, and a business bound by a procurement agreement can face different requirements. This article is a practical remediation guide for business websites, not individualized legal advice. If your question is “Which rule actually applies to us?” resolve that before anyone sells you a compliance guarantee.
For the technical work, WCAG 2.2 is the current W3C Recommendation. W3C advises using WCAG 2.2 for current and future accessibility work. It gives teams a shared vocabulary and testable success criteria across perceivable content, operable interfaces, understandable experiences, and robust implementation.
How to make your website ADA compliant with the CLEAR Remediation Loop
Accessibility audits often produce a miserable spreadsheet with 147 warnings sorted by rule number. Technically organized, practically useless. The business still does not know what to fix first.
We use the CLEAR Remediation Loop to turn accessibility findings into owned work:
- C — Critical journeys: identify the tasks people actually need to complete.
- L — Language and labels: make structure, names, instructions, and errors understandable.
- E — Entry and interaction: make controls usable with keyboard and assistive technology.
- A — Appearance and alternatives: fix contrast, zoom, reflow, images, media, and nonvisual alternatives.
- R — Retest and regression: prove the fixes, record evidence, and stop future changes from quietly breaking them.
CLEAR is a Scope Design workflow, not a replacement for WCAG. Its job is to help a business move from “we found accessibility issues” to “we know which barriers matter, who owns the fixes, and how we will verify them.”
C: Critical journeys — fix the tasks people actually need
Start with the paths where an accessibility failure blocks a meaningful outcome. For one business that may be finding a phone number and submitting a contact form. For another it may be choosing a product, adding it to a cart, paying, and retrieving an order confirmation. A healthcare or education site may have high-value forms and documents. A membership site may live or die on authentication and account management.
Map representative journeys before you sort individual violations. At minimum, test global navigation, search if the site has it, contact or lead forms, primary calls to action, checkout or booking, account login, important downloads, and any third-party widget required to finish the task.
This is also where accessibility and UX meet. A technically valid control can still be confusing, badly ordered, or hard to recover from. Our broader website UX diagnosis framework covers task friction beyond accessibility criteria; use it when the problem is bigger than a WCAG failure.
L: Language and labels — make structure understandable
People should not have to infer what a control, image, field, or section means from visual layout alone. Build meaning into the content and markup.
- Use real headings in a logical hierarchy instead of bold paragraphs pretending to be headings.
- Give links and buttons names that describe the action or destination. “Learn more” can work in context, but six identical “Click here” links are useless when read out of context.
- Give meaningful images useful text alternatives. Decorative images should usually be marked so assistive technology can ignore them rather than hearing a filename.
- Associate visible labels with form controls and explain required formats before a user fails.
- When a form error is detected, identify the field and describe the problem in text. WCAG 2.2 criterion 3.3.1 requires detected input errors to be identified and described to the user.
- Keep instructions, navigation names, and repeated controls consistent across templates.
Good labels are boring in the best possible way. Nobody should need detective skills to figure out whether a magnifying-glass icon opens search, submits a form, or launches a tiny escape room.
E: Entry and interaction — keyboard, focus, forms and controls
A website is not accessible if a person can read the page but cannot operate the interface. WCAG includes keyboard operability because many people cannot or do not use a mouse. Test the real site with Tab, Shift+Tab, Enter, Space, Escape, and arrow keys where the component pattern calls for them.
- Every interactive control needed for a task should be reachable and operable from the keyboard.
- Focus order should follow a sensible reading and task sequence.
- Keyboard focus needs to be visible. WCAG 2.2 criterion 2.4.7 requires a visible focus indicator for keyboard-operable controls.
- Menus, modals, accordions, tabs, carousels, and custom components need expected keyboard behavior and should not trap focus.
- Forms need labels, instructions, usable validation, and errors that can be found and corrected.
- Time limits, moving content, and automatically updating interfaces should not steal control from the user.
Do not test only the homepage. Many accessibility failures live in the stuff that actually makes money: checkout, booking, quote forms, account areas, filters, embedded scheduling tools, and payment interfaces.
A: Appearance and alternatives — contrast, zoom, images, media and documents
Visual design has to survive more than a designer’s monitor. People enlarge text, zoom the page, use high contrast settings, navigate on narrow screens, suppress motion, and consume the same information without seeing or hearing every element.
For text contrast, WCAG 2.2 Level AA criterion 1.4.3 requires at least 4.5:1 for ordinary text and 3:1 for large-scale text, subject to the criterion’s exceptions. Contrast is only one part of readable typography; our website font-size and readability guide covers resizing, reflow, spacing, and the myth of one magic accessible pixel size.
- Do not use color as the only way to communicate status, error, availability, or selection.
- Make sure content remains usable when text is enlarged and when the viewport becomes narrow.
- Add useful alternatives for meaningful images and charts rather than describing decorative filler.
- Provide captions for prerecorded video when required and a usable text alternative for important audio information.
- Avoid motion or flashing that can create barriers, and give users control when content moves or plays automatically.
- Treat PDFs, office documents, embedded maps, schedulers, chat tools, and other downloads or third-party interfaces as part of the customer experience when they are required to complete a task.
Accessibility is broader than compliance checking. Inclusive design helps teams notice who their assumptions exclude before those assumptions become another round of remediation.
R: Retest and regression — prove the fixes and keep them fixed
Do not close an accessibility issue because the developer changed some code. Close it because the original barrier can no longer be reproduced and the user can complete the task.
The W3C Evaluating Web Accessibility overview is explicit: evaluation should happen throughout development, and no tool alone can determine whether a site meets accessibility standards. Knowledgeable human evaluation is required. DOJ likewise recommends pairing automated accessibility checking with manual checks.
Retest in layers:
- Automated scan: catch machine-detectable issues such as missing names, contrast failures, invalid relationships, and some structural errors.
- Keyboard pass: complete the journey without a mouse and watch focus order, visibility, traps, menus, dialogs, and form behavior.
- Zoom and reflow pass: enlarge content and narrow the viewport to expose clipping, overlap, hidden controls, and two-dimensional scrolling that should not be required.
- Assistive-technology pass: use an appropriate screen reader or other technology for representative tasks, ideally with someone who knows how that technology is actually used.
- Task pass: finish the real customer job from start to confirmation, including third-party steps.
- Regression plan: record what was tested, the result, owner, date, and what changes should trigger retesting.
Once the remediation baseline is stable, hand the recurring problem to an owner. Our guide to website accessibility monitoring covers regression checks after launches, content changes, plugin updates, template edits, and third-party changes.
Website ADA compliance checklist: what to fix and how to verify it
A checklist is useful when it connects each problem to a verification method. Otherwise it becomes ceremonial paperwork: lots of boxes, very little proof.
| Barrier | Typical fix | How to verify |
|---|---|---|
| Keyboard trap or unreachable control | Use native controls or correct keyboard behavior and focus management | Complete the task with keyboard only; confirm no trap and a sensible focus order |
| Invisible keyboard focus | Add a clear focus indicator that survives component states | Tab through every interactive control and confirm focus is always visible |
| Unlabeled form field | Associate a visible label or accessible name with the input | Inspect the accessibility name and test the form with assistive technology |
| Confusing form error | Identify the field and describe the error in text with a recovery path | Submit intentionally invalid data and confirm the problem can be found and fixed |
| Low text contrast | Adjust foreground/background colors to meet the target criterion | Measure the actual rendered colors and inspect real component states |
| Information communicated only by color | Add text, iconography, shape, pattern, or another non-color cue | Review the interface without relying on hue differences |
| Meaningful image has no useful alternative | Add contextual alt text or an equivalent nearby description | Check the accessible name and ask whether the same information is available without the image |
| Content clips at zoom or narrow width | Fix rigid containers, text sizing, spacing, and responsive behavior | Test enlarged text and narrow viewport conditions across the critical journey |
| Video depends on audio alone | Add accurate captions and other alternatives needed for the information | Use the media without sound and confirm the essential content remains available |
| Required third-party tool is inaccessible | Configure, replace, supplement, or provide an equivalent accessible path | Test the full task through the embedded or external experience |
Why automated accessibility tools and overlays are not proof
Automated accessibility tools are useful. Use them. Just do not confuse what they can detect with everything a human can experience.
DOJ notes that automated accessibility checkers and overlays can help identify some problems, but a report showing no errors does not necessarily mean the website is accessible. Its guidance recommends combining automated checks with manual review. W3C makes the same boundary clear: no evaluation tool by itself can determine whether a site meets accessibility standards.
The same caution applies to an accessibility widget. A user-facing preference tool may provide useful options for some people, but installing one does not prove that your checkout works from a keyboard, your form errors are understandable, your dialog exposes the right name and state, or your documents are usable. A widget is a component. Compliance theater is pretending the component replaced the work.
How should you prioritize accessibility fixes?
Do not prioritize only by how quickly a defect can be fixed. Prioritize by the harm it creates in the real customer journey.
A useful order is:
- Blockers: barriers that prevent a person from completing a critical task at all.
- Major obstacles: barriers that make a task possible only with excessive effort, workarounds, or outside help.
- Repeated friction: issues in global navigation, shared forms, templates, or components that affect many pages or visits.
- Local defects: isolated problems that matter but do not block an important task.
- Polish: improvements that strengthen an already usable experience.
Then look for leverage. Fixing one broken form component across twelve templates is usually more valuable than hand-editing twelve symptoms. Replacing one inaccessible menu component can repair the entire site. The goal is not to minimize the issue count. The goal is to remove the most consequential barriers with fixes that hold up.
Frequently asked questions about ADA website accessibility
Can a website be ADA compliant?
A website can be evaluated for conformance to a named technical standard and scope, such as WCAG 2.2 Level AA. Whether an organization complies with the ADA is a legal question that depends on the applicable title, organization, services, circumstances, and other obligations. For private businesses, avoid turning a technical test result into a universal legal guarantee.
How do I determine if my website is ADA compliant?
First identify the legal or contractual framework that applies. Then define the technical target and test scope. Evaluate representative templates and critical journeys with automated checks, keyboard testing, zoom/reflow testing, knowledgeable manual review, and appropriate assistive technology. Record failures, remediation, retest evidence, and known limitations. A one-page scanner result is not enough.
Does WCAG 2.2 AA guarantee ADA compliance?
No. WCAG 2.2 is a current technical accessibility standard and an excellent way to organize remediation, but DOJ does not describe WCAG 2.2 AA as a universal legal safe harbor for every private website. Your legal obligations can depend on the organization and context. Use the technical standard honestly and get qualified legal advice when you need a legal determination.
Can I be sued for an inaccessible website?
Accessibility disputes and lawsuits do occur, and DOJ states that ADA Title III applies to businesses open to the public and their covered online goods and services. The risk for a particular business depends on facts this article cannot determine. Build accessibility because people need access, document your work, and talk with qualified counsel if you need advice about your legal exposure or a specific demand.
How much does website accessibility remediation cost?
There is no honest universal price. Cost depends on the number of templates and critical journeys, the age and quality of the code, custom interactive components, third-party tools, forms, media, documents, content volume, testing depth, and how many problems can be fixed once at the component level. A scoped audit should tell you what is broken before anyone pretends a flat price means the same thing on every site.
Can an accessibility overlay make my website compliant?
An overlay or widget may change presentation or add options that help some users, but it is not proof that the underlying website and customer journeys meet the required standard. DOJ warns that automated checker and overlay results can miss accessibility problems. Manual evaluation still matters.
How often should accessibility be retested?
Retest after meaningful changes to templates, navigation, forms, checkout, booking, plugins, themes, third-party widgets, media, and important content. Also schedule recurring checks based on how often the site changes and how critical the affected journeys are. Accessibility is easier to maintain as part of normal QA than to rediscover as a giant cleanup project every few years.
Make accessibility an owned website requirement
A better accessibility program is not “install a thing and hope nobody complains.” It is a repeatable operating habit: identify the right target, prioritize real customer journeys, remediate barriers, verify the fixes, and assign someone to keep the baseline from drifting.
If you need help turning an accessibility audit into practical website work, talk to Scope Design. We can review representative templates and journeys, document barriers, rank remediation work, and help implement fixes without pretending one scanner score is the whole job.
