Accessibility of Text Editors

This is a technique for testing:

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

Overview

In 2007, Pete Krantz re-evaluated a series of online rich text editors – these are like mini word processors that allow users to add text and multimedia content to web pages without having to know any Hypertext Mark-up Language (HTML) – Evaluation of WYSIWYG 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 is fckeditor with additional HTML tags to provide an easy way of reaching the features for adding media, adding URLs and making lists to embellish content.   This work around was used for the development of the LexDis website as were the additions to JW player.

fckeditor with html links

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 toolbar using the Errors, Features and Alerts may show where further issues can arise.  In the picture below the number of red icons mean there are several errors and the element cannot be accessed or used by a screen reader user.  These errors may be highlighted when a text browser such as WebbIE is used along with a screen reader.   If the form cannot be identified it may be ignored altogether.  

fckeditor with label errors

Advice