Service · Web Accessibility

ADA demand letters target broken code. The defense is fixing it — not installing a widget that pretends it's fixed.

Plaintiffs' law firms scan thousands of small business websites at once, looking for missing image descriptions, forms that screen readers can't use, and menus that require a mouse. When they find enough violations, a demand letter follows. Accessibility overlays — the $50/month widgets that promise compliance — don't fix those violations. They sit on top of broken code and courts have rejected them as a defense. Every site ArdinGate builds is built to WCAG 2.1 AA standards as part of the build: correct structure, keyboard navigation on every element, labeled forms, color contrast validated during design, and a dated written compliance report your attorney can actually use. For existing sites, the same standard applies through a full audit and code-level remediation — not a shortcut.

Get a free accessibility review Read the WCAG guide

What WCAG 2.1 AA compliance requires: seven things every site has to get right

The ADA accessibility standard for websites (WCAG 2.1 AA) comes down to seven concrete categories. These aren't abstract principles — each one translates to specific code-level requirements that have to be built into the site. They can't be added by a plugin after the fact. Each one below is what failure looks like in practice, why it gets cited in demand letters, and how ArdinGate handles it on every build.

1

Meaningful image descriptions on every photo, graphic, and icon

Missing or empty image descriptions are the most frequently cited violation in ADA demand letters. They're what automated scanners find first because they're easy to detect at scale: an image with no description at all, or one labeled "image" or "photo," or a product shot with the file name as its description ("hero-banner-final-v3.webp"). A visitor using a screen reader — software that reads the page aloud — hears the file name or complete silence. For a restaurant, that might be your menu's food photography. For a dentist, before-and-after photos. For a gym, equipment and class photos. Whatever those images are meant to communicate to a sighted visitor is completely invisible to someone who's blind without a proper description. Writing those descriptions isn't a simple fill-in — a product image needs to convey what the item looks like, a team photo needs names and roles, an infographic needs a summary of the data it presents. Every image ArdinGate adds gets a description written for what it actually communicates, not a placeholder.

2

Color contrast that people with low vision or color blindness can actually read

WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 between text and its background — a specific measurement of how distinct the two colors are from each other. For large headings, the requirement is 3:1. These thresholds exist because a significant portion of your customers have some degree of low vision, color blindness, or age-related vision change, and because screen glare and bright sunlight reduce effective contrast for everyone. Most brand color palettes were picked by a designer or a business owner who never checked these ratios. Light gray text on white is a common aesthetic choice that fails by a wide margin. Medium-toned brand accent colors used as link text frequently fail as well. Colored buttons where the label text doesn't stand out enough from the button color are another common problem. For new builds, every color in the palette — body text, headings, links, button labels, placeholder text — is measured against the WCAG threshold before design is finalized. Nothing gets locked in that doesn't pass. For existing sites, every failing combination is flagged, discussed, and fixed only after you've approved the alternative.

3

Full keyboard navigation on every interactive element: buttons, menus, forms

People who can't use a mouse — due to motor disabilities, tremors, or assistive hardware — navigate websites entirely by keyboard. Tab moves forward through interactive elements, Enter activates links and buttons, arrow keys move through menus. A site that requires a mouse for any part of its navigation fails multiple accessibility requirements. The most common failures include: buttons built from styled divs instead of actual button elements, which keyboards can't reach; navigation dropdowns that only open on mouse hover with no keyboard equivalent; popup dialogs that open without moving keyboard focus inside them, leaving keyboard users stuck behind the overlay; and the near-universal practice of removing the visible focus outline (the highlight that shows which element is currently selected) because it "looks ugly." Removing it makes the site completely unusable for anyone navigating by keyboard. Every interactive element ArdinGate builds is keyboard reachable, keyboard operable, and has a clearly visible focus indicator so users always know where they are on the page.

4

Contact forms and intake forms a screen reader user can complete

Your contact form is where potential customers try to reach you. If a screen reader user can't complete it, that's a customer who couldn't contact you — and potentially an ADA violation. The most common form failures: input fields that only use placeholder text as a label (placeholder text disappears the moment someone starts typing, so a screen reader user loses all context about what to type); error messages that appear visually after failed submission but aren't announced aloud, so the user has no idea something went wrong or what to fix; required fields that aren't flagged as required; and phone number fields coded as generic text inputs, which prevents mobile devices from showing the phone keypad. Every form ArdinGate builds uses permanent label text that stays visible and readable throughout the interaction, error messages that are announced immediately to screen readers, and input types that match the expected data so the right keyboard appears on mobile.

5

Organized headings and page landmarks so screen readers can navigate

Screen reader users don't read pages top to bottom. Instead, they jump between headings and sections to scan for what they need — like how your eye skims a page looking for the part that matters to you. That navigation only works if the page is organized correctly: one main heading that says what the page is about, subheadings in a clear hierarchy without gaps in the levels, and clearly marked sections (like navigation, main content, and footer) that let users jump directly to any part of the page. Pages built by dragging blocks in a visual editor often throw out all of this — headings are picked for how big they look, not how they organize the page, and nothing tells a screen reader what section they're in. Every ArdinGate page has a single, correctly placed main heading, subheadings in logical order, and marked sections that screen reader users can navigate the way they expect.

6

Invisible labels that announce what's happening on the page

When something changes on the page — a menu opens, a popup appears, a form shows an error — screen reader users need to hear about it. Behind the scenes, I add invisible labels that tell a screen reader "this menu just opened" or "this popup is asking for your zip code" or "this error message appeared." Without these announcements, a screen reader user clicks a button and hears nothing. They don't know whether a menu appeared, whether a form went through, or whether a dialog is waiting for them. A dropdown menu needs to announce when it's open or closed. A popup dialog needs to announce its title and guide focus inside when it appears, then return focus to the button that opened it when the dialog closes. A collapsing section needs to announce whether it's currently visible or hidden. These invisible labels are what separate a site that actually works for screen reader users from one that looks accessible on the surface but breaks as soon as someone tries to use it.

7

Skip navigation, unique page titles, and link text that makes sense on its own

Three separate requirements that each seem minor in isolation and collectively have a significant effect. Skip navigation is a hidden link at the top of every page that lets keyboard users jump past the site navigation directly to the page content. Without it, every page load forces keyboard users to Tab through every navigation link before they reach anything — on a site with a large menu, that's 20 or more keystrokes before the user gets anywhere useful. Page titles are what appears in the browser tab and what a screen reader announces when a page loads: "ArdinGate" on every single page tells a screen reader user nothing about where they are or what the page is about. Descriptive, unique titles on every page fix this. Link text is what a screen reader reads for every link on the page: "read more / click here / learn more / read more" is completely useless without visual context. Descriptive link text ("read the WCAG compliance guide," "request a free site review") communicates destination and purpose for everyone, including users who navigate by link list.

The pre-contact checklist: what a business owner does after receiving an ADA demand letter, before calling anyone

A business owner who just opened a demand letter from an ADA plaintiffs' firm is not in a normal buying mood. They have a specific legal problem with a response deadline, and before they contact anyone, they run a very specific vetting process. Here's what that process looks like and what it means for how ArdinGate positions itself.

They search for the overlay vendors named in review articles and learn those overlays were rejected in court

The first thing almost every demand-letter recipient does is search "ADA website compliance" and click the first few results. Most of those results are overlay vendor ads: AccessiBe, UserWay, AudioEye. The pitch is reassuring — install this, get a badge, you're covered. But demand-letter recipients read deeper than the ad, because they have to. Within twenty minutes of searching, most find articles explaining that overlays have been sued over, that the National Federation of the Blind has formally condemned them by name, and that courts have not accepted overlay presence as a defense. At that point they know the first tier of the market (overlay vendors) is worthless. They start looking for the second tier. Any accessibility provider whose website promotes overlays or doesn't explicitly reject them gets filtered out at this stage. ArdinGate's position is unambiguous and visible: overlays are not offered, not recommended, and don't work. That clears the first filter.

They look for evidence that you test the way the demand letter expects

ADA demand letters often cite specific WCAG success criteria by number and describe the violations in technical terms. A business owner reading a demand letter that references "WCAG 2.1 criterion 1.4.3: color contrast" and "WCAG 2.1 criterion 4.1.2: name, role, value" knows more about their site's accessibility violations than most web designers do. When they evaluate providers, they look for whether the provider can demonstrate testing methodology that matches the specificity of the violation list: automated baseline scan first, then manual keyboard navigation testing on every interactive element, then screen reader testing on NVDA, JAWS, and VoiceOver. If a provider's website only mentions "running a scan" or "checking your site," the prospect understands immediately that the scan is all they do and that a scan covers only 30–40% of violations. The violations cited in most demand letters are in the other 60–70%. ArdinGate describes the full testing methodology explicitly: automated plus manual plus screen reader. That's what the demand letter warrants.

They ask whether the compliance report will hold up when their attorney reads it

A business owner managing an ADA demand letter is likely talking to their attorney at the same time they're contacting accessibility providers. The attorney will ask to see the compliance report. The prospect evaluating ArdinGate knows — or quickly learns — that a two-page marketing summary that says "your site now meets WCAG standards" won't satisfy an attorney reviewing their defense posture. What they need is a dated PDF that identifies every page audited, every violation found (with the specific WCAG criterion it violated), what fix was applied, a retest confirming the fix, and the net conformance status of every page after remediation. That's what ArdinGate delivers. Prospects who ask about the report format before committing to any quote are asking because their attorney told them to ask. The answer matters.

They want to know upfront whether their platform can be fully remediated, or needs replacement

A prospect running on Squarespace, Wix, or a heavily-plugged WordPress install has a legitimate platform-layer question that most accessibility providers dance around. The honest answer is that platform-generated components — mobile nav drawers, image carousels, embedded booking widgets, popup dialogs — are rendered by the platform's code, not the site owner's code, and that code can't be modified. Content fixes (image descriptions, headings, color choices, form labels) are available. Platform-layer fixes often aren't. A prospect who doesn't learn this until after paying for a remediation engagement and receiving a report that says "these violations were found but cannot be fixed on this platform" is an unhappy client with a good reason to be unhappy. ArdinGate surfaces this distinction in the first conversation, before any quote is given, because the information is relevant to the decision about whether to remediate in place or build new.

The four stages of an ADA compliance engagement: from demand letter to documented defense

Most accessibility engagements start with a legal trigger, not a proactive decision. Understanding the typical path from exposure awareness to documented compliance shows where the work happens and why each stage matters, especially for a prospect evaluating providers under time pressure from a demand letter.

Stage 1: Exposure awareness. The business owner discovers their site is a potential ADA target. For most businesses, this comes through a demand letter. For a smaller number, it comes through a conversation with an attorney, a warning from a trade association, or a news story about lawsuits targeting their industry. At this stage the business owner doesn't yet know what WCAG is or what the violations are. They know they have a problem and a deadline. Their first move is to search for a solution.

Stage 2: Provider selection. The business owner evaluates options, learns that overlays don't provide legal protection, and starts looking for a provider who can do the actual work: full audit, code-level fixes, manual testing, written report. This is the stage where methodology specificity, clear overlay rejection, and a credible compliance report format are the deciding factors. It's also the stage where platform constraints surface for sites built on Squarespace, Wix, or WordPress: can the violations cited in the demand letter be fixed on the existing platform, or does compliance require rebuilding the site on a platform where the full code is controllable?

Stage 3: Audit and remediation. The engagement starts with an automated scan of every page to establish the full violation list. Manual testing follows: keyboard-only navigation through every interactive element, screen reader testing on NVDA, JAWS, and VoiceOver, verification of ARIA implementation on every dynamic component, and form label testing by code inspection. Code-level fixes are applied for every violation. Each fix is retested before it's marked resolved. The written compliance report documents every finding, every fix, and every retest result.

Stage 4: Ongoing compliance. The compliance report is dated — it documents the state of the site at the time of the audit. Every subsequent change to the site needs to be reviewed against the same WCAG standard. A site that was compliant at the time of the audit and added non-compliant content afterward is a non-compliant site. For sites ArdinGate builds and maintains, updates carry the same accessibility standard as the original build. For clients managing their own content updates, the written compliance report serves as a reference for what to watch for and what to avoid.

Where the funnel breaks most often: Stage 3, when a provider runs only an automated scan, calls it a full audit, and delivers a compliance report that covers the 30–40% of violations automated tools detect. The violations cited in the demand letter are frequently in the 60–70% that require manual testing. The report doesn't document the fix for the specific violations that triggered the letter. The attorney reviewing it flags this immediately, the settlement posture is unchanged, and the business owner has paid for an audit that didn't solve their problem.

Why overlays fail, why template platforms can't fully comply, and why hand-coded is the only approach that holds up

The accessibility overlay industry (AccessiBe, UserWay, AudioEye, EqualWeb) has built a business model on selling false certainty to business owners concerned about ADA exposure. The pitch is appealing: install a widget for $50/month, get a compliance badge, tell your attorney you're covered. The legal record says otherwise.

Overlays run JavaScript after your page loads and try to patch violations without changing the actual code underneath. The fundamental problem is that accessibility is built into how the page code is structured — you can't patch it from the outside. An overlay can try to guess at image descriptions using AI, but it has no way to know what each image is actually supposed to communicate. A product photo of a red wool sweater might get labeled "image" or "fabric item" — useless to a blind visitor. An overlay can try to add labels to buttons and forms, but it can't fix a popup that doesn't move focus into itself when it opens — that's controlled by the page's actual logic, not something an outside script can inject. An overlay can try to fix keyboard navigation, but it frequently breaks navigation that was already working by inserting its own rules that contradict what the page actually does.

Courts have not ruled that an installed overlay constitutes good faith WCAG compliance. Multiple lawsuits have been filed against businesses where an overlay was present and running. In documented cases, the widget made the site less usable for the plaintiff by interfering with their own assistive technology settings. The National Federation of the Blind has called out AccessiBe and UserWay by name for providing false compliance assurances. Over 800 disability advocates and accessibility professionals signed an open letter against overlays in 2021, and the position documented there has not changed. They are not a legal defense. They are a business selling the appearance of a legal defense.

Template platforms (Squarespace, Wix, Webflow) have a different constraint: accessibility problems built into the platform's own components that the site owner cannot fix. A Wix site using the platform's image carousel can't control whether you can navigate it by keyboard — that's Wix's decision. A Squarespace mobile menu might open a drawer without moving focus inside it, leaving keyboard users unable to interact with it. A Webflow animation might hide elements but leave them in the keyboard navigation order, so users Tab through things they can't see. These are platform decisions you can't override, and they create violations that survive any attempt to fix the visible content.

A hand-coded site has none of these constraints. Every interactive element is built from scratch with the right accessibility behavior: a popup that moves focus inside when it opens, a dropdown that announces when it's open or closed, a navigation skip link that's actually there and reachable, a form that announces errors immediately. There are no platform decisions to work around and no terms of service stopping you from controlling every line of code. That's why full accessibility compliance on a hand-coded site is completely achievable and permanently maintainable in a way that template platforms and overlay products simply cannot be.

Platform comparison: custom hand-coded vs. Wix, Squarespace, and WordPress →

Pricing

Web accessibility compliance is included with every new website ArdinGate builds — not as a line item, not as an upgrade, and not as a feature you have to ask for. It's part of how the code is written from day one. A well-organized page structure, labeled forms, keyboard navigation that works everywhere, color contrast validated during design, and invisible labels on things that change: this is what correct, professional code looks like. It doesn't cost extra because it isn't extra work when you build it right.

New site builds start at $1,200 for a single-page site and $2,800–$5,000 for multi-page sites. Both include a dated, written WCAG 2.1 AA compliance report documenting what was tested, which screen readers and browsers were used, and the conformance status of every page — formatted to be shared with an attorney if you ever need to demonstrate due diligence.

For existing sites needing a standalone audit and remediation, pricing starts at $800 for sites under ten pages. That covers the full audit: automated baseline scan, manual keyboard-only navigation testing across every interactive element, screen reader testing on NVDA, JAWS, and VoiceOver, code-level fixes for every finding, retest of each fix, and the written compliance report. Sites with more pages or a higher violation count are quoted individually after a free review — there's no per-page flat rate because the actual scope depends on what's broken, not how many pages exist.

For context on the cost math: ADA demand letter settlements typically run $10,000–$75,000 before legal fees. Defense legal fees add another $15,000–$30,000 even for cases that settle quickly. An audit and remediation costs a fraction of that, and a compliance report that predates a demand letter shifts the negotiation posture: documented good-faith remediation, before the claim, is a different position than reactive remediation after a letter arrives.

Overlays are not offered and are not recommended. If one is currently installed on your site, it can be removed as part of a remediation engagement. Its presence doesn't reduce the audit scope, because the underlying code is what determines whether each accessibility requirement is met.

Full pricing breakdown →  ·  Accessibility remediation service detail →

Web accessibility questions answered

Courts have consistently ruled that business websites are places of public accommodation under ADA Title III, and the DOJ confirmed that position with formal guidance in 2022. In practice, your website carries ADA exposure regardless of business size or industry. Plaintiffs' law firms run automated WCAG scanners against entire business categories simultaneously, looking for sites with high violation counts and significant traffic. E-commerce, healthcare, restaurant, and financial-services sites get hit most often, but any business with a public-facing website is a potential target. The practical question isn't whether the law applies — it does — but whether your site is low-hanging fruit for a demand letter. A site with documented WCAG 2.1 AA compliance and a dated compliance report is in a markedly different legal position than one that has never been audited.
WCAG stands for Web Content Accessibility Guidelines — it's the technical standard courts and regulators use to define what an accessible website looks like. Think of it as the rulebook for accessibility. It has three levels: A (minimum basics), AA (the legal standard), and AAA (extra measures like live audio captions, not required for most businesses). WCAG 2.1 AA is the legally defensible benchmark. The DOJ references it directly, and it's what courts look at when evaluating ADA Title III compliance. WCAG 2.2 came out in 2023 with a few additional requirements, and legal enforcement is beginning to move toward it. ArdinGate builds to WCAG 2.2 where feasible, but 2.1 AA is the compliance floor that matters legally right now.
For new sites built by ArdinGate, WCAG 2.1 AA compliance is included at no additional charge — it's not an add-on because accessibility is built into how the HTML is written from day one, not patched on at the end. New site builds start at $1,200 for a single-page site and $2,800–$5,000 for multi-page sites. Both include a written WCAG 2.1 AA compliance report you can keep on file or share with your attorney. For existing sites that need a standalone audit and remediation, pricing starts at $800 for sites under ten pages. That covers the full audit, code-level fixes, manual screen reader testing, and the written report. Sites with more pages or a high violation count are quoted after a free review.
No, and the legal record is clear on this. Courts have not ruled that having an overlay installed constitutes good faith WCAG compliance. Multiple lawsuits have been filed specifically against businesses that had an overlay running. In several documented cases, the overlay made the site less usable for disabled users by interfering with their own screen reader settings — so the overlay became a second target alongside the underlying violations. The National Federation of the Blind has called out AccessiBe, UserWay, and others by name for providing false assurances. Overlays cannot fix structural problems in the HTML: they attempt to patch violations in the browser after the page loads, and they fail at the specific violations that trigger demand letters — broken keyboard navigation, inaccessible forms, focus management failures. ArdinGate does not offer or recommend overlays. If you have one installed, it can be removed as part of a remediation engagement.
Missing or inadequate image descriptions are the most common violation and what automated scanners catch first — an image of your team or products with no description means a blind visitor hears nothing, or hears the file name. Low color contrast is second: if your text is light gray on white, or your brand color doesn't stand out enough from the background, people with low vision or color blindness can't read it. Third is broken form labels — contact forms where the field has no permanent label, so a screen reader user can't tell what to type where. Fourth is keyboard navigation gaps: buttons and menus that require a mouse click that a keyboard-only user can't reach. Fifth is missing navigation skip links, which force screen reader users to listen to your entire navigation menu on every single page before getting to any content. All of these require fixing the actual code — not installing a widget that claims to auto-correct them.
No, and this is where a lot of businesses get burned. Automated tools catch roughly 30–40% of accessibility violations — the ones detectable by looking at code patterns. The other 60–70% require a human to use the site with a keyboard and screen reader. An image might technically have a description but the text might be nonsensical. A form label might be in the code but attached to the wrong field. A skip link might exist but be invisible and unreachable. A popup dialog might open without moving keyboard focus inside it, leaving keyboard users stuck. Every ArdinGate audit starts with automated scanning, then closes the gap with manual keyboard navigation testing and screen reader testing on NVDA, JAWS, and VoiceOver before the compliance report is written. A report based only on an automated scan covers a fraction of what a demand letter typically cites.
Rarely, and usually not in any way sighted visitors would notice. Adding image descriptions, form labels, skip links, and the behind-the-scenes markup that talks to screen readers is entirely invisible to someone using a mouse. The one area where visual changes sometimes happen is color contrast. If your brand uses light gray text on white, or a brand color that doesn't meet the contrast threshold, those need adjustment. For new builds, the color palette gets checked against accessibility thresholds during the design phase before anything is locked in. For existing site remediation, any visual adjustments are flagged and discussed with you before anything is touched. Nothing on screen changes without your sign-off. Accessible design and attractive design aren't opposites. Apple, Google, and Microsoft spend enormous resources making accessible design look exceptional.
Yes, in meaningful ways. The structural practices that make a site work well for screen readers also make it easier for Google to understand. A clear heading structure signals what each section is about. Image descriptions tell Google what the image shows. Link text that describes where links go helps Google map your site accurately. A logical page layout with properly labeled sections is easier for Google's crawlers to traverse. Google crawlers work similarly to screen readers — they read the code, not the visual design. A well-organized, correctly built page is easier to rank accurately. Hand-coded accessible sites also tend to load faster than template-builder sites, which Google measures and rewards directly. The overlap between good accessibility and good SEO isn't perfect, but building correctly for one consistently helps the other.
The report documents every WCAG 2.1 AA requirement tested: which pages were audited, what tools were used, which screen readers and browsers were used for manual testing (NVDA on Chrome, JAWS on Chrome, VoiceOver on Safari), every violation found with a reference to the specific accessibility rule it violated, what fix was applied, and a retest result confirming the fix worked. The final conformance status of every page after remediation is documented. It's delivered as a dated PDF formatted to be shared with an attorney. Use it as proof of due diligence if you're proactively building a defense, or as evidence for responding to a demand letter showing that violations have been found, fixed, and verified rather than just promised.
Yes. Every time your site changes, that change can introduce new violations. Adding a new page, updating your contact form, embedding a video, changing your color scheme, or adding a booking widget can all break something that was previously compliant. A site that passed a compliance audit in January and added three non-compliant pages in March is non-compliant in March. The audit doesn't carry forward to new content. For sites ArdinGate builds and maintains, every update follows the same accessibility standards as the original build. For clients managing their own content updates, the written compliance report serves as a reference guide: what the standards require, what common failures look like, and how to recognize them before they accumulate into a legal exposure you didn't know you had.
For hand-coded sites, yes — full audit and code-level remediation with no platform constraints. For sites built on Squarespace, Wix, or Webflow, there's an important limitation to know upfront: certain components (mobile menus, image sliders, popup dialogs, embedded booking widgets) are generated by the platform's own code, which you can't change. The content layer — image descriptions, headings, labels, color choices — can be fixed. The platform-generated components often can't, because those are Squarespace's or Wix's decisions, not yours. WordPress sites with fully custom themes have more room to work with, but plugin-generated components have the same constraint. A free review of your existing site clarifies exactly what can and can't be fixed before any quote is given, so there are no surprises about scope after you've committed to anything.
A remediation engagement takes your current site, audits every page against WCAG 2.1 AA, fixes every violation at the code level, retests each fix, and delivers a written compliance report. It's corrective work on what already exists. A new accessible build starts from scratch with every structural decision made correctly from the beginning: the heading hierarchy planned before writing a line, the color palette validated before design is finalized, keyboard navigation built into every interactive element from day one, form labels and error messages set up correctly, image descriptions applied consistently across the whole site. Remediation brings a broken site into compliance. A new build means there's nothing to remediate because it was never broken to begin with. It also costs less: building correctly from the start is cheaper than building it wrong and then paying again to fix it.

See all frequently asked questions →

Related guides & services

Want to know exactly where your site stands before committing to anything?

Send the URL and I'll run an automated scan, test keyboard navigation by hand, check for the violations that trigger demand letters, and tell you precisely what's broken and what fixing it costs — before you decide anything.

Request a free accessibility review