Skip to main content
Cayuse Design System Lato · 4pt grid · WCAG 2.1 AA

Components · Inputs

Rich Text Editor

Formatted text entry for long-form content — disclosure forms, meeting minutes, management plans. Currently an out-of-the-box Flowable editor with a reduced toolbar, and the least settled component in the system.

Figma source: Rich Text Editor ↗

Status: in design

This component is not resolved, and the file says so

The Figma page is an open working document rather than a specification. It records that OI 2.0 MVP will ship the out-of-the-box Flowable editor for disclosure forms, that HE 2.0 likely needs the same for study submissions, and that both may later need richer, Word-like editing for agendas, minutes, letters and management plans. It also records two unresolved questions: which tools belong in the “simplified” set, and how to handle accessibility for unlabelled toolbar buttons — with a note to review VPATs for the main offenders.

What follows is guidance for using it as it stands, plus the constraints any resolution needs to satisfy. Treat the toolbar composition as provisional.

Examples

Simplified toolbar

I serve on the scientific advisory board of Helix Therapeutics, which has a licensing agreement with the university.

Compensation is disclosed in the attached statement.

Usage

When to use it

  • Use only where formatting genuinely carries meaning — structured narrative, minutes, letters.
  • Keep the simplified toolbar to what the content needs: bold, italic, lists, links.
  • Preserve the user’s content on paste from Word rather than discarding formatting silently.
  • Autosave long-form content, or warn before navigating away.

When not to use it

  • Do not use for anything a Text Area covers. Every added tool is another unlabelled button in the tab order.
  • Do not ship the full toolbar because the library offers it — the file’s own list runs to over forty tools.
  • Do not allow arbitrary colour and font choices; they break the type system and are usually inaccessible.
  • Do not lose content on validation failure elsewhere in the form.
The unlabelled-button problem is the blocker

The file flags this and it is the right thing to have flagged. A toolbar of icon-only buttons with no accessible names is a wall of “button, button, button” to a screen-reader user, and it sits between them and the field they are trying to fill in. Any editor adopted here needs, at minimum:

  • An aria-label on every toolbar button.
  • role="toolbar" with arrow-key navigation, so the whole toolbar is one tab stop rather than forty.
  • aria-pressed on formatting toggles, so the user can tell whether bold is currently on.
  • A keyboard route out of the editing area that is not Tab, since Tab may insert an indent.

These are the criteria to evaluate any candidate editor against — and they are worth checking before committing, not after.