Accessibility

The browser turns your HTML into an accessibility tree: every element gets a role (what it is), a name (what it's called) and states (checked, expanded…). Screen readers and voice control read that tree, not your pixels.

• Native elements come with all three plus keyboard support: a <button> is focusable and works with Enter and Space for free.
• ARIA attributes (role, aria-*) only change the tree. They add no behavior, so a role="button" still needs tabIndex and key handlers.
• The five rules of ARIA: (1) don't use ARIA if HTML can do it; (2) don't add ARIA that repeats HTML; (3) every ARIA control must work with a keyboard; (4) never hide focusable elements with aria-hidden; (5) every interactive element needs an accessible name.
• Use ARIA for what HTML can't say: aria-expanded, aria-current, aria-describedby, live regions, and custom widgets that follow the ARIA Authoring Practices.

Sighted people skim a page by its layout; screen reader users skim by its landmarks and headings, jumping between them from a list. If the structure is only visual, there is nothing to jump to.

• Landmarks come from <header>, <nav>, <main>, <aside>, <footer>, and a named <section> or <form>. Give repeated ones a label (aria-label="Main").
• Headings form the outline: one h1, then levels in order without skipping. Pick the level for the structure and style it with CSS.
• Lists (ul, ol, dl) say how many items there are; data tables need <th scope> and a <caption>.
• The document: a unique, descriptive <title> with the specific part first (it's the first thing announced), lang on <html> so the right voice is used, lang on parts in another language, and a title on every <iframe>.

Many people never use a mouse: they move focus with Tab and Shift+Tab, act with Enter and Space, and move inside widgets with the arrow keys. They need to reach everything, in a sensible order, and always see where they are.

• Focus order follows the DOM. Keep the source order the same as the visual order instead of fixing it with tabindex.
• tabindex="0" adds an element to the order, -1 makes it focusable only by script (a skip-link target, a dialog). Avoid positive values: they jump to the front of the whole page.
• A skip link as the first stop lets keyboard users pass the navigation on every page.
• Never remove the outline without a replacement. A visible focus indicator needs 3:1 contrast; :focus-visible shows it for keyboard users only.
• Manage focus when the page changes under the user: move it into an opened dialog and back to the opener on close (see practice 8, Accessible Modal), and to the new heading after a client-side route change.

When JavaScript changes the page, sighted users see it; screen reader users only hear about it if the page tells them. State changes belong on the element, and status messages go through a live region.

• Put click handlers on native controls (they get keyboard support); custom ones need keydown handling for Enter and Space.
• Reflect state in ARIA: aria-expanded on disclosure buttons, aria-pressed on toggles, aria-current="page" in navigation.
• A live region (role="status" or aria-live="polite"; role="alert" only for urgent errors) must be in the page before its text changes, or nothing is announced.
• In a single-page app, update document.title on every route change and move focus to the new content; the framework won't do it all for you.

Every image and media file needs a text alternative that does the same job for someone who can't see or hear it. The right alt text depends on why the image is there.

• Informative: say what matters in this context, in under about 150 characters, without "image of". Functional (in a link or button): name the action or destination. Decorative: alt="", or a CSS background.
• Complex images (charts, maps): a short alt plus the details nearby, in a <figcaption>, a table or a linked description. Inline SVGs need role="img" and a <title> or aria-label.
• Captions are the speech and meaningful sounds in sync, for people who can't hear; subtitles translate for people who can. Transcripts help everyone review and search, and search engines can read them.
• Audio description narrates important visuals between the dialogue; plan it in the script so the video says what it shows.

Low vision and color blindness affect hundreds of millions of people, and everyone struggles to read in bright sunlight. Text needs enough contrast, and meaning must never depend on color alone.

• WCAG contrast ratios run from 1:1 to 21:1. Normal text needs 4.5:1; large text (24px, or 18.5px bold) 3:1; icons, borders and focus indicators 3:1. The enhanced level is 7:1. Logos and disabled controls are exempt.
• Pair color with something else: an icon and text for errors, underlines for links in text, patterns or labels in charts.
• Respect user settings: prefers-color-scheme for dark mode, prefers-contrast and forced colors for high-contrast modes, and check both themes.
• A grayscale view of a design is a quick test of "color alone".

Readable type helps people with low vision and dyslexia, and everyone else. Above all, text must be able to grow: people zoom to 200% or more and change spacing, and the layout must keep up.

• Use a plain, familiar typeface; avoid ornate, handwritten or all-caps text for long reading, and limit bold and italics.
• Size text in rem or em so the user's default size applies; never block zoom in the viewport meta tag.
• Let boxes grow with their text: no fixed heights on text containers. WCAG asks content to survive line height 1.5, paragraph spacing 2×, letter spacing 0.12em and word spacing 0.16em.
• Keep lines under about 80 characters, align text left (justified text leaves uneven gaps), and break content up with headings and lists.

Motion can cause dizziness and nausea for people with vestibular disorders, distract people with ADHD, and flashing can trigger seizures. Keep animation meaningful, and let people turn it off.

• Never flash more than three times a second; check video and effects with a tool such as PEAT if in doubt.
• Anything that moves, blinks or scrolls on its own for more than 5 seconds needs a pause, stop or hide control.
• Honour prefers-reduced-motion: reduce: replace movement with a fade or no animation, and start parallax, auto-playing carousels and video only when motion is allowed.

Forms are where people get stuck: sign-up, checkout, search. Every field needs a visible label, and every error must be found, understood and fixed without relying on sight or color.

• A <label for> that is always visible; placeholders disappear as you type and often fail contrast.
• Group related options with <fieldset> and <legend>; link hints with aria-describedby; add autocomplete so browsers and password managers can fill fields.
• On error, say what is wrong and how to fix it in text next to the field, set aria-invalid, and move focus to an error summary that links to each field.
• Don't change context on focus or input (jumping to another page, submitting on select), and confirm success in words.
• For long forms, split them into steps with a clear progress indicator (see practice 10, Multi-step Form).

Accessibility scales through teams: build it into shared components once, and into design before any code exists.

• Start from proven patterns (ARIA Authoring Practices, GOV.UK, USWDS, Inclusive Components), but test any copied code yourself with your own browsers and screen readers.
• A design system is the best place to fix things once: names, focus styles, contrast tokens and keyboard behavior in every button, menu and dialog.
• Inclusive design: offer a comparable experience, consider the situation (one hand, bright sun, slow network), use familiar conventions, give people control, and offer more than one way to do things.
• Personas that include permanent, temporary and situational disabilities keep these needs in view; annotations hand landmarks, headings, focus order and names to developers.
• Test with automated tools (they find about a third of issues), then by hand with the keyboard and a screen reader, and above all with disabled people; simulators are no substitute.