Accessibility

WCAG-aligned rules so people of all abilities can use the site.

20 topics in this category.

Colour contrast
Required

Text and meaningful non-text elements must have enough contrast against their background so people with low vision and people in harsh light can read them.
Image alt text
Required

Every <img> element must have an alt attribute. The value describes the image's purpose to screen readers, search engines, and anyone whose image fails to load.
Form labels
Required

Every form control needs a programmatically associated label. A placeholder is not a label, and an unlabelled input is unusable for screen-reader and voice-control users.
Keyboard navigation
Required

Every interactive element on the page must be reachable and operable with a keyboard alone, in a logical order, with no traps that hold focus.
Visible focus indicators
Required

Whenever a control receives keyboard focus, the page must show a clear, high-contrast indicator. Removing focus outlines without a replacement is a top accessibility failure.
Skip links
Recommended

A 'skip to main content' link as the first focusable element lets keyboard and screen-reader users jump past repeated navigation on every page.
Semantic HTML and landmarks
Required

Use the right HTML element for the job. Landmarks like <header>, <nav>, <main>, and <footer> let assistive technologies announce structure and skip between regions.
ARIA — first rule of ARIA
Recommended

ARIA can make custom widgets accessible, but the first rule of ARIA is don't use ARIA. Reach for a native HTML element first; add ARIA only when nothing native fits.
Descriptive link text
Required

Every link's text must describe where it goes. 'Click here' and 'read more' fail screen-reader users who scan a page by jumping from link to link.
Empty links and buttons
Avoid

A link or button with no accessible name is invisible to screen readers and unreachable for voice control. Icon-only controls without a label are the usual culprit.
Accessible form errors
Required

When a form submission fails, errors must be identified in text, associated with the input that caused them, and announced to assistive technology.
Document and parts language
Required

Set the page's primary language on <html lang> and mark any inline content in a different language with its own lang attribute, so screen readers pronounce it correctly.
Reduced motion
Required

Respect the user's `prefers-reduced-motion` setting. Decorative animation, parallax, and autoplay can trigger vestibular distress, migraines, and seizures.
Accessibility overlays
Avoid

Third-party JavaScript widgets that claim to make a site WCAG-compliant at runtime. They do not work, often harm screen-reader users, and attract lawsuits.
Captions and transcripts
Required

Video needs synchronised captions, audio-only content needs a transcript, and visuals that carry meaning need audio description. Auto-captions alone are not enough.
Accessible data tables
Required

Tabular data must use real <table> markup with a caption, header cells, and scope attributes so screen readers can announce row and column relationships.
Touch target size
Required

Interactive controls must be large enough to tap or click reliably. WCAG 2.2 sets a 24×24 CSS px minimum, with 44×44 CSS px as the enhanced target.
Hidden until found
Recommended

Use hidden="until-found" (or content-visibility: hidden) for collapsible content so that browser find-in-page, assistive tech, and search engines can still reach the text and auto-expand it.
Native interactive elements
Recommended

Prefer native HTML interactive elements — <button>, <a>, <details>/<summary>, <dialog> — over divs with click handlers. You get keyboard support, focus management, and assistive-tech semantics for free.
CSS state and relational selectors
Recommended

Use `:has()` together with `:user-invalid`, `:user-valid`, `:placeholder-shown` and `:focus-within` to express form and component state in CSS, removing the JavaScript class-toggling pattern and the race conditions it brings.