About
Learn it by finding it.
Most accessibility guidance tells you the rules. This practice ground asks you to find where a page breaks them, because spotting the problem yourself is the lesson that sticks.
Why it exists
You can read "all controls must be keyboard operable" a hundred times and still ship a <div> that a keyboard user cannot reach. The gap between knowing a rule and understanding it is experience.
So each lesson hands you a full, normal-looking website and asks you to break in with the keyboard. You hunt for every barrier, then open the breakdown to see exactly what you missed and why. By the time you reach the fixed site, the difference is something you have felt, not just read.
How a lesson works
- Practice. Open the page and move your hand off the mouse. Use only
Tab,Shift+Tab,Enter,Space, the arrow keys andEsc. - Note every place you get stuck, lost, or locked out. Try to do every action on the page.
- Breakdown. Check your list against the code-level explanation of each barrier.
- Fixed. Run the same test on the rebuilt page and feel what changed.
The principles behind it
Three ideas shape every page, and they are the same ideas you will be practising:
Semantics first
Native HTML elements come with keyboard support, focus and roles for free. Most fixes are just using the right element.
Keyboard is the floor
If it works with a keyboard, it tends to work with screen readers, switches and voice control too. It is the baseline, not an extra.
Show, do not lecture
This site itself ships almost no JavaScript and keeps a loud, visible focus ring. It tries to model the thing it teaches.
Where it comes from
This is the hands-on practice ground from Accessible.org, a companion to the audits, VPATs and WCAG checklist that turn accessibility from a checkbox into a craft.
It is a learning sandbox: a place to make mistakes on purpose and learn to spot them in the wild.