European Accessibility Act Checklist for Apps

Q: Is this a full EAA or WCAG audit?

No. This checklist covers the WCAG basics that are mechanically checkable in your HTML — language, title, alt text, form labels, and zoom. Full WCAG conformance also requires human review of contrast, keyboard operation, headings, media captions, and more. Passing the basics is a meaningful first pass, not a complete audit.

The European Accessibility Act (EAA) extends accessibility obligations to a broad range of consumer-facing digital products and services sold into the EU — e-commerce, many mobile and web apps, and the websites that support them. If you are a solo developer or a small store owner who happens to have customers in the EU, the EAA can reach you even though it was not written with "indie" in mind. The intimidating part is that the law points to detailed technical standards (built on WCAG) that read like a full-time audit project.

This checklist makes that smaller and concrete. It focuses on the mechanically checkable basics — the handful of accessibility signals that live right in your HTML, that an automated scan can confirm, and that an auditor or a frustrated assistive-technology user would notice first. These basics are not full WCAG conformance, and ticking them does not "make your app accessible." But they are the cheapest gaps to close before launch, and each one maps to a LaunchTrust detector you can re-run any time.

What the EAA expects (in plain terms)

The EAA is an EU directive transposed into national law across member states, aimed at making specified products and services usable by people with disabilities. For digital services in scope, conformance is commonly demonstrated against WCAG-aligned criteria (the Web Content Accessibility Guidelines), referenced through the EU's harmonised standard for ICT accessibility. We deliberately avoid quoting a single date or article number here: enforcement runs through each member state's transposition, scope and exemptions vary (very small "microenterprises" providing services may be treated differently), and those details are easy to misquote. Confirm how the EAA applies to your specific product and country against the official text or a qualified source.

What matters for a launching indie: WCAG is the practical yardstick. If your public surfaces fail basic, well-known WCAG success criteria, you have an accessibility gap regardless of how the EAA's scope is finally read for your product. The items below are exactly those basics.

Who this checklist is for

E-commerce sites and storefronts selling to EU customers.
Web apps, SaaS landing pages, and waitlist/onboarding flows with EU users.
Mobile apps whose marketing site, account pages, or support pages are public on the web (the web surfaces are what an automated scan and a casual reviewer reach first).

If EU customers can reach your checkout, sign-up, or product pages, treat these basics as launch-time items rather than "someday" cleanup.

The mechanically-checkable EAA basics checklist

Work through these before you point EU traffic at your site. Each item is something you can confirm in your own HTML, and the linked detector reports whether the signal is present on your public surface. These five cover the WCAG basics that are realistically machine-detectable — they are a starting point, not the whole standard.

The page declares its language with a root <html lang="…"> attribute, so screen readers pick the right pronunciation and voice. → maps to HTML lang attribute · WCAG 3.1.1 (Language of Page)
Every page has a real, non-empty <title> — not the template default like Vite App — because the title is the first thing a screen reader announces and the label browsers put on tabs. → maps to page title · WCAG 2.4.2 (Page Titled)
Informative images carry alt text, and purely decorative images use an intentional empty alt="" so assistive tech skips them. → maps to image alt text · WCAG 1.1.1 (Non-text Content)
Form inputs have accessible labels — a <label>, aria-label, or aria-labelledby — so a screen-reader user hears the field's purpose instead of just "edit text." → maps to form input labels · WCAG 3.3.2 (Labels or Instructions)
Zoom is not disabled in the viewport meta tag, so low-vision users can enlarge content to at least 200%. → maps to viewport zoom · WCAG 1.4.4 (Resize Text)

These five are the spine of a pre-submission pass. The items below are equally important under WCAG but generally need a human or a full accessibility tool, not a passive HTML scan:

Sufficient color contrast between text and background (WCAG 1.4.3) — check with a contrast tool, since it depends on rendered styles.
Full keyboard operability — every control reachable and usable without a mouse, with a visible focus indicator (WCAG 2.1.1, 2.4.7).
A logical heading structure (<h1>…<h2>…) and meaningful link text, so navigation by landmarks makes sense.
Captions and transcripts for video and audio content (WCAG 1.2.x).
An accessibility statement describing how you meet accessibility expectations and how users can report problems — increasingly expected for in-scope services.

If you can confirm the first five (the scannable basics) and have a plan for the human-reviewed ones, you have addressed the parts of the EAA most likely to trip a typical indie site at launch.

What LaunchTrust checks for this framework

LaunchTrust does not assess "EAA compliance" and produces no accessibility score — no scanner can. What it does is surface the observable signals an accessibility reviewer would look for first, by fetching your public page and inspecting the served HTML:

HTML lang attribute (a11y_lang) — reports detected when the <html> tag carries a language value, not detected when it is absent.
Page title (a11y_title) — detected when a non-empty <title> is in the served HTML; not detected when it is missing or empty.
Image alt text (a11y_img_alt) — detected when every <img> carries an alt attribute (including a valid empty one), not detected when one or more have none, and tells you how many.
Form input labels (a11y_form_labels) — a lenient count comparing labelable inputs against <label> and ARIA-labeled inputs; detected when labels plausibly cover every input.
Viewport zoom (a11y_viewport_zoom) — detected when the viewport tag does not block zoom; not detected when it sets user-scalable=no or caps maximum-scale below 2.

Each result is a signal, not a judgment. "Detected" means the attribute or element is present in the HTML — it does not confirm the value is correct, the wording is meaningful, or that the page conforms to WCAG or the EAA. For example, the alt-text check sees alt="image123.png" as "detected" even though that description is useless, and the lang check sees lang="en" as "detected" even on a page written in German. Use detected as "the basics are present," then review quality yourself.

A "not detected" result means the wanted signal is missing — not that you have broken a law. And several detectors can report unable to determine when the page cannot be fetched, or when content is injected only by client-side JavaScript a plain fetch does not run.

A concrete example

The same gaps that fail WCAG basics are the ones the scanner flags. In plain markup:

<!-- Not detected on three checks at once -->
<html>                              <!-- no lang attribute -->
  <head>
    <title>Vite App</title>        <!-- template default, but still "detected" -->
    <meta name="viewport"
          content="width=device-width, user-scalable=no">  <!-- zoom blocked -->
  </head>
  <body>
    <img src="/hero.jpg">          <!-- no alt attribute -->
    <input type="email">           <!-- no label -->
  </body>
</html>

The accessible-basics version flips each signal:

<html lang="en">
  <head><title>Acme Checkout — Secure Payment</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
  </head>
  <body>
    <img src="/hero.jpg" alt="Customer completing a purchase on a phone">
    <label for="email">Email address</label>
    <input id="email" type="email">
  </body>
</html>

How to address EAA basics

Add lang to your root <html> tag — one line, e.g. <html lang="en">. See HTML lang attribute.
Give every page a real, descriptive <title> and remove any starter-template default. See page title.
Audit every <img>: write a useful alt for informative images and alt="" for decorative ones; wire the alt field into your CMS or component so new images cannot ship without it. See image alt text.
Label every form field with a <label for="…"> or an aria-label; never leave an input nameless. See form input labels.
Remove user-scalable=no and any maximum-scale below 2 from your viewport tag so users can zoom. See viewport zoom.
Plan the human-reviewed items — color contrast, keyboard operability, headings, captions, and an accessibility statement — since a passive HTML scan cannot confirm those.
Re-scan and confirm the five basic signals read detected, then verify the experience yourself with a keyboard and a screen reader (VoiceOver or NVDA) on a logged-out page.

Check this in 30 seconds

Paste your URL into the free LaunchTrust scanner. It fetches your live page and reports, item by item, whether your page language, title, image alt text, form labels, and zoom signals are detected, not detected, or unable to determine — so you can close the WCAG basics behind the EAA before a customer, an auditor, or an app reviewer hits them. The scan is passive, reads only the public HTML your visitors get, and never crawls private pages. Treat it as a fast first pass, not a full WCAG audit.

FAQ

Is this a full EAA or WCAG audit? No. This checklist covers the WCAG basics that are mechanically checkable in your HTML — language, title, alt text, form labels, and zoom. Full WCAG conformance also requires human review of contrast, keyboard operation, headings, media captions, and more. Passing the basics is a meaningful first pass, not a complete audit.

Does the EAA apply to my small app? It depends on what you sell, to whom, and how each member state transposed the directive — and some very small service providers may be treated differently. If you have EU customers and a public storefront or app, the safe posture is to address the WCAG basics now and confirm your specific obligations against the official text or a qualified source. See the European Union overview.

Does a "detected" result mean my app is accessible or EAA-ready? No — it surfaces a signal, not a verdict. LaunchTrust is a compliance aid, not legal advice or certification, and it produces no accessibility score. "Detected" means the attribute or element is present in your HTML; it does not prove the value is correct or that your site meets WCAG or the EAA. Use it to find gaps, then confirm conformance with a qualified professional.

Why did the scan miss accessibility issues I know exist? The scan reads the served HTML and does not run JavaScript or evaluate rendered styles. It cannot judge color contrast, keyboard focus, the quality of your alt text, or content injected client-side. Those need a human reviewer or a full accessibility testing tool — the scan catches the structural basics quickly so you can spend your review time on the rest.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.