A website accessibility checklist makes sure people with disabilities can use your site: every function works with a keyboard, focus is always visible, text has sufficient contrast, images have meaningful alt text, forms have labels and clear errors, headings are structured, motion can be reduced, and the site works with screen readers. WCAG 2.2 level AA is the usual benchmark.
Accessibility is part of how I define “finished” on a project, alongside speed and security. This guide supports my landing page structure pillar, because an inaccessible page also converts worse for everyone.
What does website accessibility mean?
It means people with visual, hearing, motor or cognitive disabilities can perceive, understand, navigate and interact with the site, including with assistive technologies such as screen readers, screen magnifiers, voice control and keyboard-only navigation. WCAG organises this into four principles: perceivable, operable, understandable and robust.
Who benefits, beyond the people you’re thinking of
Accessibility work is usually framed around permanent disabilities: blindness, deafness, limited mobility, cognitive differences. But the improvements reach a much wider group. Captions help people watching in a noisy clinic waiting room or a shared office. High contrast helps anyone reading a phone screen in strong daylight. Keyboard access helps someone with an injured wrist using the mouse with their other hand, and larger target sizes help everyone with a phone held over a rough road. WCAG itself recognises this range of permanent, temporary and situational limitations, which is why accessibility is best treated as general usability for a much wider slice of your audience, not a special mini-project for a small group.
Why it matters for business
- More people can use and buy from your site.
- Many accessibility fixes (clear labels, contrast, structure) also improve conversion and SEO.
- Legal requirements are growing; the European Accessibility Act covers e-commerce from 28 June 2025, and other regions have their own rules.
What WCAG 2.2 conformance levels mean
WCAG success criteria are sorted into three levels. Level A covers the essentials a user with a disability largely cannot work around, such as keyboard access and text alternatives for meaningful images. Level AA removes the common practical barriers, including contrast minimums, visible focus, consistent navigation and focus not obscured, and it is the benchmark most laws, offers and procurement policies expect; it is where this checklist aims. Level AAA is stricter (higher contrast, limits on how fast content changes) and is rarely required in full; treat it as a goal for specific areas where it fits your audience. When a client or a tender document asks for “an accessible website”, agree explicitly on the level before design or development starts, so you build to a defined target instead of a vague one.
1. Keyboard access
- Every link, button, menu, form field and modal reachable with Tab.
- Logical tab order following the visual order.
- No keyboard traps; modals close with Escape and return focus.
- A “Skip to content” link as the first focusable element.
- Custom controls (sliders, tabs, accordions) work with keyboard keys as expected.
2. Visible focus
- Focus indicator clearly visible on all interactive elements.
- Focus not hidden behind sticky headers or cookie banners (a WCAG 2.2 criterion: Focus Not Obscured).
Removing outlines for mouse clicks while keeping them for keyboard users:
a:focus:not(:focus-visible),
button:focus:not(:focus-visible) { outline: none; }
a:focus-visible,
button:focus-visible {
outline: 3px solid var(--focus, #0ea5a4);
outline-offset: 3px;
}
This keeps the site tidy for mouse users without breaking keyboard navigation.
3. Colour and contrast
- Normal text contrast at least 4.5:1; large text at least 3:1.
- UI components and meaningful graphics at least 3:1 against adjacent colours.
- Information never conveyed by colour alone (errors need text, links in body text need underline or another cue).
- Both light and dark modes checked if the site has them.
4. Images and media
- Informative images have alt text describing their purpose.
- Decorative images have empty alt (
alt=""). - Logos’ alt text is the company name.
- Images of text avoided; where used, the text is in the alt.
- Videos have captions; audio has transcripts.
- No autoplaying media with sound.
5. Structure and semantics
- One
h1per page and a logical heading order. - Landmarks:
header,nav,main,footer. - Lists marked up as lists, tables as tables with headers.
langattribute set onhtml, and on passages in another language;dir="rtl"for Arabic.- Links with descriptive text, not “click here.”
- Buttons are
buttonelements, links areaelements.
6. Forms
- Every field has a visible label connected to the input.
- Required fields indicated in text, not only by colour or asterisk.
- Errors identified in text, next to the field, and announced to screen readers.
- Input purposes identified with
autocompletewhere applicable. - No cognitive puzzles required to log in or submit (WCAG 2.2: Accessible Authentication), or an alternative is provided.
See contact form best practices.
7. Target size and touch
- Interactive targets at least 24×24 CSS pixels or with enough spacing (WCAG 2.2 Target Size Minimum, AA).
- Drag interactions have a single-pointer alternative (WCAG 2.2: Dragging Movements).
Covered in more depth in the mobile-first design checklist.
8. Motion and timing
- Respect reduced motion preferences:
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
- Carousels can be paused; nothing flashes more than three times a second.
- Time limits can be extended or are not used.
- Scroll-driven effects never hide content from users who disable motion.
9. Zoom and reflow
- Page usable at 200% zoom and at 320 CSS pixel width without two-dimensional scrolling.
- User zoom not disabled in the viewport meta tag.
- Text spacing can be increased without content overlapping.
10. Dynamic content
- Modals use proper roles and manage focus.
- Status messages (added to cart, form sent) announced via live regions.
- Menus expose
aria-expandedstate.
Documents: PDFs, downloads and files
Business sites often move the problem into files: a PDF price list, an application form, a report. A file can be as much of a barrier as a broken page. Name files descriptively instead of final_v3.pdf, state the format in the link text itself (“Download the onboarding form (PDF)”), and for documents you control, check that they contain real text — not just a scanned image — with tagged headings, a logical reading order and tables marked up as tables. If a document is meant to be filled in or is updated often, a regular web page is nearly always the more accessible and more maintainable choice, and it stays easier to update than a file you have to regenerate.
Arabic and bilingual sites
For sites serving Egypt, the UAE or Saudi Arabia, accessibility also has a language dimension. Set lang="ar" and dir="rtl" on Arabic pages so screen readers use the right voice and navigation order; mirroring the layout with CSS alone is not enough, because it does not tell assistive technology which language is running. A passage in another language should carry its own lang attribute so the reader switches correctly. Choose a legible Arabic web font rather than stretching a Latin one, check that decorative icons do not become confusing when the layout mirrors, and run the Arabic version through the same keyboard and screen-reader passes as the English one. A bilingual site is only accessible if both language versions are.
How to test
- Automated scan: WAVE, axe DevTools or Lighthouse on key templates. Fix all clear errors.
- Keyboard pass: put the mouse away and complete key tasks.
- Screen reader pass: VoiceOver on macOS/iOS, NVDA on Windows, TalkBack on Android. Navigate by headings and landmarks, fill a form.
- Zoom and reflow: 200% zoom and a narrow window.
- Real users: if possible, test with people who use assistive technology daily.
Automated tools catch only a portion of issues; manual testing finds the rest.
If you can only improve a few things first
- Take your five most visited pages — usually the homepage, main service pages and the contact page — and make them fully keyboard-usable with visible focus.
- Fix the contrast of your main text, links and buttons, in both themes if you have two.
- Add alt text to meaningful images on those pages, and mark the decorative ones with empty alt.
- Label every field on every form, state errors in text next to the field, and confirm the submission state is announced.
- Run your key flows through one screen reader: navigate by headings, fill the form, submit it, and listen to what comes back.
Don’t try to fix the whole site in one pass. Prioritise by how many people and tasks each barrier affects, verify every fix manually rather than trusting the scanner, and then fold accessibility checks into your normal QA so regressions are caught where they were introduced.
About overlay widgets
Accessibility overlay plugins add a toolbar but cannot fix missing labels, keyboard traps or poor structure in the underlying code. Many disabled users and experts criticise them. Fix the source instead.
Common mistakes
- Removing focus outlines entirely.
- Icon-only buttons without accessible names.
- Placeholder text used as labels.
- Low-contrast grey text for “elegance.”
- Animations that cannot be turned off.
If you want an accessibility review of your site with prioritised fixes, contact me. It pairs well with a technical SEO audit.
Frequently asked questions
What is WCAG 2.2?
The Web Content Accessibility Guidelines 2.2 are a W3C Recommendation published in October 2023. They build on WCAG 2.1 and add criteria such as focus not obscured, target size minimum and accessible authentication.
Is website accessibility a legal requirement?
It depends on where you operate and who you serve. For example, the European Accessibility Act applies to many consumer products and services, including e-commerce, from 28 June 2025. Check the rules that apply to your business.
Can an accessibility overlay plugin make my site compliant?
Overlay widgets cannot fix underlying code problems such as missing labels or keyboard traps, and many accessibility experts advise against relying on them. Fix the site itself.
What is the best free website accessibility checker?
Tools such as WAVE, axe DevTools and Lighthouse's accessibility audit are widely used. Use them together with manual keyboard and screen reader checks, since automated tools miss many issues.
