Invalid HTML gets silently rewritten
A <p> can't contain a <div>, so the parser closes the paragraph before the div, and the stray </p> creates a second, empty paragraph. The div in the ul is kept but is invalid: a screen reader may count the list wrongly. The validator reports both.
Quality comes from layers of checks: the W3C validator for correct HTML, Lighthouse and axe for automatic accessibility checks, a keyboard and screen reader pass for what tools can't judge, and the DevTools accessibility tree to see what assistive tech really gets.
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.
Write a Playwright test that loads /signup and fails if axe finds any WCAG A or AA violations.
This HTML has three validation errors. List them and write the fixed version: <ul><div><li>One</li></div></ul><img src="a.png"><label for="x">Name</label><input id="y">
Explain it without notes
Why validate HTML if browsers display invalid HTML anyway?
What can automated accessibility tools catch, and what can't they? How do you test the rest?
How would you add accessibility checks to a team's development process?
What does the DevTools accessibility pane show, and when do you use it?
Preview
Console
Nothing logged yet.Expected console output
paragraphs written: 1, paragraphs in the DOM: 2
div is inside the p? false
children of ul: DIV, LI