Labels give inputs a name (placeholders don't)
input.labels is the browser's own list of labels for a field. htmlFor and wrapping both work; the placeholder-only field has none. Browsers may fall back to the placeholder as its name, but that name vanishes from view the moment you type, and tools such as Testing Library's role queries don't count it (Topic 18.5).
React renders plain HTML, so most accessibility comes free when your components output the right elements: real buttons, labelled inputs, headings and landmarks, with Fragments instead of wrapper divs that break the structure.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Rewrite <div className="icon-btn" onClick={close}><svg …/></div> so it is accessible.
A NavItems component returns <div><li>Home</li><li>About</li></div> and is used inside <ul>. Fix it.
Write a search form with a labelled search field and a submit button, using landmarks correctly.
Explain it without notes
Why is <div onClick> an accessibility bug, and what exactly does <button> give you instead?
What is the accessibility tree, and how does React's output reach it?
Why do Fragments matter for accessibility, not only for tidy markup?
What can eslint-plugin-jsx-a11y catch, and what can't it catch?
Preview
Console
Nothing logged yet.Expected console output
email | labels: 1 | label text: Email
phone | labels: 1 | label text: Phone
city | labels: 0 | label text: (none)
clicking the Email label focused: email