Fix the most common accessibility gaps
Alt text, form labels, keyboard use, visible focus, contrast and the newer WCAG 2.2 rules such as target size and accessible sign-in.
Skip to the promptWho needs this
- You sell to consumers in the EU (the European Accessibility Act applies to e-commerce and many consumer services since 28 June 2025; micro-enterprises with fewer than 10 staff and no more than €2 million turnover are exempt for services).
- You operate in the US, where websites are regularly sued under the ADA, or in places like California and Ontario with their own accessibility laws.
- You want everyone, including keyboard and screen reader users, to be able to use your product.
Why it matters
- WCAG 2.2 level AA is the standard most laws point to, directly or in practice: the European Accessibility Act through the EN 301 549 standard, ADA lawsuits and settlements in the US, and laws such as California's Unruh Act and Ontario's AODA.
- A few problems cause most failures: missing alt text, unlabeled form fields, poor contrast, missing focus outlines and things that only work with a mouse.
- WCAG 2.2 added rules people often miss: targets at least 24 by 24 pixels, focus not hidden behind sticky headers, alternatives to dragging, and sign-in that doesn't rely on memory or puzzles.
Before you paste
- Your brand colours (hex values), since contrast fixes may need slightly darker shades.
- The two or three flows that matter most (sign-up, checkout, the main feature) to test first.
The prompt
Copy it into your AI builder. Fill in anything in [brackets] first, and review every change before you ship it.
Fix the most common accessibility problems in this app to WCAG 2.2 level AA. Go through every page and component. 1. STRUCTURE - Set the page language (lang attribute on html). - One h1 per page and headings in order (h2, h3), not chosen for their size. - Use semantic elements (button, a, nav, main, header, footer) instead of clickable divs. Add a "Skip to content" link as the first focusable element. 2. IMAGES AND ICONS - Meaningful images get alt text that says what they show or do; decorative images get alt="". - Icon-only buttons and links get an accessible name (aria-label or visually hidden text). 3. FORMS - Every input, select and textarea has a visible label tied to it; placeholders are not labels. - Errors are shown in text next to the field, announced to screen readers (aria-live or aria-describedby), and don't rely on colour alone. - Don't ask for information already given in the same process (redundant entry). - Sign-in: allow pasting passwords and password managers, and don't use puzzles or memory tests as the only way in (offer email links or passkeys as alternatives). 4. KEYBOARD AND FOCUS - Everything clickable works with Tab, Shift+Tab, Enter, Space and Escape, in a sensible order, with no keyboard traps. - A clearly visible focus outline on every interactive element (at least as visible as the browser default). Don't remove outlines without a replacement. - Focused elements must not be hidden behind sticky headers, footers or cookie banners. - Dialogs: move focus into them when they open, keep it inside while open, return it when closed, and close on Escape. - Anything done by dragging (sliders, reordering, maps) also works with simple clicks or taps. 5. COLOUR AND SIZE - Text contrast at least 4.5:1 (3:1 for large text, icons and input borders). List any brand colours that fail and suggest the closest passing shade. - Click and tap targets at least 24 by 24 CSS pixels, or with enough space around them. - The layout works at 200% zoom and at 320 pixels wide without horizontal scrolling. 6. MOTION AND MEDIA - Respect prefers-reduced-motion for animations; nothing flashes more than three times a second. - Videos have captions; auto-playing media can be paused. 7. ACCESSIBILITY STATEMENT - Add a short page: the standard you aim for, known issues, and how to report a problem. When you're done: list every file you changed, explain each change in one line, and give me a step-by-step test for each numbered item above. Don't change anything unrelated.
Builder tips
Lovable
Ask Lovable to fix the shared components (Button, Input, Dialog) first. Fixing them once fixes every screen that uses them.
Cursor
Install the axe DevTools browser extension, paste its findings into the chat, and ask Cursor to fix them one component at a time.
Claude Code
Start in plan mode (Shift+Tab) so you approve the plan before any file changes, then let it run the checks it lists.
Common mistakes
- outline: none in a global CSS reset with no replacement focus style.
- Placeholder text used as the only label.
- Clickable divs and spans that keyboards can't reach.
- Cookie banners and sticky headers covering the focused element.
- Blocking paste in password fields.
Check it worked
- 1Put the mouse away and complete sign-up and the main flow with the keyboard only. You should always see where focus is.
- 2Run Lighthouse (DevTools → Lighthouse → Accessibility) and the axe DevTools extension on your main pages. Fix every failure they list; then test by hand, since tools catch only part of the problems.
- 3Zoom the browser to 200%: nothing overlaps or needs sideways scrolling.
- 4Turn on VoiceOver (Cmd+F5 on a Mac) or NVDA (Windows) and complete one form by listening.
- 5Check text colours in a contrast checker against WCAG AA.
What a SafeLaunch scan adds
SafeLaunch tests your pages against WCAG 2.2 AA and maps each failure to the accessibility law of each market you sell in.
One free fix in your inbox each week
A new copy-paste prompt for Lovable, Cursor or Claude Code every week, with the rule behind it and how to check it worked. No spam, unsubscribe in one click.
By signing up you agree to get this weekly email. We send it with Kit, and you can unsubscribe at any time. What we share with Kit is in our privacy notice.
Questions
Sources
General guidance for common problems, not legal advice. Whether a rule applies depends on where you operate, who your users are and the size of your business.