Use the checklist as a starting point, not a compliance claim.
WCAG 2.2 provides testable success criteria across different levels of conformance. It covers a much wider range of needs than colour contrast and image descriptions alone.
Automated tools can find some technical failures, but they cannot judge every label, reading order, focus path, error message or piece of alternative text. Useful testing combines tools, keyboard checks, screen-reader checks where appropriate and human review.
What should an accessible business website include?
An accessible website uses semantic structure, readable content, keyboard-operable controls, visible focus, sufficient contrast, useful text alternatives, clear labels and errors, adaptable layouts, controlled motion and consistent navigation. It also needs human testing against the journeys and content people actually use.
Make the content understandable without relying on appearance.
A page should preserve its meaning when zoomed, read aloud, restyled or used without seeing its decorative treatment.
Use semantic headings
Give the page one descriptive H1, then nest sections in a logical order. Do not choose heading levels for their visual size.
Write useful link text
Describe the destination or action. Repeated links labelled only 'click here' become difficult to distinguish when read out of visual context.
Provide text alternatives
Describe the purpose of meaningful images. Leave purely decorative images empty to avoid adding noise. Complex charts may need an adjacent text explanation.
Keep instructions independent of colour
Do not rely only on colour, shape or position to identify an error or required action. Pair visual signals with words and programmatic meaning.
Use plain, specific language
Short labels and direct instructions reduce interpretation. Explain uncommon terms and keep the next action consistent with the words on the control.
Make every essential journey work with a keyboard.
A person should be able to reach, understand and operate interactive controls without being trapped or losing track of focus.
Preserve visible focus
Interactive elements need a clear focus indicator that is not hidden behind sticky headers, cookie notices or modal overlays.
Follow a logical focus order
Keyboard movement should follow the reading and task sequence. Visual rearrangement must not create a surprising DOM order.
Use native controls where possible
Links, buttons, fields and headings carry established keyboard and assistive-technology behaviour. Custom controls need the same states and interaction support.
Label forms and errors
Every input needs a persistent, programmatically connected label. Errors should identify the field, explain the problem and preserve entered data where practical.
Offer adequate targets
Controls need enough size and spacing to reduce accidental activation, especially on touch screens and for people with limited fine motor control.
Protect readability across real screens and preferences.
Responsive design includes zoom, text spacing, contrast and reduced-motion preferences, not only a narrower layout.
Check colour contrast
Test text, controls, icons and focus indicators against their actual backgrounds, including hover, disabled, error and dark-mode states.
Support zoom and reflow
Content should remain usable at high zoom without forcing two-dimensional scrolling for ordinary reading. Avoid fixed-height text containers that clip larger type.
Respect reduced motion
Remove or reduce non-essential animation when the user's operating system requests it. Do not make critical information depend on movement.
Keep touch and desktop states complete
Information revealed only on hover can disappear on touch devices. Provide equivalent focus and tap behaviour without requiring precision.
Test at content extremes
Long names, validation messages, translated text and increased spacing expose clipping that short placeholder content hides.
A practical accessibility testing route.
No single tool can confirm accessibility. Use overlapping checks and record findings against the real task being tested.
Automated scan
Find detectable issues such as missing names, invalid relationships and some contrast failures. Review false positives and gaps.
Keyboard pass
Complete each important journey using only Tab, Shift+Tab, Enter, Space, arrow keys and Escape where expected.
Zoom and reflow
Check larger text, browser zoom, narrow viewports and text-spacing changes for clipping or lost controls.
Screen-reader review
Check landmarks, headings, names, states, errors and reading order with suitable screen-reader and browser combinations.
Content review
Judge whether headings, links, labels, alternative text, instructions and errors make sense to a person.
User testing
Include disabled people where the service risk and audience justify it; real use exposes barriers that conformance checks can miss.
Sources and further reading.
These primary sources inform the guidance above. Your project may need additional legal, security or accessibility advice for its own context.
Web Content Accessibility Guidelines (WCAG) 2.2
W3C: The current W3C Recommendation defining testable success criteria for more accessible web content.
WCAG 2 Overview
W3C Web Accessibility Initiative: An introduction to WCAG versions, supporting documents and the relationship between principles, guidelines and success criteria.
Put accessibility into the definition of done.
We can plan semantic content, responsive behaviour and interaction states as part of the website build, with a testing route matched to the service and its risk.
Accessibility questions.
Is WCAG 2.2 a legal requirement for every UK business website?
Legal duties depend on the organisation, service and context. WCAG is a widely used technical standard, but this guide is not legal advice and a checklist does not establish legal compliance. Seek qualified advice for your specific obligations.
Can an automated accessibility checker prove a website is compliant?
No. Automated tools can identify some code and contrast issues, but many criteria need human judgement. Labels, reading order, keyboard behaviour, error recovery and the quality of text alternatives need manual review.
What is the difference between WCAG A, AA and AAA?
WCAG groups success criteria into three conformance levels: A, AA and AAA. Each higher level includes the levels below. W3C notes that Level AAA is not recommended as a general policy for entire sites because some content cannot satisfy every AAA criterion.
When should accessibility testing happen?
Start during content, design and component work, then test complete journeys before launch and after meaningful changes. Testing only at the end turns structural barriers into expensive rework.