Best practices

Concrete recommendations for accessible websites, grouped by topic — a checklist for design and development.

Color & contrast

Text and background need at least a 4.5:1 contrast ratio (3:1 for large text, 24px or 19px bold and up).
Never convey information through color alone (e.g. marking errors only in red) — add text, an icon, or a pattern too.
Check contrast on hover, focus, and placeholder text in form fields too, not just the default state.
Test with a contrast checker against the actual rendered background, not just the design mockup.

Informative images need meaningful alt text that describes their purpose, not just what's depicted.
Purely decorative images get an empty alt="" so screen readers skip them.
Videos need captions; audio content should have a transcript where possible.
For complex graphics (charts, infographics), also provide the content as text.

Every interactive element must be reachable via Tab and operable with Enter/Space.
Focus must always be visible — don't remove the default focus outline via CSS without providing an equally clear alternative.
Tab order should follow the page's visual/logical order.
A "skip to main content" link at the top saves keyboard users from tabbing through navigation on every page.
No keyboard traps: every component (e.g. a modal) must be exitable via keyboard.

Exactly one h1 per page, heading levels without gaps (h2 follows h1, not h2 straight to h4).
Structure page regions with semantic landmarks: main, nav, header, footer instead of generic <div>s.
Use native HTML elements instead of recreating interactivity — <button> instead of a clickable <div>, <a href> instead of onClick on a <span>.
Set the document language correctly via the <html lang="…"> attribute.

Every form field needs a visible, programmatically associated <label> — placeholder text alone isn't enough.
Communicate required fields and format requirements (e.g. date format) clearly before submission, not just via color.
Give specific error messages tied to the affected field (e.g. via aria-describedby), not just a generic banner.
Group related fields (e.g. an address) with <fieldset> and <legend>.

Links and buttons need text that makes their purpose clear even out of context — not just "click here" or "more".
Make touch targets on mobile at least 24×24 pixels with enough spacing between them.
For icon-only buttons, add an accessible name via aria-label.
Communicate state (selected, disabled, expanded) both visually and via ARIA attributes (aria-expanded, aria-selected, aria-disabled).

Build automated scans like this one regularly into your development process, ideally before every release.
Complement automated results with manual keyboard and screen reader testing (e.g. NVDA, VoiceOver).
Where possible, get real feedback from people who use assistive technology.
Consider accessibility from the start (design, concept phase), not as a fix right before launch.