Skip to main content

Rich Text Editor

A WYSIWYG editor supporting text formatting such as bold, lists, and hyperlinks. Use when users need to author structured or styled content within the product. Don't use for plain text form fields — use Input or Text Area instead.

Figma Storybook Docs

Description

What it does

Provides an in-browser authoring surface with a toolbar for applying formatting — headings, bold, italic, unordered and ordered lists, hyperlinks, and inline images — and outputs structured HTML content.

Where it appears

Consultation description fields, stakeholder communication templates, news and announcement body content, survey question descriptions, and email body authoring within Open Point.

Why it exists

Government staff need to produce readable, structured content for community-facing pages and notifications without writing raw HTML. The rich text editor bridges the gap between plain text inputs and a full CMS, keeping authoring inside the product workflow.

Anatomy

PartRequired?Notes
Toolbar Required Contains formatting action buttons grouped by type: text style (Bold, Italic, Underline), structure (Heading levels, Unordered List, Ordered List), and insert actions (Link, Image). Rendered above the editable region.
Toolbar button Required Individual icon buttons within the toolbar. Each has an active/pressed state to reflect the format applied at the current cursor position. Minimum 44x44px touch target.
Toolbar divider Optional Visual separator between toolbar button groups. Uses --op-color-border-default.
Editable content area Required The contenteditable region where users type and see formatted output. Renders formatted HTML output inline (WYSIWYG). Min-height should accommodate at least three lines of text.
Placeholder text Optional Descriptive hint shown when the content area is empty. Uses --op-color-text-placeholder. Disappears on first keystroke.
Character / word count Optional Displayed below the content area when a limit is configured. Shows remaining characters or a warning when the limit is approached.
Field label Recommended Sits above the toolbar, associated with the editor via aria-labelledby. Follows the same label pattern as Form Control.
Hint text Optional Supporting instruction below the label, associated via aria-describedby. Explains formatting expectations or content limits.
Validation message Recommended Inline error or success message displayed below the content area. Uses status tokens and the Validation Message component.
Focus ring Required 3px solid ring using --op-color-interactive-focus applied to the content area container on keyboard focus.

Variants

Standard

Default editor with full toolbar

Use for consultation descriptions, announcement bodies, or any long-form content that may need headings, lists, and links. Most common authoring context.

Minimal

Reduced toolbar — bold, italic, and unordered list only

Use when rich formatting is permitted but the content scope is narrow — for example, a survey question description or a tooltip body that supports basic emphasis but not full document structure.

Read-only

Renders formatted HTML output without an editable surface

Use to display previously authored rich text content in a form review step, a confirmation page, or a detail view where the user cannot edit.

Disabled

Full editor rendered but non-interactive

Use when the field exists in the form but cannot be edited due to workflow state — for example, a locked consultation that has been published.

States

State Behaviour
Default Toolbar and content area are visible and interactive. Content area shows placeholder text if empty.
Focused Content area receives a 3px focus ring using --op-color-interactive-focus. The toolbar remains visible and active. Screen reader announces the labelled field is in edit mode.
Active (toolbar button pressed) A toolbar button shows its active state — background fill using --op-color-interactive-default at reduced opacity, icon uses --op-color-text-on-interactive — when the corresponding format is applied at the cursor position.
Error Content area border changes to --op-color-status-error. Validation message appears below the editor. aria-invalid="true" is applied to the content area container.
Disabled Toolbar buttons and content area are non-interactive. All elements render at reduced opacity using --op-color-text-disabled. aria-disabled="true" applied to the container.
Read-only No toolbar rendered. Content area replaced by a styled HTML output region with no contenteditable attribute. Content is visually identical to the authored output.
Character limit warning Character count indicator switches to --op-color-status-warning colour when the user is within 10% of the character limit.
Character limit exceeded Character count indicator switches to --op-color-status-error. Further input may be blocked or flagged depending on configuration.

Usage guidelines

When to use

  • Authoring long-form content that will be published to community members — consultation descriptions, project updates, news articles.
  • Composing email or notification templates where staff need to apply emphasis, structure content with lists, or insert hyperlinks.
  • Survey or form question descriptions that benefit from formatted instructions.
  • Any field where the output is rendered as HTML and basic document structure (headings, lists, links) adds clarity for readers.

When not to use

  • Short, single-line text inputs — use Input instead.
  • Multi-line plain text with no formatting requirement — use Text Area instead.
  • Code or technical string fields — use a monospaced Input or Text Area.
  • Fields where the output is processed programmatically and formatting would introduce unwanted markup.

Do / Don't

Do

Set a meaningful character limit and display the count so authors can self-manage content length before submission.

Don't

Leave character limits unconfigured for public-facing content — unconstrained HTML output can break page layouts.

Do

Associate a clear field label and hint text explaining the expected content and any formatting conventions (e.g. 'Use headings to structure long descriptions').

Don't

Use placeholder text as a substitute for a label — placeholder disappears on input and is not reliably announced by screen readers.

Do

Use the Minimal variant for short supporting text fields where only basic emphasis is needed.

Don't

Use the Standard variant with a full toolbar for fields expected to contain only one or two sentences.

Do

Sanitise HTML output server-side before storing or rendering content, even when the editor enforces formatting constraints client-side.

Don't

Trust raw editor output as safe HTML — XSS risks apply if output is rendered unescaped.

Do

Provide clear validation feedback when required rich text fields are empty or exceed limits.

Don't

Rely solely on the character counter to communicate limits — pair it with a validation message on submit.

Was this page helpful?

Updated 9 September 2026