Toolbars of clickable icons a keyboard can't reach

A marketplace lets sellers fix a listing photo before it goes live. Under the photo sits a row of six icons: Rotate left, Rotate right, Flip, Zoom in, Zoom out and Reset. A seller whose photo came out sideways clicks Rotate right, and the mug stands upright. Each icon is a span holding an SVG, with a click handler on the span. Put the mouse aside and press Tab: focus goes from the page above straight to Save photo, past all six tools. No key turns the photo, so a keyboard user can only save it sideways. A screen reader reading the toolbar finds six spans with no text, no role and no name: nothing says the tools are there, that they can be pressed, or what each one does.

Success criterion 2.1.1 Keyboard asks that everything the mouse can do, the keyboard can do. Every tool works only on a click, on a span, which takes no focus. The browser turns Enter and Space into a click only on a native control, so even a span given tabindex would still ignore both keys. Turning, flipping and zooming the photo can't be done from the keyboard at all.

Success criterion 4.1.2 Name, Role, Value asks that every control's name and role can be determined by software. The tools are controls: a click on each one changes the photo. A span has no role of its own, so nothing says it can be pressed, and the icon inside is an SVG hidden from screen readers, so nothing gives the span a name either. W3C documents this as failure F59, script that makes a span or div a control without giving it a role, and more broadly as failure F15, a custom control that doesn't use the accessibility API.

Toolbars like this sit wherever a site edits something in place: photo and avatar croppers, document and PDF viewers, comment boxes, file lists with actions for what is selected. Icon tools are often drawn small and close together, which makes them hard to click for people with tremors, and some of them turn to the keyboard for exactly that reason.

2 of 10 groups affected

• No vision (affected)
• Low vision (not affected)
• Colour vision (not affected)
• No hearing (not affected)
• Hard of hearing (not affected)
• No speech (not affected)
• Motor (affected)
• Reach, strength (not affected)
• Cognitive (not affected)
• Seizures (not affected)

• Limited manipulation Keyboard and switch users never land on a tool, so they can't turn, flip or zoom the photo at all. Voice control users can't say "Click Rotate right", because no tool has a name, and are left to place the pointer by grid.
• Without vision Screen reader users find six empty spans with no text, no role and no name, so they can't tell that the photo can be turned, or which icon would do it.

axe has nothing to check in this toolbar. A span with a click handler has no role, so no rule asks it for a name, and nothing in the markup says it is meant to be pressed. The same span after the fix an AI may suggest, role="button", tabindex="0" and an aria-label, passes axe and Tab reaches it, but Enter and Space still do nothing, as div buttons that can't be reached with Tab shows.

The audit presses Tab through the page. An element with its own pointer cursor and an icon or words inside, in a container named as a toolbar by its class, id or role, that Tab never reaches is reported, when two or more such tools sit side by side and nothing in the row takes focus. In each role="toolbar" whose tools share one Tab stop, it focuses that tool and presses the arrow keys, Home and End; if focus never moves, the other tools can't be reached, and that is reported too. That is the other half-finished fix: the markup of the toolbar pattern, tabindex="-1" on every tool but the first, copied without the script that moves focus. A toolbar of clickable icons whose container has no telling class name, id or role is not reported as a toolbar, and no check can tell whether a name says what the icon does.