Stage 6: Accessibility

The short answer

Accessibility means people with disabilities can use your app: people who use a keyboard instead of a mouse, a screen reader instead of their eyes, or larger text and higher contrast. The working standard is WCAG at level AA. Build to it, test with free tools, and then test by hand, because the tools only find part of the problems. In the US, websites that fail get sued thousands of times a year, and in the EU some consumer services now have a legal duty.

Why this matters

• Thousands of federal suits a year. Seyfarth Shaw, a law firm that tracks these cases, counted 3,117 website accessibility lawsuits in US federal court in 2025. That is up 27% from 2,452 in 2024. It is not a record: there were 3,255 in 2022. Website cases were 36% of all 8,667 federal ADA Title III suits in 2025, and 1,021 were filed in New York federal courts (Seyfarth Shaw ADA Title III blog). These counts are federal only, so the real number is higher. Other trackers that add state courts report roughly 4,000 to 5,000, but I could only reach those figures through summaries, so treat them as rough.
• The EU now has a law for some digital services. The European Accessibility Act is an EU directive, which is a law each EU country writes into its own law. Countries had to apply it from 2025-06-28 (Directive 2019/882, Article 31). It covers consumer services such as e-commerce, banking, e-books, passenger transport and telephony (European Commission).
• Public buyers will ask. The US Department of Justice (DOJ) requires state and local governments to meet WCAG 2.1 AA on their websites and apps. Large ones now have until 2027-04-26 (ADA.gov). If you sell to a school district or a city, expect them to ask your product for the same.
• A real gap on a real site. When I checked ducktate.com, the homepage had a language tag, alt text on all six images, reduced-motion rules and visible focus outlines. It also had no skip link, no main landmark, and no accessibility test in the repo. Contrast was not measured and nobody had done a keyboard walk. Those gaps are still open as of 2026-10-09. A site can look careful and still miss the basics.

Core concepts

WCAG, levels, and which version to build to

WCAG stands for Web Content Accessibility Guidelines. It is the standard from the W3C, the group that writes web standards. It is a list of success criteria, which are testable rules, each with a number such as 1.4.3. Each rule has a level: A is the minimum, AA is the level laws and courts point to, and AAA is the highest.

Two versions matter now:

• WCAG 2.1 is a W3C Recommendation, with a current edition dated 2025-05-06 (WCAG 2.1). The DOJ rule for public bodies requires 2.1 AA.
• WCAG 2.2 is a W3C Recommendation dated 2024-12-12 (WCAG 2.2). It adds new rules on top of 2.1, so if you meet 2.2 AA you also meet 2.1 AA.

The new rules in 2.2 at levels A and AA:

My advice: build to WCAG 2.2 AA. It covers 2.1 AA, which is what courts and buyers usually use, and it adds rules that matter on phones.

The four basics that catch most people

You do not need to learn every rule before launch. Start with these, from the W3C text and its quick reference:

1. Text alternatives (1.1.1, level A). Every image or icon that carries meaning has a text alternative with the same purpose. On the web that is the alt attribute. A screen reader reads it aloud.
2. Keyboard (2.1.1, level A). Everything works from a keyboard. Try it: put your mouse away and press Tab through the page.
3. Contrast (1.4.3, level AA). Normal text has a contrast ratio of at least 4.5:1 against its background. Large text, which is 18 point, or 14 point bold, needs at least 3:1.
4. Labels on form fields. Every input has a visible label that says what to type. A grey placeholder that disappears when you type is not a label. See the quick reference for the exact rule wording.

Worked example. Your sign-up form has an email field with only a placeholder, an icon-only "show password" button, light grey text on white, and a "Create account" button made from a div. A screen reader user hears "edit text, button, button". A keyboard user cannot reach the div. Here is the fix in code:

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<button type="button" aria-label="Show password">
  <svg aria-hidden="true">...</svg>
</button>

<button type="submit">Create account</button>

A real <label>, a real <button>, and a text name for the icon. Then darken the grey text until a contrast checker says 4.5:1 or more.

A screen reader is software that reads the screen aloud and lets people move through it by keyboard or gestures. Your phone and computer have one built in: VoiceOver on Apple devices, TalkBack on Android, and Narrator on Windows. Five minutes with one teaches more than an hour of reading.

Which laws reach a small app

This is where people get confused. Here is the short map.

US, private businesses (ADA Title III). The ADA is the Americans with Disabilities Act. Title III covers businesses open to the public. It has no technical rule for websites. In practice, courts and plaintiffs use WCAG 2.1 AA as the benchmark (Seyfarth Shaw ADA Title III blog). That is practice, not a statute, but it is why the suit numbers above matter to you.

US, public bodies (ADA Title II). Title II covers state and local governments, not private apps. The DOJ rule from April 2024 requires WCAG 2.1 AA. In April 2026 the DOJ pushed the dates back one year (ADA.gov):

This rule does not bind you directly. It binds your customer, if your customer is a public body, and they will pass the duty on to you in the contract.

EU (European Accessibility Act). The Act covers certain consumer products and services, such as e-commerce, banking and e-books. It has an exemption that matters to most solo founders: microenterprises that provide services are exempt from the service rules (Article 4(5)). A microenterprise has fewer than 10 people AND either yearly turnover of no more than EUR 2 million or a balance sheet total of no more than EUR 2 million (Article 3(23)). The exemption covers services only, not products. Each EU country writes the Act into its own law, and I did not check those national laws, so details can differ. I read the Directive on a UK government copy of the EU text as adopted.

Worked example. You are two people, with EUR 300,000 a year in revenue, and you run an online shop for EU buyers. E-commerce is a covered service, but you are a microenterprise, so the service rules of the Act do not bind you. You still face US suit risk if you sell to US buyers, and a shop that a keyboard user cannot check out of loses sales. The exemption ends when you reach 10 people, or when both your turnover and your balance sheet pass EUR 2 million. Build to AA now and you will not need a rebuild then.

Why the free tools are not enough

Three free tools find many problems fast:

• axe DevTools from Deque, which Deque describes as a free browser extension (axe DevTools). I did not check its pricing page.
• WAVE from WebAIM, a browser extension and web service (WAVE).
• Lighthouse, built into Chrome's developer tools, which gives an accessibility score along with other checks (Lighthouse).

These are automated tools: they scan the page code for rule breaks a machine can detect, such as a missing alt or low contrast. They cannot judge whether the alt text makes sense, whether the tab order is logical, or whether a screen reader user can finish your checkout. I did not find a reliable public figure for the share of problems they catch, so I will not give one. Assume they miss a lot.

So the test has three parts:

1. Run axe or WAVE on every key page: home, sign-up, login, the main screen, settings, checkout.
2. Do a keyboard-only pass: unplug the mouse, use Tab, Shift+Tab, Enter, Space and Escape, and complete each key task. You must always see where you are.
3. Do a screen reader pass: turn on VoiceOver or NVDA and complete sign-up with your eyes closed, or with the screen covered.

Write down what fails and fix it before launch. Then publish a short accessibility statement: a page that says which standard you aim for, what you know is not yet right, and how people can tell you about a problem.

Key terms

The checklist

• Pick WCAG 2.2 level AA as your target and write it in your project notes so your agent builds to it.Must doSource: WCAG 2.2, WCAG 2.1
• Give every meaningful image and icon button a text alternative, and mark decorative images so screen readers skip them.Must doSource: WCAG 2.2 quick reference
• Give every form field a visible label that stays when the user types, not only a placeholder.Must doSource: WCAG 2.2 quick reference
• Make every task work with a keyboard alone, with a visible focus outline that sticky headers and popups do not cover.Must doSource: WCAG 2.2, WCAG 2.2 quick reference
• Check text contrast and fix anything below 4.5:1 for normal text or 3:1 for large text.Must doSource: WCAG 2.2 quick reference
• Check your app against the six rules WCAG 2.2 added: focus not obscured, dragging, target size, consistent help, redundant entry and accessible login.Should doSource: WCAG 2.2
• Run axe, WAVE or Lighthouse on every key page and fix what they report.Must doSource: axe DevTools, WAVE, Lighthouse
• Do a keyboard-only pass and a screen reader pass through sign-up, login and your main task, because automated tools miss many problems.Must doSource: WCAG 2.2 quick reference, WAVE
• Publish an accessibility statement with your target standard, known gaps and a way to report problems.Should doSource: Seyfarth Shaw on 2025 filings
• If you sell a covered consumer service to EU buyers, check whether you are above the microenterprise limits, and if so meet the European Accessibility Act.If it appliesSource: Directive 2019/882 Article 4, Article 3 definitions, European Commission
• If you sell to schools, cities or other public bodies in the US, be ready to show WCAG 2.1 AA conformance before their 2027 and 2028 deadlines.If it appliesSource: ADA.gov web rule first steps
• Add an automated accessibility check to your tests so new pages do not slip back.Should doSource: axe DevTools, Lighthouse

The prompt for your agent

Copy this into Claude Code, Codex or Cursor from the root of your project. Then do the keyboard and screen reader passes yourself: an agent reading code cannot feel what a user feels.

Audit this project for Stage 6 of a launch checklist: accessibility, target
WCAG 2.2 level AA.
Do not change any code, styles, or copy until I approve a plan.

For each item below, report PASS, FAIL, or UNKNOWN, with the file and line that
proves it. If you cannot prove an item from the code, report UNKNOWN. Never report
PASS without evidence. List every failing instance, not only the first.

1. Images and icons: does every meaningful <img>, SVG icon, and icon-only button
   have a text alternative (alt, aria-label, or visible text)? Are decorative
   images marked so screen readers skip them (alt="" or aria-hidden)?
2. Forms: does every input, select, and textarea have a programmatic label
   (<label for>, aria-label, or aria-labelledby)? Flag any field that relies on a
   placeholder only.
3. Keyboard: flag any click handler on a non-interactive element (div, span) with
   no keyboard support, any tabindex greater than 0, and any outline: none or
   outline: 0 without a visible replacement focus style.
4. Focus: can sticky headers, cookie banners, or popups cover the focused item?
   Do modals trap focus while open and return it when closed?
5. Contrast: list text and background color pairs from the styles. Compute the
   ratio where you can and flag any below 4.5:1 (normal text) or 3:1 (large
   text). Report UNKNOWN where colors are set at runtime.
6. Page structure: does each page set a lang attribute, have one main landmark,
   a logical heading order, and a skip link?
7. Dragging and targets: does any action require dragging with no single-tap
   alternative? Are any touch targets very small?
8. Login: does login block password managers or paste, or rely on a puzzle?
9. Is there an automated accessibility test (axe, Lighthouse CI, or similar) in
   the test suite? Is there an accessibility statement page?

End with a table: item, status, evidence (file and line), and the smallest fix you
suggest. Then stop and wait for my approval.

Common mistakes

• Running one Lighthouse scan, getting a high score, and calling the app accessible. The score only covers what a machine can check.
• Installing an "accessibility overlay" widget instead of fixing the page. The standard measures your page, and a widget on top does not change the code underneath.
• Using placeholders as labels because the design looks cleaner.
• Removing focus outlines with outline: none and adding nothing back.
• Building buttons from div elements that a keyboard cannot reach.
• Quoting the lawsuit numbers wrong. The 3,117 figure is federal only, and 2022 was higher.
• Assuming the DOJ Title II dates apply to a private app. They apply to public bodies, and reach you only if they are your customers.

Check yourself

Resources

• W3C: WCAG 2.2GuidanceFree

  The current standard, with every rule and its level.

• W3C: How to Meet WCAG (quick reference)GuidanceFree

  Every rule with plain techniques and examples, filterable by level.

• W3C: WCAG 2.1GuidanceFree

  The version the DOJ rule and many contracts name.

• Seyfarth Shaw: 2025 federal website accessibility filingsResearchFree

  The 3,117 count, its trend and its limits.

• ADA.gov: first steps for the web ruleGuidanceFree

  The DOJ rule for public bodies and its current deadlines.

• European Accessibility Act, Article 4LawFree

  The requirements and the microenterprise exemption for services.

• European Commission: European Accessibility ActGuidanceFree

  Which products and services the Act covers.

• axe DevToolsToolFree

  A browser extension that scans a page for accessibility rule breaks.

• WAVEToolFree

  Shows accessibility problems drawn on top of your page.

• LighthouseToolFree

  Chrome's built-in audit, including an accessibility score.

Next stage

Everyone can now use your app. Stage 7 looks at the AI features inside your app: when you must tell people they are talking to an AI, and what you owe them when their data goes to a model provider.