Keyboard support

Silktide finds parts of your pages that respond to a mouse or touchscreen - clicking, hovering, dragging - but may not work for someone using only a keyboard. Everything a visitor can do with a mouse should also be possible with a keyboard.

Why this matters

Many people cannot use a mouse or touchscreen: people with motor impairments, people with tremors, and blind users, whose screen readers drive the page through the keyboard. For all of them, functionality that only responds to a pointer is simply unavailable. Keyboard operability is WCAG success criterion 2.1.1, a level A requirement - the most basic tier of the standard.

How to fix it

1. Prefer native HTML elements - links, buttons, and form controls - which are keyboard-operable by default:

<!-- Only works with a mouse: not focusable, double-click only -->
<div ondblclick="location.href='\/new-page'">Double click me</div>

<!-- Fixed: a link works for everyone -->
<a href="\/new-page">Go to page</a>

2. Where custom interaction is unavoidable, add a keyboard equivalent: make the element focusable (tabindex="0"), and handle key events alongside the mouse events.
3. Hover-only interactions such as tooltips and dropdown menus need particular care - show them on keyboard focus as well as on hover.
4. If a flagged element has a keyboard equivalent Silktide could not see, approve the finding.

How Silktide tests this

1. Collect the event listeners the page registers in the browser.
2. Keep those for mouse-only and touch-only events: clicks, double-clicks, hovers, mouse movement, wheel, context menus, and touch gestures.
3. For plain click handlers, skip elements a keyboard can already operate - links, buttons, form fields, and anything focusable via tabindex - because pressing Enter on a focused element fires its click handler.
4. Report the remaining elements for you to confirm whether a keyboard alternative exists.

Troubleshooting

The element has a keyboard alternative elsewhere

Silktide flags elements whose listeners suggest pointer-only behaviour, but it cannot always tell that the same functionality is available another way - for example a hover menu that duplicates links in the footer, or a drag action with a button equivalent. Where an alternative genuinely exists, approve the finding.

Hover effects that are purely decorative

Listeners that only change appearance (a highlight on hover, an animation) don't withhold any functionality from keyboard users. These are safe to approve.

Learn more

• Understanding Success Criterion 2.1.1: Keyboard (WCAG 2.1)
• Tooltips in WCAG 2.1 (Sarah Higley)