Paths Subjects Questions Quizzes Pricing Search
Intermediate Open Free

Making an Icon-Only Toolbar Accessible

You're reviewing a rich-text editor's toolbar: a row of icon-only buttons (bold, italic, underline, insert link, insert image) with no visible text labels, built as <div> elements with onclick handlers and custom CSS to look like buttons. A tooltip shows the button's name on mouse hover.

  1. List the concrete accessibility gaps in this toolbar as built.
  2. For each gap, name the specific fix.
  3. Why doesn't the hover tooltip solve the labeling problem on its own?
Solution

1 & 2. Gaps and fixes

  • No keyboard operability: <div> with only an onclick handler isn't in the tab order and doesn't respond to Enter/Space. Fix: use real <button> elements, which get keyboard activation and tab-order inclusion automatically, or add tabindex="0" plus manual keydown handling if a native button is genuinely unusable for some reason.
  • No accessible name: icon-only, no visible text, so a screen reader announces only "button" (or nothing distinctive at all if built as an unstyled div) for every single toolbar item — a user can't tell bold from italic from insert-link. Fix: aria-label on each button ("Bold," "Italic," "Insert link") so each gets a distinct accessible name independent of the tooltip.
  • No indication of toggle state: bold/italic/underline are typically toggle buttons (currently active or not on the selected text), and if that state is only shown via a visual highlight, it's invisible to a screen reader. Fix: aria-pressed="true"/ "false" on the toggle buttons, updated as selection state changes.
  • No visible focus indicator: if the custom div styling didn't include a focus style (a likely companion bug to the missing keyboard support), a sighted keyboard user tabbing through the toolbar can't see which button is focused. Fix: a :focus-visible style meeting the 3:1 UI-component contrast minimum.

3. Why the tooltip alone doesn't solve labeling

A hover tooltip requires a mouse (or a deliberate long-press on touch) to trigger — a screen-reader user navigating by keyboard or swipe gestures, and a keyboard-only sighted user, may never trigger a hover state at all, so the label the tooltip provides is invisible to exactly the population that most needs an accessible name. A tooltip is a supplementary visual affordance for sighted mouse users, not a substitute for aria-label, which is read directly from the accessibility tree regardless of input method.

Share this question

← Back to Accessibility and Inclusive Design practice

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.