Alt text is the short written description a browser exposes to screen readers and assistive technology when an image can't be seen. For a launching indie developer or a store owner, it's one of the cheapest accessibility signals to get right and one of the most commonly missed. A landing page, a product gallery, or a marketing site full of <img> tags with no alt attribute is invisible to a blind or low-vision visitor, and that gap is increasingly something regulators and platforms expect you to have addressed.
LaunchTrust looks at this passively, on your own public pages, and reports what it sees as a signal — not as a pass-or-fail judgment of your site's accessibility.
What LaunchTrust checks
The image alt text detector (internally a11y_img_alt) inspects the HTML your page actually serves. It does not render the page, run scripts, or evaluate how good your descriptions read. Concretely, it:
- Finds every
<img>element in the page markup. - Counts how many of those tags carry an
alt=attribute. It looks for a realaltattribute on the tag — adata-altor similar custom attribute does not count. - Compares the two numbers.
The result you get back is one of three signals:
- Detected — every
<img>on the page carries analtattribute, or the page has no<img>elements at all. An emptyalt=""counts as present here, because an empty alt is the valid, intentional way to mark a purely decorative image so assistive tech skips it. - Not detected — one or more images have no
altattribute at all. The signal notes how many: for example, "3 of 12 images have no alt attribute," and references WCAG success criterion 1.1.1 (Non-text Content). Severity is reported as medium. - Unable to determine — the detector couldn't fetch or read the page HTML (for instance, the URL didn't return inspectable markup), so it makes no claim either way.
This is a "positive" signal: the presence of alt attributes is the thing you want to see. A "not detected" result means the wanted signal is missing, not that you've broken a law.
One honest limitation worth stating: the check measures presence of the attribute, not the quality of the description. alt="image123.png" will read as detected even though it's a poor description. Use this signal as a prompt to review, not as proof your alt text is meaningful.
Why it matters
Accessible images map directly to well-established expectations:
- WCAG 1.1.1 (Non-text Content) is the foundational rule that informative images need a text alternative. It's the most widely referenced accessibility criterion, and most regional accessibility laws lean on WCAG as their technical baseline.
- The European Accessibility Act (EAA) brings accessibility obligations to a broad range of consumer-facing digital products and e-commerce services sold in the EU. Where it applies, conformance is commonly demonstrated against WCAG-aligned criteria, of which text alternatives for images are a core part.
For an e-commerce store, missing alt text on product photos is both an accessibility gap and a discoverability one — search engines also lean on alt text to understand images. Addressing it tends to help two goals at once.
A concrete example
Here's the difference the detector is looking for, in plain markup:
<!-- Not detected: no alt attribute at all -->
<img src="/hero.jpg">
<!-- Detected: informative image with a real description -->
<img src="/hero.jpg" alt="A runner checking a fitness app on their phone">
<!-- Detected: decorative image intentionally hidden from assistive tech -->
<img src="/divider.svg" alt="">
All three are valid HTML in a browser. Only the first one produces a "not detected" signal, because the alt attribute is entirely absent.
How to address it
- Audit every
<img>on your public pages. Open the page source and search for<img. Each occurrence needs a decision: is this image informative, or decorative? - Write a real description for informative images. Describe what the image conveys in context, not the file. Aim for a concise phrase a listener would find useful — e.g.
alt="Invoice screen showing a paid status". - Use empty alt for decorative images. Spacers, background flourishes, and purely visual dividers should use
alt=""so screen readers skip them rather than announcing a filename. - Don't rely on
data-altortitleas a substitute. The detector — and assistive technology — looks for the standardaltattribute. A custom data attribute won't satisfy either. - Wire alt into your templates and CMS. If images come from a component or product feed, make the alt field required at the source so new images can't ship without one.
- Re-check after changes. Accessibility regressions are easy to reintroduce when a redesign or a new section lands.
Check this in 30 seconds
You don't have to read your own source by hand. Paste your site URL into the free LaunchTrust scanner and it will report, page by page, whether every image carries an alt attribute — and exactly how many are missing if not. It's a fast way to catch the gap before a review, an audit, or a customer hits it. The scan is passive and runs only on the public surfaces you point it at.
FAQ
Does a "detected" result mean my images are accessible? No. Detected means each image has an alt attribute present, including valid empty ones for decorative images. It does not check whether the description is accurate or useful. Treat detected as "the attribute exists," then review the wording yourself.
Is an empty alt="" a problem? Not on its own. An empty alt is the correct, intentional way to tell assistive technology that an image is decorative and should be skipped. The detector treats it as present. The mistake to avoid is leaving the attribute off entirely, which forces screen readers to guess — often by reading the filename.
Does passing this check satisfy the EAA or WCAG? No — it surfaces a signal, not a verdict. LaunchTrust is a compliance aid, not legal advice or certification. The image alt text check tells you whether an attribute is present on your public pages; it does not prove your site meets the EAA, WCAG, or any other standard. Use it to find gaps, then confirm your obligations with a qualified professional.
Why did the scan say "no img elements" but I can see images? Some sites inject images with JavaScript or CSS backgrounds rather than <img> tags in the served HTML. The detector reads the markup the page returns and does not execute scripts, so client-rendered or CSS background images won't be counted as <img> elements. Those images may still need accessible alternatives by other means.
Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.