Web Accessibility Checklist for HTML (WCAG Basics)

Around one in six people worldwide lives with a significant disability, and many more have temporary or situational limitations — a broken arm, bright sunlight on a phone screen, a noisy train. Accessible websites work for all of them. The good news: most accessibility wins are basic HTML done right. Use this checklist on any site, WordPress or custom.

The POUR principles#

Content and structure#

• Set the page language: <html lang="en"> (or hi, mr, etc.).
• One descriptive H1; headings in logical order without skipping levels — see headings and lists.
• Use landmarks: header, nav, main, footer — see semantic HTML.
• Write descriptive page titles and link text (“Download the pricing PDF”, not “Click here”).
• Use real lists and tables with headers.
• Keep language plain; explain jargon or link to definitions (like the SEO Library).

Images and media#

• Informative images have meaningful alt text; decorative images have alt="".
• Charts and infographics have a text summary of the key data.
• Videos have accurate captions; audio has a transcript.
• No auto-playing audio; auto-playing video can be paused.
• Avoid text inside images.

Colour and visual design#

• Text contrast at least 4.5:1 (3:1 for large text and UI components) — check in both light and dark mode.
• Don’t rely on colour alone: error fields need text or icons, links in paragraphs need underlines or another cue.
• Text can be resized to 200% without breaking the layout.
• Respect prefers-reduced-motion for animations.

Keyboard and focus#

• Every interactive element can be reached and used with Tab, Shift+Tab, Enter and Space.
• Focus is always visible — never outline: none without a replacement style.
• A “Skip to content” link is the first focusable item.
• Menus, modals and chat widgets trap focus while open and return it when closed; Escape closes them.
• Use <button> for actions and <a href> for navigation.

Forms#

• Each input has a visible, connected <label>.
• Required fields are indicated in text, not just with colour or an asterisk.
• Error messages explain what went wrong and how to fix it, and are announced to screen readers.
• Captchas have an alternative (this site offers WhatsApp contact as a fallback).

Details in HTML forms best practices.

ARIA: use sparingly#

The first rule of ARIA is: don’t use ARIA if a native HTML element does the job. A <button> beats <div role="button" tabindex="0"> every time. Use ARIA to fill gaps — aria-label on icon-only buttons, aria-expanded on menu toggles, aria-live for chat or status messages.

How to test#

1. Automated: Lighthouse (Chrome DevTools), axe DevTools or WAVE catch roughly a third of issues.
2. Keyboard: unplug the mouse and complete key tasks — navigate, search, submit the contact form.
3. Screen reader: try NVDA (Windows, free), VoiceOver (Mac/iPhone) or TalkBack (Android) on your main pages.
4. Zoom: zoom to 200% and check nothing overlaps or disappears.
5. Real users: if possible, ask people who use assistive technology for feedback.