Accessibility

A rich text toolbar on small screens

Thirty buttons do not fit on a phone. Sort by use, put the rest behind a labelled menu, size the tap targets, and keep the toolbar usable from a keyboard.

6 min read

A desktop toolbar with thirty buttons does not fit on a phone. The usual responses are to wrap the buttons onto several rows, to scroll them sideways, or to hide most of them behind a menu. Each choice has a cost. Wrapped rows push the text down the screen, sideways scrolling hides buttons from view, and a hidden menu makes common actions slower. The right answer depends on which actions writers use most, and on whether the toolbar can be reached with a keyboard as well as a finger.

Sort the buttons by how often they are used

Before choosing a layout, count what writers actually click. Bold, italic, a link, a list and undo usually make up most of the presses. Headings, tables, images and colours come next, and the rest are rare. Keep the first group visible on the smallest screen, and move the rare actions into an overflow menu. Do not decide by how many icons look alike, because the usage data often puts a rarely used icon near the top.

An overflow menu needs a clear label

A button with three dots is not self-explanatory. Give it a visible label such as “More”, and name it for screen readers with aria-label and aria-expanded, so the state is announced. When the menu opens, move focus to its first item, and return focus to the button when it closes. Closing with Escape must work, because a keyboard user has no other way out.

Code example
function toggleMore(button: HTMLButtonElement, menu: HTMLElement) {
  const open = button.getAttribute("aria-expanded") !== "true";
  button.setAttribute("aria-expanded", String(open));
  menu.hidden = !open;
  if (open) {
    menu.querySelector<HTMLElement>("[role='menuitem']")?.focus();
  } else {
    button.focus();
  }
}

The sample keeps the state in the DOM attribute, so screen readers and the visual state cannot disagree. Hiding the menu with the hidden attribute removes it from the accessibility tree while it is closed.

Make the buttons big enough to tap

A tap target that is smaller than about 44 by 44 CSS pixels is hard to hit with a thumb. Small toolbars are often packed tight, and the buttons end up as small as 24 pixels, with two targets sharing a single tap area. Give each button a minimum size, even if its icon is smaller, and leave a gap between groups. The visual size of the icon can stay small while the hit area is large.

A phone can still have a keyboard

Tablets with keyboards, and phones with a Bluetooth keyboard, need the toolbar to work with arrow keys as well as taps. Make the toolbar one tab stop, and move between its buttons with the left and right arrow keys. Tab should leave the toolbar entirely. Without this, a writer on a tablet must press Tab through every button to reach the editor.

The on-screen keyboard covers the toolbar

On a phone, the on-screen keyboard takes up half the screen, and a toolbar fixed to the bottom of the viewport can disappear behind it. Use the visualViewport API to measure what is left above the keyboard, and position the toolbar just above it. Where that API is unavailable, a toolbar placed in the normal page flow, directly above the editor, usually avoids the problem.

A short test list

RichTextEditor is a perpetual-licence JavaScript editor — one purchase, self-hosted, no metered editor loads. Download the evaluation or see how it compares.