8.8 Accessibility & inclusive basics

Accessible UI is mostly just well-built UI — real buttons, labelled inputs, enough contrast, things you can reach with a keyboard. It’s also the area an AI is laziest about, because the happy-path demo looks fine without it. The non-negotiables here aren’t a separate “accessibility pass”; they’re the baseline you ask for up front, and most of them also make the UI better for everyone.

Key vocabulary

Semantic HTML: Using elements for their meaning — <button>, <nav>, <header>, <label> — instead of generic <div>s. You get keyboard support, focus, and screen-reader meaning without writing any of it.
Focus ring: The visible outline showing which element the keyboard is on. Removing it (a common “cleanup”) makes the app unusable without a mouse. Keep it visible.
Label vs placeholder: A label names an input and stays visible; a placeholder is hint text that disappears on typing. A placeholder is never an acceptable substitute for a label — screen readers and forgetful users both lose.
Alt text: A text description of an image. Informative images need a meaningful alt; purely decorative ones take an empty alt="" so screen readers skip them.
WCAG AA contrast: The accessibility standard for legibility: text needs a contrast ratio of 4.5:1 against its background (3:1 for large text and UI elements). This site fails its own build if a token pair drops below AA.

Semantic HTML does the work for you

The foundation of accessibility is using the right element. A real <button> is focusable, clickable by keyboard (Enter/Space), and announced as a button to screen readers — all for free. A <div> dressed up to look like a button is none of those things until you reimplement them by hand, badly. Same for <nav>, <header>, <label>, <table>. “Div soup” — everything built from generic divs — is the root cause of most accessibility failures and a classic sign of AI-generated markup. Asking for “semantic HTML” up front prevents a whole category of problems.

Keyboard, labels, and contrast

Three checks catch most of the rest. Keyboard: every actionable thing must be reachable by Tab, in a logical order, with a visible focus ring; overlays trap focus and close on Esc. Labels: every input needs a real, visible label (a placeholder doesn’t count), and an icon-only button needs an accessible name. Contrast: body text must hit WCAG AA — 4.5:1 against its background — and you must never use colour alone to convey meaning (pair the red with an icon or text), since not everyone perceives it.

FIG 1 · contrast: AA pass vs fail The same accent on the same background. The left clears WCAG AA (4.5:1); the “subtle” grey on the right fails — and is exactly what AI reaches for.

Reaching everything by keyboard

A surprising amount of “it’s broken” turns out to be “it’s mouse-only.” Tab through any screen: can you reach every button, field, and link? Is the focus ring visible at each stop? In a modal, does focus stay trapped inside and return sensibly when it closes? This 30-second test catches the failures AI most often ships — icon buttons with no accessible name, custom dropdowns you can’t open with the keyboard, and the removed focus ring.

FIG 2 · a sensible focus order Tab should move through a form in reading order, with a visible ring at each stop and Esc to close any overlay.

Image is…	alt strategy	Why
Informative (a chart, a product photo)	meaningful alt describing it	the content is lost otherwise
Decorative (a background flourish)	empty alt=""	screen readers skip it — no noise
A functional icon (an icon-only button)	an accessible name on the button	“button, settings” not “button, unlabelled”

Alt text isn't “describe every pixel” — it's “convey the purpose, skip the decoration.”

01 Learning objectives

0 / 6 done

02 Curated reading

W3C WAI — Accessibility Principles
essential 18m — The authoritative “what accessible actually means” overview.
WebAIM — Contrast and Color Accessibility
essential 12m — WCAG AA contrast explained, with the ratios that matter.
MDN — Accessibility
optional 15m — Semantic HTML, ARIA, and keyboard support reference.

03 Knowledge check

knowledge check3 questions · pass ≥ 70%

01easy
Conveying status with colour alone (e.g. a red dot) is sufficient for accessibility.
02medium
WCAG AA requires body text to have a contrast ratio of at least…
03medium
What's wrong with a clickable <div> styled to look like a button?

04 Interview questions

browse all ↗

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

★ must-know Commonly asked mid concept common What are the most common accessibility mistakes, and how do you catch them?
The frequent offenders: div-soup (clickable <div>s instead of real <button>/<a>, so there's no keyboard or screen-reader support), placeholder-as-label (an unlabelled field), low-contrast text that fails WCAG AA, missing or removed focus rings, and icon-only buttons with no accessible name. You catch most of them in two minutes: Tab through the screen (can you reach and see focus on everything?), check contrast against AA (4.5:1 body), and confirm every input has a real label.
What a strong answer covers
- Div-soup → use semantic <button>/<a>/<nav> for free keyboard + meaning.
- Placeholder-as-label and icon buttons with no name → add real labels/names.
- Low contrast / removed focus ring → meet AA, keep the focus ring.
- Catch it: Tab through it, check contrast, check labels.
Quick self-check
An icon-only 'delete' button (just a trash icon) is announced by a screen reader as 'button, unlabelled'. The fix?
Follow-ups they push on
- Why is a clickable <div> worse than a <button>?
- Why isn't conveying status with colour alone enough?
Red flag Treating accessibility as a separate 'pass' at the end — it's a baseline you ask for up front, and most of it is just using the right element.
source: W3C WAI — Accessibility Principles ↗