The demand letter is written by a robot

For decades Title III of the Americans with Disabilities Act was read literally: a ramp to the entrance, braille signage, an accessible restroom. All of it about buildings. The break came when federal courts placed a commercial website alongside a place of public accommodation.

The consequence is plain and hard. If a site sells goods, takes bookings or simply hands information to a general audience, it owes access to people with visual, hearing, motor and cognitive impairments. That duty did not arrive with a new statute; it arrived with a reading of the old one, and it landed at once on everybody already online.

What followed was a difference in the cost of inspection. Complaining about the shop on the corner takes a person: travel there, walk in, measure, record. Complaining about a website takes nothing but a machine that never sleeps. Law firms living on high-volume filings saw it before anyone else.

The result is measurable: over recent years Title III claims tied to inaccessible websites have risen by more than three hundred per cent. Almost nobody was spared — retail, hospitality, finance, healthcare and small local operators. And the warning shot is rarely a customer complaint. It is a formal pre-litigation letter demanding payment, usually somewhere between ten and fifty thousand dollars, with a federal suit offered as the alternative.

What the crawler actually looks for

A bot does not judge convenience. It checks four things, every one of them visible in the markup. First, an image with no alternative description: with no text attribute a screen reader cannot tell a blind visitor what the picture shows. Second, an input field with no label bound to it — a search box, a contact form, a newsletter signup.

The third is arithmetic: the standard asks ordinary text to differ from its background by a contrast ratio of at least four and a half to one, and stylesheets are checked by calculation. The fourth is the keyboard: someone with a motor impairment moves through a page by tab and enter, and if a menu will not open that way or an order will not confirm, there is no compliance. All four come from the international WCAG guidance, version 2.1, level AA.

After that no lawyer is involved. Software pulls the domain owner's registration details, drops them into a prepared complaint template and prints the demand. One firm turns out hundreds of these a week, and the marginal cost of each approaches nothing.

Having received the letter, an owner looks for a quick way out and finds it as a third-party JavaScript plugin, usually a circle in the corner of the screen. The promise is perfect: paste one line of code and artificial intelligence brings the site into full compliance.

Technically this is makeup rather than repair. The underlying HTML and CSS stay as they were; the overlay lives in the visitor's browser and tries to rebuild the page's object model on the fly. A surface layer copes with the simple and fails at the complex: dynamic menus, modal windows and the checkout cart stay opaque to assistive software.

Worse, the overlay gets in the way of the very people it was bought for. Blind users do not navigate through a panel bolted onto a site. They use their own configured software — JAWS, NVDA, VoiceOver. Widgets clash with it and seize keyboard control, which is why so many of those panels are switched off or blocked outright.

Why the patch attracts a filing

The central paradox is legal. A widget is visible in page source at a glance, and plaintiff scanners are tuned for exactly such sites. For the filing side it is a ready argument: the owner knew about the problem and chose a cheap overlay instead of a fix. Many American courts have already held widgets insufficient, and companies running them have lost hundreds of cases.

The side costs arrive as a bonus. A heavy third-party script slows the page and damages Core Web Vitals, so the effect on search results is neutral at best and negative at worst.

The alternative is described as the AIfa Shield package from the AIfa Works studio, and it is built the opposite way round: the source itself is edited. The first floor is meaningful markup. Faceless containers give way to tags that state their own purpose — header, navigation, main region, section, footer. Headings form a strict ladder from the first level down to the sixth. Buttons are buttons and links are links, and keyboard focus starts working by default, without a line written to support it.

The second floor is ARIA for elements with no standard equivalent. Purpose is spoken aloud through labels and bindings to a description, the state of a collapsible list is exposed as expanded or collapsed, and purely decorative icons are hidden from reading so the listener is not worn down by noise.

The third floor is operation without a mouse. Focus travels in a sensible order, a link to the main content sits at the very top so menus need not be heard on every page, the active element is highlighted clearly and with contrast, and a modal window always has an exit on the escape key. Traps the keyboard cannot leave must not exist.

The fourth floor is colour. Contrast is recalculated across every text element and brought to what the standard asks: four and a half to one for ordinary text, three to one for large headings. That addresses not only blindness but low vision and colour blindness as well.

Accessibility is easy to achieve and just as easy to lose on the next release. So the article describes two standing mechanisms rather than one edit. Server rendering in Next.js 14 delivers finished semantic markup immediately, to the screen reader and the search crawler alike; nobody waits for the browser to assemble the page.

The second mechanism matters more. Automated checking is wired into the build pipeline: an accessibility error stops the build, and the code never reaches the production server. That moves accessibility out of the promise column and into the release conditions. And unlike an overlay, which adds weight, cleaning the code removes it, which shows up in load time and in the Lighthouse score.

The spend pays back in more than silence from plaintiffs. Roughly fifteen per cent of the world's population lives with some form of health limitation — not a charitable footnote but a market segment an inaccessible site cuts off mechanically.

The second effect is technical. A search crawler reads a page much the way screen-reading software does: by semantic markup, alternative descriptions and heading structure. What is legible to one is legible to the other. The third effect is reputational, and it counts too: visible care about access works on trust.

Here it is important not to skip the caveat the article makes itself. In the comparison between overlay and native repair, the legal protection of the latter is called high — with an explicit qualifier: native accessibility reduces the risk of lawsuits rather than removing it altogether. The studio is described as aiming at level AA conformance, and the stated outcome is a substantial reduction in legal exposure.

That is the correct wording and it is worth remembering in exactly that shape. Conformance is a state of the code, not an indulgence: anyone may file at any time. The difference lies in what you answer with. A site with a widget answers with the widget, already held insufficient in court. A site with corrected markup answers with a build history in which every check passed before release.

The economics of a claim changed before the sites did. Inspection became free for the inspector while remediation stayed expensive for the owner, and the entire market in quick overlays grew inside that gap. An overlay closes the anxiety without closing the markup, and it flags the site as a convenient target on top of that.

The only answer that holds under load is a dull one: semantic tags, labels for non-standard elements, a working keyboard, honest contrast — and an automated check allowed to break the build.