Inspect the accessibility tree

A native button exposes a role, accessible name, disabled state, and keyboard behavior without custom scripting. That contrast gives us something useful to test instead of a rule to memorize.

Assistive technologies work from platform accessibility information, not directly from the visual pixels. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can assume visible text and CSS alone produce the intended programmatic meaning and still get one successful demo. Push past the demo. inspect the computed accessibility properties and fix the source semantics that create them, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Frame accessibility around successful user tasks and inspect what browsers expose to assistive technology. Save the before-and-after evidence now; it will make the final project review much more honest.

Compare a button element with a clickable div in the accessibility inspector and keyboard. Save the evidence, then explain which requirement would force you to choose a different design.