Accessibility of Text Editors

Over the years there have been improvements in the accessibilty of text editors but there is still a need to evaluate which aspects of the menus can be easily reached and where there remain barriers for screen reader and keyboard only users. The University of Illinois Library Accessibility First group provided the outcomes of their meeting in April 2016 on the Accessible Text Editor Options and the decision was to update their own accessible text editor A11y First Text Editor which highlights the issues that still remain with these online word processors.

Checks for  keyboard access and tab order have been discussed  in relation to forms. However, even if certain keyboard shortcuts can be implemented once the user has landed within the editor, such as Ctrl+B for bold text, there remain limitations to total access in many editors.

The sample editor below can be configured in many ways as shown in the documentation provided by ckeditor


One point to remember when working with these types of editors – if you copy and paste text directly from Microsoft Word you may find there are times when your text has all sorts of small marks or oddities creeping in.  This is because the markup language that is used by Microsoft Word is not necessarily recognised by the browser.  Typical examples are the inverted commas (curly speech marks) or extra spaces becoming question marks in a diamond!


As has been suggested the main tests are manual as for keyboard access and tab order.

However a quick check with Webaim Wave online tool using the Errors, Features and Alerts may show where there are further issues but it may also fail to even find the text editor! In the picture below you can see how accessible elements of the Trix rich text editor can be viewed in WebbIE and used with a screen reader.    The menu button links can be seen and the text within the editor.

Trix rich text editor



This technique may be used to test the following sections of best practice.

Document Section Heading
WCAG 2.0 1.1 Provide text alternatives for any non-text content so… More Info
WCAG 2.0 1.1.1 Non-text Content More Info
WCAG 2.0 4.1 Maximize compatibility with current and future user… More Info
WCAG 2.0 4.1.1 Parsing More Info
WCAG 2.0 4.1.2 Name, Role, Value More Info

See Also

WCAG 2.0:   Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language. Understanding Guideline 1.1

1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)

  • Controls, Input:If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)  How to Meet 1.1.1 | Understanding 1.1.1

Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.  Understanding Guideline 4.1
4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A) How to Meet 4.1.1 | Understanding 4.1.1

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)  How to Meet 4.1.2 | Understanding 4.1.2