Tooltips (don’t be hover-only)
A short, practical UI accessibility note for games and web UIs. No tracking.
Try the micro-demo: tooltip-demo.html
It compares a tooltip that only appears on hover (BEFORE) vs one that appears on keyboard focus, hover, and tap (AFTER).
What goes wrong
Many UIs use a little “?” icon next to a label. The tooltip appears on mouse hover, so it feels fine in testing. But if the tooltip is hover-only, then:
- Keyboard users can focus the icon, but never see the hint.
- Touch users don’t have hover at all.
- Screen readers can miss the tooltip content unless it’s programmatically associated.
What to do instead
- Make the trigger a real
<button>(not a bare<div>). - Show the tooltip on focus as well as hover.
- Support tap/click (toggle open/closed).
- Provide a way to dismiss it (e.g.,
Escape). - Associate the content with the trigger using
aria-describedby.
Minimal sketch:
<button id="help" aria-describedby="tip">?</button>
<div id="tip" role="tooltip" hidden>Audio controls stereo mix.</div>
<script>
const btn = document.getElementById('help');
const tip = document.getElementById('tip');
const setOpen = (v) => tip.hidden = !v;
btn.addEventListener('focus', () => setOpen(true));
btn.addEventListener('blur', () => setOpen(false));
btn.addEventListener('click', () => setOpen(tip.hidden));
btn.addEventListener('keydown', (e) => {
if (e.key === 'Escape') setOpen(false);
});
</script>
Exact behavior varies by UI, but the big idea is: don’t rely on hover alone.