Accessibility
WCAG-aligned rules so people of all abilities can use the site.
28 topics in this category.
Colour contrast
RequiredText 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.
Automatic contrasting colour
OptionalLet the browser pick a legible black or white foreground for a dynamic background with the CSS contrast-color() function, instead of hard-coding colour pairs or computing luminance in JavaScript.
Forced colours mode
RecommendedRespect forced colours mode (Windows High Contrast and similar). The `forced-colors` media feature lets you repair UI the user's palette would otherwise flatten — without overriding their choice.
Image alt text
RequiredEvery <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
RequiredEvery 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
RequiredEvery 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
RequiredWhenever 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
RequiredA 'skip to main content' link as the first focusable element lets keyboard and screen-reader users jump past repeated navigation on every page.
The inert attribute
RecommendedWhen an overlay is open, the content behind it should be unreachable — not just dimmed. The inert attribute removes a subtree from tab order and the accessibility tree at once, replacing fragile focus-trap JavaScript.
Semantic HTML and landmarks
RequiredUse 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
RecommendedARIA 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
RequiredEvery 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
AvoidA 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
RequiredWhen a form submission fails, errors must be identified in text, associated with the input that caused them, and announced to assistive technology.
Accessible authentication
RecommendedLet people log in without solving a puzzle, transcribing a code, or memorising anything. Don't block password managers, allow paste, and offer a method that needs no cognitive function test.
Redundant entry
RecommendedDon't make people re-type information they already gave you in the same process. Auto-populate it, or let them pick it from what they entered a step ago.
Consistent help
RecommendedIf you offer help — a contact link, a phone number, a chat widget, an FAQ — put it in the same relative place on every page that has it. Moving it around is the failure.
Document and parts language
RequiredSet 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
RequiredRespect the user's `prefers-reduced-motion` setting. Decorative animation, parallax, and autoplay can trigger vestibular distress, migraines, and seizures.
Accessibility overlays
AvoidThird-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
RequiredVideo 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
RequiredTabular 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
RequiredInteractive 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.
Dragging movements
RecommendedAnything you can drag must also work with a single pointer that never drags. Sliders, sortable lists, and drag-to-pan maps each need a click or tap alternative.
Hidden until found
RecommendedUse hidden="until-found" for collapsible content so that browser find-in-page, assistive tech, and search engines can still reach the text and auto-expand it.
Mobile-friendly form inputs
RecommendedOn a phone, the right input type, inputmode, and enterkeyhint summon the correct on-screen keyboard and a useful Enter key. Keep input text at 16px or larger so iOS Safari doesn't zoom on focus.
Native interactive elements
RecommendedPrefer 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
RecommendedUse `: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.