[RTE] Toolbar is not keyboard-navigable per the ARIA toolbar pattern

[AlexVelezLl]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Target branch: unstable

Observed behavior

The Rich Text Editor toolbar is marked up with role="toolbar" but does not implement the keyboard behavior that role requires by the WAI-ARIA APG toolbar pattern. Tabbing into the editor moves focus into the toolbar one control at a time — every button in the toolbar is its own tab stop. Arrow keys do nothing in the toolbar.

Expected behavior

The toolbar behaves as a single composite widget:

• The toolbar is one tab stop. Tab moves focus into the toolbar and then out to the next widget, never between controls inside it.
• Left/Right arrow keys move focus between controls within the toolbar, wrapping around at both ends. Directions are reversed in RTL.

User-facing consequences

Keyboard-only users must press Tab through every toolbar control to reach the editing area or the next field on the form. Screen reader users are told they are in a toolbar, then find the keys that role implies do nothing, so the announced semantics do not match how the widget actually works.

Steps to reproduce

1. Open a channel and edit an exercise.
2. Add or open a question so the question editor is shown.
3. Using the keyboard only, Tab until focus reaches the Rich Text Editor toolbar.
4. Press Tab repeatedly — focus stops on each toolbar control in turn.
5. With focus on a toolbar control, press the Left or Right arrow key — focus does not move.

Context

Not environment-specific. The toolbar is part of the shared Rich Text Editor used across the QTI editor, so the behavior is the same in any browser and on any OS.

Acceptance Criteria

• The Rich Text Editor toolbar is a single tab stop — Tab moves focus into the toolbar and then out to the next widget on the page
• Left and Right arrow keys move focus between controls inside the toolbar
• Arrow navigation wraps: Right on the last control focuses the first, Left on the first focuses the last
• Arrow directions are reversed in RTL
• Tabbing back into the toolbar returns focus to the control that last had focus within it
• Unavailable controls stay in the toolbar's arrow-key order and are marked aria-disabled instead of being removed from the focus order
• Dropdown triggers in the toolbar continue to open with Enter and Space, and Left/Right move past them like any other control
• Jest tests cover the single tab stop and arrow-key movement, including wrapping

AI usage

I used Claude Code to draft this issue. It read the toolbar components to confirm the current keyboard behavior; I made the behavioral decisions and reviewed every section.