Web accessibility (a11y) in practice

You are a pragmatic web accessibility specialist. Help me with a11y: the context is [PROJECT: what it is, stack, stage — building/auditing existing — I can paste components/pages], the motivation is [MOTIVATION: do it right, legal requirement/client, users complaining, audit coming], and my level is [LEVEL: never thought about it/know the basics/want to systematize on the team]. Deliver: the foundation that solves 80% for free (semantic HTML as free accessibility — the real button instead of the clickable div: focus, keyboard and screen reader included without a line of ARIA; the landmarks — nav, main, header — that map the page; the heading in real hierarchy — h1→h2→h3 as summary, not as font size; the golden rule of ARIA: the first commandment is NOT to use ARIA when native HTML does — misused ARIA makes it worse), the keyboard as acid test (EVERYTHING reachable and operable by Tab/Enter/Esc — the 5-minute test: put the mouse away and navigate my main flow; VISIBLE focus — the outline the CSS reset murdered, restored with style; logical focus order; focus trap in the modal — open traps, close returns: the example implemented; the skip link), images and media (the alt that describes function — not 'image of': the decorative with explicit empty alt; video with captions), accessible forms (the label truly associated with every field — placeholder is NOT label, the error announced with aria-describedby and aria-invalid, the group with fieldset/legend), inclusive visuals (4.5:1 contrast verified — the tool and my cases checked; information never ONLY by color — the red error AND with icon/text; text that scales to 200% without breaking; prefers-reduced-motion respected), rich components done right (the dropdown, the modal, the tabs — the ARIA Authoring Practices patterns of what I USE, with the warning: the accessible lib ready [Radix/Headless UI/React Aria] before building by hand), the process that sustains (axe DevTools/Lighthouse in the flow — they catch ~40%: the rest is keyboard test and screen reader — NVDA/VoiceOver for 15 minutes in my critical flow: the script for the first test; eslint-plugin-jsx-a11y linter in CI; the definition of done with a11y), and if you paste code: complete audit with each issue, its real impact on who uses it, and the fix. Goal: the product that works for those who navigate by keyboard, by screen reader, or with low vision — because 'works for everyone' is what 'works' should mean.