Accessibility basics for your web app: where to start

An accessible web app is one that people can use with a keyboard alone, with a screen reader, with zoomed-in text and without relying on colour, which in practice means real buttons and links, labelled form fields, visible focus, enough contrast and dialogs that manage focus properly. The usual reference is WCAG 2.2 at level AA. You can find most problems in an AI-built app in about half an hour of testing, and the fixes are usually small changes to components you reuse everywhere, so fixing one component fixes many screens.

This guide covers who this affects and why it matters, the problems that show up most often in apps made with Lovable, Bolt, v0 or Cursor, a quick test you can run yourself, the fixes, and how to keep it from regressing.

Why does accessibility matter for a small app?

Some of your users navigate with a keyboard because of a motor disability or just preference, use a screen reader because they're blind or have low vision, zoom the page to 200%, or are colour-blind. Many more are temporarily in a similar situation: a broken arm, bright sunlight on a phone, a noisy room. An app they can't use is an app they leave.

There's also a legal side. This is a plain-language overview, not legal advice, so check with a lawyer about your situation:

• In the EU, the European Accessibility Act has applied since 28 June 2025 to a range of products and consumer-facing services, including e-commerce and some banking and transport services. Microenterprises providing services (fewer than 10 people and annual turnover or balance sheet of no more than €2 million) are exempt from the service requirements, but exemptions are read narrowly.
• In the US, websites and apps have been the subject of many lawsuits under the Americans with Disabilities Act, and public bodies have specific web accessibility rules.
• Public-sector and enterprise customers often ask for accessibility conformance information during procurement.

WCAG 2.2 became a W3C Recommendation in October 2023 and is the version most new requirements point to.

What accessibility problems do AI-built apps usually have?

AI tools often start from component libraries built on accessible primitives, which helps. The problems appear in the custom parts and in the details:

1. Clickable divs. A card or row with onClick but no button or link role can't be reached with the Tab key or activated with Enter.
2. Icon-only buttons with no name. A trash-can icon reads as "button" to a screen reader, with no hint of what it does.
3. Inputs labelled only by placeholder text, which disappears as soon as you type and is often too faint to read.
4. Pale grey text on white for secondary information, below the required contrast.
5. Focus outlines removed with outline: none because they "looked ugly", leaving keyboard users lost.
6. Custom modals and dropdowns that don't move focus into the dialog, don't close with Escape, and let Tab wander behind them.
7. Status shown only by colour, such as a red or green dot with no text.
8. Error and success messages that appear visually but are never announced to screen readers.
9. Password fields that block pasting, which breaks password managers.

How can I test my app in 30 minutes?

1. Keyboard only (10 minutes)

Put the mouse away. Use Tab and Shift+Tab to move, Enter and Space to activate, Escape to close, and arrow keys inside menus. Go through sign-up, the main task in your app and settings. Write down anywhere you can't reach something, can't see where you are, or get stuck.

2. Zoom and contrast (5 minutes)

Zoom the browser to 200%. Content should reflow without overlapping or forcing sideways scrolling on normal pages. Then run Lighthouse's accessibility audit or the axe DevTools extension on your main screens; both flag contrast failures, missing labels and missing alt text.

3. Screen reader (15 minutes)

On a Mac, turn on VoiceOver with Command+F5. On Windows, NVDA is free. Try to complete one task with your eyes closed or the screen dimmed. Listen to what each button announces and whether errors are read out.

Automated tools find a useful share of problems but not all of them. Keyboard and screen reader checks catch the rest, especially in flows like checkout or onboarding.

What are the fixes that matter most?

Use real elements. A link that goes somewhere is an <a href>; an action is a <button>. You get focus, keyboard support and the right announcement for free.

Name every icon button:

<button type="button" aria-label="Delete invoice" onClick={onDelete}>
  <TrashIcon aria-hidden="true" />
</button>

Label every input with a visible label connected to it:

<label htmlFor="email">Work email</label>
<input id="email" type="email" autoComplete="email" />

Meet contrast ratios. WCAG AA asks for at least 4.5:1 for normal text and 3:1 for large text and for important interface elements like input borders and focus indicators.

Show focus. If you remove the default outline, replace it with a clear :focus-visible style.

Make targets big enough. WCAG 2.2 adds a minimum target size of 24 by 24 CSS pixels for most controls, or enough spacing around smaller ones.

Announce changes. Put form errors next to the field and connect them with aria-describedby; use a polite live region (aria-live="polite") for toasts and status messages.

Use the library's dialog. If your project includes Radix, shadcn/ui or a similar library, use its dialog, menu and popover components rather than hand-built ones; they handle focus and Escape.

Allow paste and autofill in login forms. WCAG 2.2's accessible authentication criterion is about not forcing people to remember or transcribe codes and passwords, and password managers are the usual way people meet it.

How do I stop it from coming back?

• Add eslint-plugin-jsx-a11y to the project, so common mistakes show up as warnings while you build.
• Fix the shared components (button, input, dialog, table) first, and tell your AI tool to reuse them instead of generating new ones.
• Add a keyboard pass to your release checklist for the main flows.
• Include accessibility in the instructions you give your AI tool, for example "every interactive element must be a button or link with an accessible name". Our guide to reviewing AI-generated code has more on checking what the tool produces.

Quick answers

Is an accessibility overlay widget enough? No. Overlays don't fix the underlying markup, and many screen reader users report that they get in the way. Fix the components.

What WCAG level should I aim for? Level AA of WCAG 2.2 is the common target for commercial apps and what most rules refer to.

Does accessibility help SEO? Indirectly. Proper headings, link text and alt text help search engines understand pages, and the same habits help with SEO for React single-page apps.

How long does fixing take? It depends on how many custom components the app has. Fixing shared components first usually covers most screens quickly.

Want an expert pass?

If you'd like someone to test and fix the main flows, our maintenance and support plans include this kind of work, and custom software development covers rebuilding components properly. The free health check is a quick place to start, or get in touch. W3C's summary of what's new in WCAG 2.2 lists the newest requirements.