A text toolbar exposes commands that act on the current document or selection. Use one when visible commands help people discover useful operations. Keep ordinary typing, selection, and browser editing behavior available without requiring the toolbar.

Choose the components

Compose Buttons for commands and Menu for less frequent actions. ControlGroup can provide a visual grouping with shared Button configuration. It does not implement a complete ARIA toolbar or an editor command model.

Liquidify TextEditor renders a native textarea with a string value. It has no rich-text document, formatting marks, or built-in bold, italic, undo, and redo commands. For plain text, offer only operations the application implements, such as inserting a template. For rich text, integrate an editor that owns the document and selection, then connect supported Liquidify controls to that editor's commands.

Follow the interaction sequence

1. Identify the document and, where relevant, the selection a command will affect.
2. Expose only commands supported by the editing context.
3. Preserve the editor's selection before moving focus to a command when the editor integration requires it.
4. Execute the command through the application or editor API.
5. Reflect the updated document and return focus deliberately so editing can continue.

For an “Insert template” action, specify whether it replaces a selection or inserts at the cursor. If insertion cannot be performed at the original selection, explain or choose a documented fallback; do not silently replace the entire document.

States and recovery

A command may be available, unavailable, or applicable only to part of a selection. Represent those states according to the editor's model. Do not display a formatting control as selected merely because it was last pressed.

Keep the undo history in the editing system. A Button callback does not create a reversible transaction. Test whether application-driven string updates interact with native textarea undo before promising that behavior. If a save fails, preserve the editable document and distinguish unsaved content from an editing command failure.

Content

Use familiar command names and precise accessible labels. Include the affected action in an undo label when useful, such as “Undo insertion.” Show a shortcut hint only when the application actually supports it and it fits the active platform's conventions.

Avoid crowding the toolbar with duplicates of browser commands that people already use through native shortcuts and context menus. Keep less frequent commands in a predictable location.

Accessibility

For a small action group, normal Tab navigation through native Buttons is a valid starting point. If the application chooses role="toolbar", it must also implement the corresponding focus and keyboard interaction; adding the role alone is insufficient. ControlGroup does not add arrow-key navigation.

Keep the editing region labeled. Test keyboard-only movement between document and commands, selection retention, focus restoration, and unavailable commands. Do not intercept standard editing keys solely to imitate a native Apple menu.

Related implementation

See TextEditor, Button, ControlGroup, and Menu. Read Common actions for command outcomes and Overflow content for narrow layouts.

Further reading

• Apple: Toolbars
• Apple: Edit menus