- Success Criterion 4.1.2
- Conformance level A
- W3C reference F42
Scripted Link or Button With No Real Role or Keyboard Support
4.1.2 — Name, Role, Value
Scenario
Setting
A language-learning app's lesson screen
What’s wrong
Something is made to act like a link or button using script only (a clickable div/span) — it isn't announced as a link/button and often can't be used by keyboard.
Example
<span class="check-answer-btn" onclick="checkAnswer()">Check answer</span>
<!-- styled to look like a button, but it's a bare span with only a click handler --> Why it matters
A keyboard-only learner tabbing through the exercise skips right past it and can never submit an answer.
How to test
Inspect a link/button emulated with a div/span: check the Accessibility Tree for the correct role and confirm keyboard operability — either missing fails.
How to fix
A native button gets focus, keyboard activation, and the button role for free; a styled span gets none of that.
<button type="button" class="check-answer-btn" onclick="checkAnswer()">Check answer</button> Outcome
A learner tabs to "Check answer" and submits their response with the Enter key.
Who is affected
Keyboard-only users and screen reader users doing the lesson cannot reach or activate the check-answer control.
Learn more
- Understanding Understanding document (opens in a new tab)
- Technique Related technique (opens in a new tab)
Related scenarios
- Custom Dropdown or Slider With No Accessibility API Support
- Content Changes That Never Update Their Accessible Name
- Clickable Div Turned Into a Control but Given No ARIA Role
- Form Field With No Programmatic Label at All
- Assistive Technology Never Told Which Element Currently Has Focus
- Multi-Part Field Where Each Box Has No Individual Name