Guides / Prompting and shipping
How to Make Your Website Accessible: A WCAG 2.2 Starter Guide
Make your website usable by everyone: semantic HTML, keyboard access, contrast, alt text, forms and focus, checked against WCAG 2.2 AA, with a checklist.
Mythex Team · · 6 min read
To make a website accessible, build it so people can use it with a keyboard, a screen reader, zoom or a switch device as well as a mouse: use real HTML elements for buttons, links, headings and form labels, give images meaningful alt text, keep text contrast high and make focus visible. The standard to aim for is WCAG 2.2 Level AA. Automated checkers catch part of the problem; a ten-minute keyboard and screen reader test catches much of the rest.
What "accessible" means in practice
Accessibility is about people: someone who is blind and uses a screen reader, someone with a tremor who navigates by keyboard, someone with low vision who zooms to 200%, someone reading in bright sunlight, someone with a temporary broken wrist. Good accessibility tends to make a site better for everyone — clearer structure, readable text, forms that explain their errors.
The reference standard is the W3C's Web Content Accessibility Guidelines (WCAG). As of September 2026, the current version is WCAG 2.2 (published October 2023, updated December 2024); WCAG 3 is an early draft. WCAG is organised around four principles — content must be perceivable, operable, understandable and robust — and has three conformance levels:
| Level | What it means | Who aims for it |
|---|---|---|
| A | The minimum; without it, some people cannot use the site at all | Everyone |
| AA | The common target; covers contrast, focus, resizing, error handling | Most organisations and many laws |
| AAA | The strictest; not achievable for all content | Specific services and audiences |
Laws in several places reference WCAG — for example the European Accessibility Act, which has applied to many consumer-facing digital services in the EU since June 2025. Which rules apply to you depends on where you operate and what you sell; check with an adviser if you are unsure. This guide covers the practical work.
Options: how to get there
| Approach | Good for | Trade-off |
|---|---|---|
| Build it in from the start | New sites and apps | Least effort overall; needs saying up front |
| Audit and fix | Existing sites | Finds real issues; takes a focused pass per page |
| Professional audit | Regulated sectors, large sites, public bodies | Thorough and documented; costs money |
| Overlay widget | Not recommended | Cannot fix the underlying code |
For most small sites the first two are enough: tell the AI to build accessibly from the start, then audit before launch.
The fixes that matter most
Use the right HTML elements
Most accessibility comes free with correct HTML. A <button> is focusable, works with Enter and Space, and is announced as a button. A <div> with a click handler is none of those. AI-generated code sometimes uses styled divs for everything; ask for semantic elements:
<button>for actions,<a href>for navigation- One
<h1>per page, then<h2>,<h3>in order — screen reader users jump between headings - Landmarks:
<header>,<nav>,<main>,<footer> <label>connected to every form field- The page's language in
<html lang="en">
Use ARIA attributes only when no native element fits — for a custom tab set or combobox, say. Wrong ARIA is worse than none.
Keyboard access and visible focus
Everything you can do with a mouse must work with the keyboard alone (WCAG 2.1.1). Press Tab through the page: every link, button and field should be reachable in a logical order, and you should always see where focus is (2.4.7 Focus Visible). WCAG 2.2 added that the focused element must not be completely hidden behind sticky headers or cookie banners (2.4.11, Level AA).
Common failures: menus that open only on hover, modals that don't trap focus or can't be closed with Escape, and outline: none in the CSS with nothing to replace it.
Text alternatives
Every meaningful image needs alt text that says what it shows in context ("Chef plating the tasting menu", not "image1.jpg"). Decorative images get an empty alt="" so screen readers skip them. Icon-only buttons need an accessible name ("Close", "Search"). Videos need captions; audio needs a transcript.
Colour and contrast
WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (1.4.3), and 3:1 for interface parts such as input borders and meaningful icons (1.4.11). Light-grey placeholder text and pale buttons are the usual failures. Also, never use colour alone to carry meaning — a red border on an invalid field needs an error message too.
Resizing and reflow
Text must stay usable when zoomed to 200% (1.4.4), and content must work at a width of 320 CSS pixels without scrolling sideways (1.4.10). A properly responsive layout handles most of this.
Targets, forms and errors
- Target size: WCAG 2.2 AA asks for pointer targets of at least 24 by 24 CSS pixels, or enough spacing around smaller ones (2.5.8). Bigger is kinder on phones.
- Forms: visible labels (not placeholder-only), clear instructions, and error messages that say what is wrong and how to fix it, next to the field.
- Login: don't make people solve a puzzle or transcribe a code without an alternative; allow password managers and pasting (3.3.8 Accessible Authentication).
Prompts that work
Build this site to meet WCAG 2.2 Level AA: semantic HTML landmarks, one h1 per page with headings in order, real button and link elements, labels on every form field, visible focus styles, text contrast of at least 4.5:1, alt text on meaningful images and alt="" on decorative ones, and html lang set.
Audit the /signup and /checkout pages for accessibility. Check keyboard-only use, focus order, visible focus, labels, error messages, contrast and screen reader names for icon buttons. List each problem with the WCAG criterion, then fix them without changing the visual design more than needed.
The mobile menu can't be used with a keyboard. Make it a button with aria-expanded, move focus into the menu when it opens, close it with Escape and return focus to the button.
Step by step
- Run an automated check. Lighthouse's Accessibility section in Chrome DevTools, or the axe browser extension, on each main page. Fix everything it reports.
- Unplug the mouse. Tab through each page and complete every key task — sign up, search, check out. Note anything you can't reach, can't see focus on, or can't escape from.
- Zoom to 200% and narrow the window to phone width. Nothing should be cut off or need sideways scrolling.
- Try a screen reader for ten minutes: VoiceOver on Mac and iPhone, TalkBack on Android, or NVDA on Windows (free). Listen to headings, links and form fields. "Button" with no name, or "link, click here", means work to do.
- Check contrast for text, buttons and inputs with a contrast checker.
- Fix, then retest the same tasks.
- Publish an accessibility statement saying what standard you aim for and how to report problems — and answer those reports.
Common mistakes
- Relying on an overlay widget instead of fixing the code.
- Removing focus outlines because they look untidy, with no replacement.
- Placeholder text as the only label. It disappears when someone starts typing and is often low contrast.
- "Click here" and "Read more" links. Out of context, screen reader users hear a list of identical links.
- Alt text stuffed with keywords. Alt text is for people; describe the image.
- Testing once. Every new feature can break keyboard access. Add a keyboard pass to your pre-launch testing.
Accessibility checklist
- Automated check (Lighthouse or axe) clean on main pages
- Every task can be completed with the keyboard alone
- Focus always visible and never hidden behind sticky elements
- Semantic headings, landmarks, buttons and links;
langset - Meaningful alt text; decorative images
alt=""; captions on video - Text contrast ≥ 4.5:1 (large text ≥ 3:1); UI parts ≥ 3:1
- Works at 200% zoom and 320 px width
- Every form field has a visible label and clear error messages
- Accessibility statement with a way to report problems
For the concepts behind this, read what is web accessibility. Accessible design and good design overlap a lot; how to design a good-looking app with AI covers the visual side.
Accessibility on Mythex
Mythex builds with whatever standard you ask for, so put "WCAG 2.2 AA" in your first prompt and in follow-ups. You can use Preview's phone-size frame to check small screens (Preview and Code), but keyboard, zoom and screen reader tests work best on the published URL or a preview opened in its own tab. Ask the agent to audit a page, fix what it finds, then test the fixes yourself — an automated pass is a start, not a sign-off.
Questions
What is the current accessibility standard for websites?
As of September 2026, the current W3C standard is WCAG 2.2, first published in October 2023. Most organisations and many laws aim for Level AA. WCAG 3 is still an early draft.
Can an accessibility overlay make my site compliant?
Don't rely on one. Overlays add a toolbar on top of the page but cannot fix missing labels, broken keyboard access or poor structure in the underlying code. Fixing the site itself is what makes it usable.
Do automated checkers find every problem?
No. Tools like Lighthouse and axe catch things such as missing alt text, low contrast and unlabelled fields, but many issues — confusing focus order, meaningless link text, alt text that is present but wrong — need a person to check with a keyboard and a screen reader.
What contrast ratio does WCAG require?
WCAG 2.2 Level AA asks for at least 4.5:1 for normal text and 3:1 for large text, and 3:1 for user interface components such as input borders and icons that convey meaning.