WYSIWYG editor spec – Overview

Sorry, slight change of plan, rather than producing a gargantuan post in 4 weeks, I’ll break it up. This is the overview that outlines the guidelines that affect a “What You See Is What You Get” editor (WYSIWYG) editor, and help you evaluate an editor so that you know what to look for.

So what makes a good, usable, accessible, WYSIWYG editor?

(NB: I’m using “editor” to exclusively mean the tool, and “author” for the person using it.)

The accessibility requirements fall into three broad categories in a rough order of importance:

1. It must create accessible output.
2. It must be accessible itself.
3. It should encourage/enforce accessible content (e.g. useful alternative text, appropriate heading use).

The usability aspects are a little harder to generalise, but the top line assumptions I’m making are that non-technical people are the main audience, and Word is likely to be their usual document editor. The usual scenario I come across is where the editor is part of a Content Management System (CMS) used by non-technical people who may not know anything about accessibility. I’m also assuming that the site would be using (X)HTML and CSS.

What to look for

For the non-technical web manager, evaluating an editor is not easy. It’s a combination of what interface you would consider usable, and what it outputs. For starters though I would evaluate a site that was created using that editor.

Creating accessible output

In the context of using an editor to produce (X)HTML, the accessible tools guidelines (ATAG) checkpoints 1.1 & 1.3 boil down to the same thing, they should allow (in my opinion, enforce) the use of accessible markup by the editor.

For an (X)HTML editor, that means that it must only allow certain functions, so the perfect editor is actually very locked down.

Bad example

The following example is from TinyMCE, I’m not picking on this one, almost all have this full featured view, and most can remove features.

The problem with having a full featured editor is that you cannot maintain separation of style from content when using many of the options. These options require an editor to add inline markup, either with font tags or inline styles.

For example, if you use the colour chooser, it produces this:

<font color="#cc3300">text</font>

Not only are font tags deprecated, but even if it used a span tag it would still be an inline style – and style should be separated for accessibility and maintainability.

So which of the controls should not be used? The implementation can vary, but in all likelihood the greyed out ones should not be included:

Good example

Most editors (including TinyMCE) are configurable, so what should you include?

• Block elements: (called “Format” in TinyMCE) this allows the addition of structure elements like paragraphs, headings and pre. I would also add blockquote to this drop-down if possible.
• Styles: these can be used for adding custom styles (classes) to elements.
• Lists: unordered, ordered and (perhaps) definition.
• Horizontal rule.
• Strong & Italics, assuming that is what the “b” and “i” buttons use. I would also add a ‘quote’ button for the <q> element.
• Images.
• Links.
• Tables.

There are other useful buttons such as ‘paste plain text’, but the list above covers the structural elements that authors should be using.

Being accessible as an editor

Being accessible for a browser based editor means that it should be as accessible as any web site is. However, as explained, an editor requires ‘behavior’, so JavaScript is in.

This makes it fairly easy to evaluate: there should be alternative texts for any images, controls should be keyboard accessible, expandable text, labels for inputs, and all the relevant checkpoints from the WCAG.

Given that you need to act on a material with certain controls (e.g. making the selected text bold), you need to be able to interact with a text area and select a control at the same time, with the keyboard.

The simplest way to evaluate this is by trying the editor using a keyboard. Defining this is going to be an interesting aspect, later in this series of posts.

Enforcing accessibility

How you enforce accessibility depends on what is possible when using the editor. If you have a locked down editor as outlined above, then it is typically things like:

• Alternative texts must be used.
• Changes in language are marked up in the code.
• The heading structure is logical.
• Links to the same page have the same link text, and links to different pages have different text (i.e. don’t use “click here”).

Just about everything else should be either impossible to get wrong.

Next steps

In order to get close to the above ideal interface, a WYSIWYG editor will need setting up correctly. The intent is to test commonly used editors such as TinyMCE, FCKeditor and Xstandard against the criteria (both ATAG and practical) in later posts with both the default configurations and when configured as best as possible.

Those posts will cover the configuration and interface aspects of:

• What HTML should be allowed.
• How CSS and custom styles should be imported.
• How to add structural code (i.e. what the user can choose, and what the editor then applies).
• How to add images and manage alt text.
• How to add data tables.
• How to add content area layouts.
• Interface accessibility.
• How to prevent accessibility issues.
• Overall WYSIWYG editor checklist.

It would be great to get some comments (critical, things to add or change etc.), perhaps at the end these could be pulled into one document. From this point on, the posts will be fairly technical.

---

Technorati Tags:

• accessibility
• editors
• WYSIWYG
• usability
• WCAG
• ATAG