Most of your images have no alt text

You built the app with Lovable, Bolt, v0, or Replit. The hero image, the feature icons, the product photos, the team headshots: the AI wrote <img src="..."> for every one of them and stopped there. A screen reader user gets the filename or silence. That is the single most cited defect in website accessibility demand letters, because a bot can count it, and the letters are sent by the thousands.

Why this matters more than it feels like it should

Courts have treated public facing websites of businesses as places of public accommodation under Title III of the Americans with Disabilities Act, and several thousand web accessibility suits are filed in federal court every year, plus far more demand letters that never become suits. The plaintiff firms work from automated scans, and missing alt text is the first line of every report those scans produce. The ADA itself gives plaintiffs attorney fees and an injunction, not damages, which is why these cases are so often filed in California: the state's Unruh Civil Rights Act adds statutory damages of $4,000 per violation for California residents, and New York has its own equivalent. Typical settlements land in the five figures.

The standard everyone measures against is WCAG 2.1 level AA. Its very first criterion, 1.1.1, is that every non-text element has a text alternative. You do not need to read the rest of it to fix this page.

Separate from the law: alt text is what Google reads for image search and what shows when an image fails to load. Fixing it is free SEO.

Count them in thirty seconds

1. Open your deployed app, open the browser developer tools (right click, Inspect), and go to the Console tab.
2. Paste this and press Enter:

   [...document.images].filter(i => !i.hasAttribute('alt')).length + ' of ' + document.images.length + ' images have no alt attribute'

3. Do the same on your two or three busiest pages. If more than a handful are missing on any page, or more than half overall, you are in the group the scanners flag.
4. Also check icons and logos that the AI rendered as SVG or as CSS background images: those need a text label a different way (see below), but the console line will not count them.

The fix, about an hour

1. Decide which images mean something. A product photo, a chart, a screenshot, a logo that acts as a link, a team headshot: these carry information and need a real description. A decorative gradient, a divider, a background flourish: these carry nothing and should be explicitly marked as such so screen readers skip them.
2. Write short, specific alt text for the meaningful ones. One sentence that says what the image shows in context. "Dashboard showing weekly sales by region" beats "dashboard" and far beats "image". Do not start with "image of" or "picture of"; the screen reader already says that. Do not stuff keywords.
3. Mark decorative images as decorative. That means alt="", an empty string, on purpose. An empty alt is correct for decoration; a missing alt is the defect. For CSS background images nothing is needed. For decorative inline SVGs add aria-hidden="true".
4. Handle images that are links or buttons. A logo that links home needs alt text saying where it goes ("Home") not what it looks like. An icon button with no visible label needs aria-label="Close" or similar on the button itself.
5. Let the builder do the typing. This prompt does most of the work in Lovable, Bolt, or v0: "Go through every img element in the app. For each image that conveys information, add a concise descriptive alt attribute based on where it is used. For purely decorative images add alt="". For inline SVG icons that are decorative add aria-hidden="true". For icon-only buttons add an aria-label. Do not change any layout." Then re-run the console line and spot check that the descriptions are true, because the AI will guess when it cannot see the image.
6. Uploaded content needs a rule too. If users upload images (avatars, listings), make the upload form ask for a short description, or set a sensible default alt from the listing title. Otherwise every new upload reopens the gap.

While you are in there: the other things the scans count

The same automated reports that count alt text also count these, and each is a few minutes: every form input needs an associated label (not just placeholder text); the page needs a lang attribute on the html element; link text should say where it goes ("View pricing", not "click here"); text on colored backgrounds needs enough contrast (a 4.5 to 1 ratio for normal text; the browser's Inspect panel shows the ratio when you hover a color); and the whole page should be usable with the Tab key alone, with a visible focus outline. AI builders get some of these right by default and miss others at random.

Do not do this

Do not install an "accessibility overlay" widget that promises to make the site compliant with one script tag. Plaintiff firms sue sites with overlays at the same rate, the overlays are named in complaints, and the Federal Trade Commission has already acted against one vendor for compliance claims. Fixing the markup is cheaper and actually works. And do not set every alt to the page title or the company name; that is counted as a defect too.

Related exposure the same audience ships

An app with no alt text usually shipped without a privacy policy, and often with an analytics pixel firing before consent. Both are their own demand letter categories with their own guides: no privacy policy and pixel before consent. All three are visible from the outside in seconds, which is how small apps get found.

Not sure what your app is exposing?