An accessible website is one people with disabilities can use, whether they rely on a screen reader, a keyboard, magnification or captions. The Department of Justice has no regulation setting detailed web standards for private businesses, so we build and test to WCAG 2.2 Level AA, the current W3C standard, and fix existing sites the same way.
What an "ADA Compliant Website" Can Honestly Mean
People search for ADA compliant website design because they want two things: a site everyone can use, and protection from a lawsuit. We can deliver the first with confidence. The second deserves a straight answer, so here is what the law and the standards actually say.
Title III of the Americans with Disabilities Act covers businesses open to the public. In March 2022 the Department of Justice published Guidance on Web Accessibility and the ADA (opens in a new tab). It says the Department has consistently taken the position that the ADA's requirements apply to the goods and services businesses offer on the web, that it does not have a regulation setting out detailed standards, and that businesses have flexibility in how they comply. It also points to existing technical standards, including WCAG, as helpful guidance, and it lists the barriers it sees most: poor color contrast, missing text alternatives, missing video captions, inaccessible forms and mouse-only navigation.
For state and local governments, covered by Title II, the Department went further. Its rule on web content and mobile apps (opens in a new tab), published April 24, 2024, adopts WCAG 2.1 Level AA as the technical standard. An interim final rule published on April 20, 2026 extended the compliance dates to April 26, 2027 for governments serving 50,000 or more people, and April 26, 2028 for smaller governments and special district governments. That rule does not apply to private businesses directly, but it shows which standard the Department chose when it did write one.
We target WCAG 2.2 Level AA. W3C published WCAG 2.2 as a Recommendation on October 5, 2023, and it encourages using the latest version (opens in a new tab). W3C also states that content conforming to WCAG 2.2 also conforms to 2.1 and 2.0, so a site built to 2.2 AA meets the 2.1 AA level the Title II rule names, with a few more user protections on top.
WCAG 2.2 Level AA in Plain English
WCAG is organized around four principles, often shortened to POUR. W3C's introduction to understanding WCAG 2.2 (opens in a new tab) defines each one. Here is what they mean on a typical small business website.
| Principle | What it means | What it looks like on your site |
|---|---|---|
| Perceivable | Information and controls must be presented in ways people can perceive, whatever their senses. | Alt text on meaningful photos, captions on videos, text contrast of at least 4.5:1 (3:1 for large text), content that reflows on a phone without sideways scrolling. |
| Operable | Every control and all navigation must work for people using different input methods. | Menus, buttons and forms that work with a keyboard alone, a focus outline that is always visible and never hidden under a sticky header, tap targets at least 24 by 24 CSS pixels or well spaced, no keyboard traps. |
| Understandable | Information and the way the site works must be understandable. | Clear labels and instructions on forms, error messages that say what to fix, navigation and help links that stay in the same place from page to page, plain language. |
| Robust | Content must work reliably with a wide range of browsers and assistive technologies. | Correct HTML for headings, lists, buttons and links, accessible names on icons and form controls, and status messages that screen readers announce. |
The Failures We Find Most Often
When we audit small business sites on the coast, the same problems come up again and again. Most are not hard to fix once someone looks for them.
- Low contrast text: pale gray on white, or white headlines over busy beach photos.
- Missing or useless alt text: a file name such as IMG_4021.jpg read aloud, a menu photo described only as "image," or decorative swirls announced to screen reader users.
- Keyboard traps: pop-ups, chat widgets and booking embeds you can tab into but cannot tab or escape out of.
- Unlabeled form fields: placeholder text used as the only label, which disappears as soon as someone starts typing.
- Invisible focus: a theme that removes the focus outline, so keyboard users cannot see where they are on the page.
- Broken heading structure: bold text styled to look like headings, or heading levels chosen for size instead of order.
- Vague links: "click here" and "read more" repeated down the page with no clue where each one goes.
- Tiny tap targets: social icons and close buttons too small or too crowded to hit on a phone.
- Menus and brochures as images or scanned PDFs: nothing a screen reader can read and nothing a phone user can zoom comfortably.
- Moving content with no pause: auto-advancing sliders and background videos with no way to stop them.
WCAG 2.2 added six new requirements at Levels A and AA that catch several of these: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry and Accessible Authentication (Minimum). W3C's summary of what is new in WCAG 2.2 (opens in a new tab) explains each one and notes that the old 4.1.1 Parsing criterion was removed as obsolete.
Why Overlay Widgets Do Not Make a Site Compliant
An overlay is a script added to a website, usually with a floating button, that claims to detect and repair accessibility problems automatically. They are sold heavily to small businesses as a one-line fix. They are not one.
The Overlay Fact Sheet (opens in a new tab), signed by more than a thousand accessibility practitioners, developers and people with disabilities, states that no overlay product can make a website fully compliant with any existing accessibility standard. Federal regulators have weighed in too. In April 2025 the Federal Trade Commission approved a final order requiring accessiBe to pay $1 million (opens in a new tab) over claims that its AI-powered accessWidget could make any website WCAG compliant. The order bars the company from claiming its automated products can make any website WCAG-compliant without evidence to support it.
The reason is practical. A missing form label, a confusing reading order or a booking widget that traps the keyboard is a problem in the site's own code and content. It has to be fixed there, by someone who understands what the page is supposed to do.
About the toolbar on our own sites: sites we build include an optional preference toolbar that lets visitors enlarge text, switch to a more readable font, highlight links and make similar adjustments. It is a convenience for people who like those options. It is not how we meet WCAG, it does not repair anything, and every page works fully with it switched off.
Florida and Website Accessibility Lawsuits
Florida is one of the busiest states in the country for website accessibility lawsuits. Seyfarth Shaw, a law firm that tracks ADA Title III filings, reported these federal court numbers for 2025:
Those figures come from Seyfarth's report, Federal Court Website Accessibility Lawsuit Filings Bounce Back in 2025 (opens in a new tab), and they exclude state court cases and demand letters, which the firm notes are also common.
We are web developers, not lawyers, and nothing on this page is legal advice. No honest designer can promise that a site will never draw a demand letter. What we can do is remove the real barriers, document how the site was tested, publish an accessibility statement with a working contact, and help you respond quickly when someone reports a problem. That is what protects your customers, and it is far better footing than a widget.
How We Audit a Website
Every audit combines automated tools with human testing, because W3C's guide to selecting evaluation tools (opens in a new tab) is clear that tools cannot determine accessibility on their own, they can only assist, and human judgment is required.
Automated scan
We run axe-core, the Lighthouse accessibility audit and our own AldoMedia Ultimate Website Scanner across your key templates to catch contrast failures, missing alt attributes, unlabeled fields and invalid ARIA quickly.
Keyboard-only pass
We put the mouse away and move through every menu, form, pop-up and embedded widget with Tab, Shift+Tab, Enter, Space, Escape and the arrow keys.
Screen reader pass
We listen to the page: headings, landmarks, link names, form labels, error messages and status updates, and we try to complete the tasks that matter, such as calling, booking or ordering.
Zoom, reflow and contrast
We enlarge text, zoom to 400 percent, narrow the window to phone width and measure the contrast of real color combinations, including text over photos.
Code validation
We check HTML with the W3C Nu Html Checker and CSS with the W3C CSS Validation Service, because clean structure prevents problems that assistive technology stumbles over.
Content review
We review alt text quality, link wording, heading order, plain language, PDFs and video captions.
Report and plan
You get a prioritized list: each issue, where it appears, the WCAG criterion involved, who it affects and how we would fix it, with the most damaging barriers first.
Accessibility Statements
An accessibility statement tells visitors what standard your site aims for and how to reach you if something does not work. W3C's guide to developing an accessibility statement (opens in a new tab) recommends including your commitment, the standard applied (such as WCAG 2.2), contact details for reporting problems and, ideally, known limitations and the date of the last review. W3C even offers a free generator.
We write a statement for every site we build and keep it current. It is not a legal shield. Its value is practical: a customer who hits a problem has a direct way to tell you, and you have a written record that accessibility is ongoing work, not a one-time checkbox. You can read our own accessibility statement as an example.
Remediating an Existing Website
Most coastal businesses already have a website, and a rebuild is not always the answer. Remediation starts where it does the most good:
- Fix templates first: the header, navigation, footer and forms appear on every page, so one repair there fixes the issue everywhere.
- Prioritize real tasks: finding your hours and location, calling, booking, ordering and sending a message come before anything decorative.
- Deal with third-party embeds: booking engines, reservation tools, chat widgets and maps. We ask vendors for accessibility conformance reports, configure what can be configured and suggest alternatives when a tool cannot be made usable.
- Turn image menus and PDFs into real pages: a restaurant menu in HTML is readable, searchable and easy to update.
- Train whoever edits the site: alt text, heading order and link wording, so new content stays accessible. Clients who use our SimpleCMS editor get the same guidance.
- Re-test on a schedule: every redesign, new plugin or new widget can undo earlier fixes.
When a site is built on a heavy theme or page builder with deep structural problems, a rebuild can cost less than patching it page by page. After the audit we will tell you which path makes sense. Accessible structure also supports our local SEO and website speed work, and every custom website we design is built to the same WCAG 2.2 AA target from the first line of code.
Frequently Asked Questions
Will an accessibility overlay or widget make my website compliant?
No. The Overlay Fact Sheet, signed by more than a thousand accessibility practitioners, says no overlay can make a site fully compliant with any accessibility standard, and in 2025 the FTC finalized a 1 million dollar order against one overlay vendor over claims that its tool could make any website WCAG compliant. Real fixes happen in the site's code and content.
Does the ADA apply to my small business website?
In its 2022 guidance, the Department of Justice says it has consistently taken the position that the ADA applies to the goods and services businesses open to the public offer on the web, and that businesses have flexibility in how they comply. There is no detailed federal technical rule for private business websites, which is why WCAG is the usual benchmark. Ask an attorney about your specific situation.
Can you guarantee my website will never be sued?
No one can honestly promise that. A demand letter can be sent about any website, and the outcome depends on facts and law that a web developer does not control. What we can do is remove real barriers, test by hand and with tools, document the work and give you an accessibility statement so visitors can reach you.
What changed between WCAG 2.1 and WCAG 2.2?
WCAG 2.2, published by W3C in October 2023, added nine success criteria, six of them at Levels A and AA, covering focus that is not hidden behind sticky headers, minimum target size, alternatives to dragging, consistent help, not re-entering information and easier logins. It also removed the obsolete Parsing criterion. W3C says content that conforms to 2.2 also conforms to 2.1.
How much accessibility testing can be automated?
Only part of it. Tools such as axe quickly catch problems like low contrast, missing alt attributes and unlabeled fields, but W3C notes that tools cannot check every aspect and that human judgment is required. Whether alt text is accurate, whether focus order makes sense and whether a screen reader user can finish a booking all need a person.
Do I need an accessibility statement on my website?
No specific federal rule requires one for a private business, but W3C recommends it and it is good practice. A statement names the standard you follow, gives people a way to report problems and shows that accessibility is ongoing work. We write one for every site we build.
What should I do if I receive an ADA demand letter about my website?
Contact an attorney first, because we are web developers, not lawyers, and your response has legal consequences. Then get an independent audit so you know which barriers are real. We can provide that audit and fix what it finds, with documentation of what was tested and what changed.
Sources and Further Reading
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab)
- W3C WAI, Introduction to Understanding WCAG 2.2: the four principles (opens in a new tab)
- U.S. Department of Justice, Guidance on Web Accessibility and the ADA (March 2022) (opens in a new tab)
- U.S. Department of Justice, Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments (opens in a new tab)
- Federal Trade Commission, FTC Approves Final Order Requiring accessiBe to Pay $1 Million (April 2025) (opens in a new tab)
- Overlay Fact Sheet (opens in a new tab)
- Seyfarth Shaw, ADA Title III blog: Federal Court Website Accessibility Lawsuit Filings Bounce Back in 2025 (opens in a new tab)