WYSIWYG editing Image gallery upload Content templates
Accessibility · Updated April 2026

Accessibility Statement

Richscripts Inc. is committed to making RichTextBox usable by everyone, regardless of the assistive technology a person uses to write and review documents. This page states what we target, what currently works, and where we know we fall short.

Conformance target

RichTextBox targets conformance with Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. The editor is built on native contenteditable, standard semantic HTML, and ARIA roles / attributes where semantic HTML alone is insufficient.

A third-party accessibility audit is scheduled for 2026 and a VPAT 2.5 report will be published once that audit closes. Until then this statement reflects our self-assessment, kept honest by calling out what we know doesn't work.

What works today

Keyboard operability (WCAG 2.1.1, 2.1.2, 2.4.3)

  • All toolbar commands have keyboard shortcuts. Tab moves focus through toolbar groups; arrow keys navigate within groups.
  • Dialogs are focus-trapped; Esc closes and returns focus to the triggering control.
  • Tables support tab-based cell navigation and Shift+Tab reverse.
  • Slash commands, @mentions, and the AI dialog are fully keyboard-driven — no mouse required.
  • No keyboard trap: users can always Esc out or Tab past the editor.

Screen reader support (WCAG 1.3.1, 4.1.2, 4.1.3)

  • Toolbar buttons expose accessible names via aria-label; toggle states via aria-pressed.
  • Dialogs expose role="dialog" + aria-modal + aria-labelledby.
  • The AI Review drawer exposes role region with a live label; new suggestions are announced via aria-live="polite".
  • Comments and Track Changes suggestions expose per-author labels so screen readers announce "Comment by Maya Patel".
  • Headings in editor content preserve h1h6 semantics; lists preserve ul/ol/li.

Visual design (WCAG 1.4.3, 1.4.11, 1.4.12)

  • Default theme meets 4.5:1 text contrast and 3:1 UI contrast.
  • Focus indicators are visible at 3:1 against adjacent colors and are never suppressed by custom skins shipped with the package.
  • Editor layouts honor user text-size preferences — no fixed pixel heights that clip text when the browser zoom is 200%.
  • No information is conveyed by color alone; track-change attribution always includes an author label as well as a color.

Input assistance (WCAG 3.3.1, 3.3.3)

  • Upload and image-URL dialogs describe errors in plain language, associated with the failing field via aria-describedby.
  • Destructive actions (delete comment, reject suggestion) offer an Undo path in the review drawer.

Content model

  • Images receive alt text via the Image dialog; alt is preserved on paste from Word, Excel, and Google Docs.
  • Links preserve human-readable text — "click here" is not generated automatically.
  • The exported HTML and DOCX preserve heading levels and list structure; downstream screen readers see structure that matches the editor.

Known gaps

We believe trust is built on honesty, not a perfect-sounding statement. These are the areas where we know we don't yet meet the target, and what we're doing about each:

Supported assistive technology

We test against the following combinations before each release. Issues in any of these combinations block release.

Platform Screen reader Browser
Windows 11 NVDA 2024.x Chrome, Firefox, Edge (latest)
Windows 11 JAWS 2024 Chrome, Edge (latest)
macOS 14+ VoiceOver Safari (latest)
iOS 17+ VoiceOver Safari
Android 13+ TalkBack Chrome (best effort)

Keyboard shortcuts

The End-User Guide documents the full shortcut reference. Highlights:

Report an issue

If you use assistive technology and something doesn't work, we want to hear about it. Please include:

Email [email protected] — we commit to a first response within two business days.

Version history. This statement was first published April 2026. It is reviewed each quarter alongside our release cycle; material changes are called out in the product changelog.