Accessibility Statement

Richscripts Inc. is committed to making RichTextEditor 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

RichTextEditor targets conformance withWeb 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 and formal VPAT are not yet published. Until independent evidence is available, this page is a self-assessment and explicitly lists the gaps we know about.

What works today

Keyboard operability (WCAG 2.1.1, 2.1.2, 2.4.3)

The toolbar is a single tab stop, following the ARIA Authoring Practices toolbar pattern: Tab enters it once, then ← / → move between buttons and Home / Endjump to either end. Focus returns to whichever button you last used. Arrow direction follows the document’s reading direction in RTL.
No keyboard trap (2.1.2). Tabkeeps its editing meaning inside the content — indenting a list, moving to the next table cell — so the way out is a separate, documented key: Esc leaves the editing area and puts focus on the toolbar, from whichTabcontinues through the page normally. The escape route is announced as part of the editing area’s accessible name, so a screen reader reads it on entry rather than leaving the user to guess. If a menu or dialog is open, Esc closes that first.
All toolbar commands have keyboard shortcuts.
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.

Screen reader support (WCAG 1.3.1, 4.1.2, 4.1.3)

Toolbar buttons expose accessible names via aria-label. Toggle commands — bold, italic, underline, alignment, lists, track changes and the view modes — expose aria-pressed, mirrored from the editor’s own active state so the announced value can never disagree with the highlighted button. Menu buttons expose aria-haspopup and keep aria-expanded accurate as the menu opens and closes.
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 h1–h6 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.
PDF export is tagged.Selectable text is not the same as an accessible document — an untagged PDF gives assistive technology a flat stream of words with no headings, list semantics, table relationships or guaranteed reading order. The vector exporter writes a full structure tree (H1–H6, P, L/LI, Table/TH/TD with column scope, Figure with /Alt), and marks rules, borders and running headers as artifacts so they are excluded from the reading order. See why a searchable PDF and an accessible PDF are different features.

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:

Third-party audit not yet published. This statement reflects self-assessment only. Enterprise procurement teams that require a formal VPAT should treat it as an open requirement and contact us for the current accessibility evidence package.
Table headers are flagged, not inferred.The editor does not guess that a first row is a header row — guessing wrong relabels data as headings, which is worse than leaving it alone. What it does do is flag the table: the accessibility checker raises table-missing-header on any table with no header cells, and offers a one-click repair that promotes the first row to <th scope="col">, preserving cell content and attributes. That scope is what carries through to the tagged PDF (TH with column scope) and to .docx (a repeating tblHeader row), so one fix corrects the table everywhere it is exported. The residual gap is that a casually-authored table stays inaccessible until someone runs the checker.
Image editor (tui.image-editor) is a third-party dependency; its tool palette is not fully keyboard-accessible. We expose a plain Upload fallback so users can skip the editor and still insert alt-text-bearing images.
Mobile toolbar is responsive but not optimized for VoiceOver / TalkBack rotor navigation. On the 2026 roadmap alongside the dedicated mobile toolbar mode.

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:

Ctrl+B / I / U — bold / italic / underline
Ctrl+K — insert link
/ at start of a line — slash-command menu
@ + name — mention picker
Ctrl+Alt+M — add comment on selection
Ctrl+Shift+E — toggle Track Changes
Ctrl+Space on a selection — Ask AI

Report an issue

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

The assistive technology you’re using (name + version)
Browser and operating system
What you were trying to do, what happened, and what you expected
The URL or a code snippet if you’re an integrator

Email accessibility@richtexteditor.com— 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 release notes.

Documentation