Accessibility of Text Editors
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!
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.
- Webaim: Creating Accessible Forms
- ckeditor: keyboard shortcuts
- TinyMCE Accessibility
- Atto! text editor Usability and Accessibility
- Dive into Accessibility: Labelling form elements
- 456 Berea St: Use the label element to make your HTML forms accessible – highlighting how inaccurate use affects accessibility.
This technique may be used to test the following sections of best practice.
|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 AlsoWCAG 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
- 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