In short
Accessibility means people with disabilities can perceive, operate, and understand your site. WCAG 2.2 Level AA is the standard most organisations are held to, and clients increasingly require it contractually. The highest-impact fixes are keyboard operability, visible focus states, sufficient colour contrast, properly labelled form fields, meaningful alt text, and correct heading structure — most of which cost nothing if done while building.
What the standard actually asks
WCAG organises requirements under four principles: content must be perceivable, interfaces operable, content understandable, and markup robust enough for assistive technology.
Most organisations are held to Level AA, which is the practical target. Clients increasingly write it into contracts, and 2.2 is now the current version — it added requirements around focus visibility, dragging alternatives, and not obscuring focused elements behind sticky headers.
You do not need to memorise the criteria. You need to fix the things that actually stop people.
The checklist, in order of impact
1. Everything works with a keyboard
The single highest-value check, and the easiest to run: put your mouse away and use the site with Tab, Shift+Tab, Enter, Space and arrow keys.
Can you reach every control? Can you activate them? Can you get out of a menu or modal? Does the order follow the visual layout?
The usual failures are custom controls built from divs with click handlers and no keyboard equivalent, and modals that let focus escape to the page behind. Both are common and both fully block some users.
2. Focus is visible
If you cannot see where you are, keyboard operability is theoretical. Removing focus outlines because they look untidy is the most damaging small decision in front-end work.
Style them instead. Use :focus-visible so a visible ring appears for keyboard users without showing on mouse clicks, and make sure it has contrast against its background. Under 2.2, a focused element must also not be hidden behind sticky headers or footers.
3. Colour contrast meets AA
Body text needs a contrast ratio of at least 4.5:1; large text at least 3:1; and interface components and meaningful graphics at least 3:1.
The usual offenders are light grey placeholder text, disabled states, and brand colours used for small text. Check them with any contrast tool — this takes minutes and is entirely objective.
Also: never use colour alone to convey meaning. A red field border needs an accompanying message.
4. Form fields are properly labelled
Every input needs a real <label> associated with it. Placeholder text is not a label — it disappears on typing and is usually too low-contrast.
Errors must be announced, not merely shown in red, and must say how to fix the problem. Group related fields with fieldset and legend. Where a field has a format requirement, state it before the person types, not after they get it wrong.
5. Images have appropriate alt text
Describe the function, not the file. A logo linking home is "Troiana, home". A decorative flourish takes alt="" so screen readers skip it. A chart needs the finding it conveys, not "chart".
Empty alt is correct and useful for decoration. Missing alt is not the same thing.
6. Headings describe structure
One h1 per page, then h2 and h3 in order, without skipping levels for visual reasons. Screen reader users navigate by heading, so a correct outline is genuine navigation, not markup hygiene.
If a heading looks wrong at the right level, fix it with CSS rather than by choosing a different tag.
7. Motion can be turned off
Respect prefers-reduced-motion and provide a still alternative for anything that animates significantly. Vestibular disorders make large parallax and auto-playing motion genuinely unpleasant, not merely distracting.
Nothing should flash more than three times per second.
8. Content is understandable
Write plainly. Expand abbreviations on first use. Make link text meaningful on its own — screen reader users often navigate by pulling up a list of links, where twelve entries reading "read more" are useless.
How to test without a specialist
Keyboard test. Free, five minutes, finds a surprising share of real problems.
Automated scanner. Browser extensions like axe or Lighthouse catch missing labels, contrast failures, and structural errors. Understand the limit: automated tools catch roughly a third of issues. They are a floor, not a pass.
Screen reader. Try VoiceOver on macOS or NVDA on Windows. You will be clumsy at first; that is fine. Ten minutes tells you whether your page is comprehensible without sight.
Zoom to 200%. Text must remain readable and nothing should be cut off or overlap.
Turn off CSS. If the content still makes sense in order, your structure is sound.
What this costs
Done during the build: very little. Semantic HTML, real labels, adequate contrast, and visible focus states are not extra work — they are the default, if the default is set correctly at the start.
Done afterwards: expensive, because custom controls have to be rebuilt and colour decisions unwound. This is the whole argument for treating it as a baseline rather than a feature.
Where to start on an existing site
Run the keyboard test on your three most important journeys — homepage to contact, the signup flow, the main product screen. Then run an automated scan for contrast and labels. Then fix what those two surface, in that order.
That is a day of work on most sites, and it removes the majority of issues that actually block people. Perfection can wait; being usable cannot.
If accessibility is now a contractual requirement and you need to know where you stand, book a call.
Common questions
What does WCAG 2.2 Level AA require?
That content is perceivable, operable, understandable and robust, at the middle of three conformance levels. In practice the criteria that matter most are keyboard operability, visible focus states, contrast of at least 4.5:1 for body text, properly labelled form fields, meaningful alt text, and a correct heading structure. Version 2.2 added requirements around focus visibility, alternatives to dragging, and not obscuring focused elements.
How do I test accessibility without specialist tools?
Four checks cover most of it. Use the site with only a keyboard and confirm you can reach, operate and escape everything. Run a free automated scanner such as axe or Lighthouse. Try a screen reader for ten minutes. And zoom to 200% to confirm nothing is cut off. Note that automated tools catch only around a third of issues.
What contrast ratio do I need?
At least 4.5:1 for body text, 3:1 for large text, and 3:1 for interface components and meaningful graphics. The usual failures are light grey placeholder text, disabled states, and brand colours used at small sizes. Never rely on colour alone to convey meaning.
Is placeholder text a substitute for a label?
No. Placeholder text disappears as soon as someone types, is usually too low in contrast, and is not reliably announced by assistive technology. Every input needs a real label element associated with it; a placeholder can supplement that but never replace it.
How much does accessibility work cost?
Very little if done while building — semantic HTML, real labels, adequate contrast and visible focus states are simply the correct defaults. It becomes expensive retrofitted, because custom controls have to be rebuilt and colour decisions unwound. On an existing site, one focused day on your three most important journeys removes most of the issues that actually block people.
