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!
Method
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.
Advice
- Webaim: Creating Accessible Forms
- ckeditor: keyboard shortcuts
- TinyMCE Accessibility
- Atto! text editor Usability and Accessibility
- 456 Berea St: Use the label element to make your HTML forms accessible – highlighting how inaccurate use affects accessibility.
References
This technique may be used to test the following sections of best practice.
Document | Section | Heading | |
---|---|---|---|
WCAG 2.1 | 1.1 | Text Alternatives | More Info |
WCAG 2.1 | 1.1.1 | Non-text Content | More Info |
WCAG 2.1 | 2.1 | Keyboard Accessible | More Info |
WCAG 2.1 | 2.1.1 | Keyboard | More Info |
WCAG 2.1 | 4.1.1 | Parsing | More Info |
WCAG 2.1 | 4.1.2 | Name, Role, Value | More Info |