WYSIWYG editor checklist
About this document
This checklist accompanies various posts on browser-based What You See Is What You Get (WYSIWYG) editors. It is intended as a tool to assess and help improve editors intended to produce (X)HTML web content, usually as part of a Content Management System.
- This version
- 0.2 (28-02-2007).
- License
- This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.0 UK: England & Wales License. Feel free to copy, publish and extend for non-commercial use, just please include a visible link back to this page. This document is specifically intended for use by people creating browser-based WYSIWYG editors (commercial or not).
- Author
- Alastair Campbell (email 'ac' at this domain). Feedback is welcome.
- See also
- The WAI's Authoring Tools Guidelines V1 (and V2).
Terms used
These terms are used throughout:
- Editor
- The installed application that people use to edit content, the full term is 'WYSIWYG editor', but usually just called 'editor' here.
- Author
- The person using the editor, assumed to have no technical or accessibility knowledge.
- Developer
- The person who installs / configures / implements the editor. It is assumed they have good knowledge of HTML/CSS, and some of accessibility.
- Core
- Core features are essential for accessibility. If an editor doesn't have these, it will be an uphill battle.
- Extra
- Useful, but perhaps not essential features.
Weighting
Some of these checks are more important than others. I'm not aiming for a pass/fail, but that a higher score means a better editor. The checkpoints that are a minimum for achieving accessible and valid output are marked as 'core' and failing means a negative score. 'Extra' features that are accessible can only help the editor score higher.
This is the scoring for each item:
- -1
- If the editor cannot accomplish one of the core checks, therefore use of this editor is likely to lead to accessibility issues.
- 0
- The editor cannot accomplish the check for an extra feature.
- 1
- It is possible to achieve the accessible outcome, but not the default or not easy.
- 2
- The accessible outcome is possible and easy.
Several of the items apply to a list of things, such as what HTML elements are allowed, and are scored separately to keep the main results clearer. For these, the score is out of 10 (for core), and 5 (for extras).
Process of evaluation
The steps to evaluate an editor with this checklist are:
- Install a copy of the editor, making sure that you can save and preview at least one (X)HTML page.
- Save this page off locally so that you can fill in the results in this page. (You might want to delete everything between 'Terms used' and 'Individual editor results'.)
- Fill in the version and platform information.
- Attempt to 'prove' each of the statements in the checklist. E.g. for "Removes elements and attributes not on the ideal HTML list": insert elements that should be removed. Save the page, and review the result.
- If the editor does not appear to support that check, try any relevant configuration settings that you can find and re-test. (This does mean an editor with better documentation may score better. This is a good thing!)
- Score each point according to the weighting.
- Note any peculiarities of support at the bottom (under 'notes'). Start each note with the checkpoint number it relates to.
- Total the scores.
Individual Editor Results
Editor name:
Editor version:
User browser:
Editor platform:
1. Setup and basic editor functions
| Requirement | Level | Score | |
|---|---|---|---|
| Total: | |||
| 1.1 | Removes elements and attributes not on the ideal HTML list.
|
Core | |
| 1.2 | Allow all the core elements and core attributes to be added (via any means, i.e. they aren't removed during editing or on save). (NB: Score out of 20 from the two tables.) To do: test page with all the valid core elements/attributes. |
Core | |
| 1.3 | Allow all the extra elements and extra attributes to be added (via any means, i.e. they aren't removed during editing or on save). (NB: Score out of 10 from the two tables.) To do: test page with all the valid extra elements/attributes. |
Extra | |
| 1.4 | The default allowed/removed HTML elements & attributes matches the ideal HTML list. | Extra | |
| 1.5 | Allows configuration of custom classes for styling elements within the editor. (CSS import ideas.) | Core | |
| 1.6 | Uses dynamic style selection based on the selected element. | Extra | |
| 1.7 | Allows a configuration to produce either HTML or XHTML. (Score 1 if this is supported, score 2 if it actively converts content.) |
Extra | |
2. Interface - Adding elements
| Requirement | Level | Score | |
|---|---|---|---|
| Total: | |||
| 2.1 | The interface allows the publisher to include all the core elements and core attributes via the interface, using valid code (see Adding structural code).
(NB: Score out of 20 from the two tables.) |
Core | |
| 2.2 | The interface allows the publisher to include all the extra elements and extra attributes via the interface, using valid code.
(NB: Score out of 10 from the two tables.) |
Core | |
| 2.3 | Separate block and inline elements in the interface (see Adding structural code). | Extra | |
| 2.4 | Paragraphs are created with 'enter', and line breaks with shift-enter. Pressing space does not create non-breaking spaces. |
Extra | |
| 2.5 | Blockquotes are created with a 'quote' button, not an indent button. If there is an indent/outdent button, it applies a class to achieve the effect. |
Core | |
| 2.6 | Both blockquote and q encourage a cite (URL only) as a property of that element. |
Extra | |
| 2.7 | There is a warning for nested blockquotes. | Extra | |
| 2.8 | Nested lists can be created (e.g. with tab), and are valid HTML. Checks for different variations of nested lists, e.g. ol within a ul. |
Core | |
| 2.9 | Adding an acronym or abbr opens a dialogue to add it's title. |
Extra | |
| 2.10 | There is a warning for potentially poor link names. | Extra | |
3. Complex elements
| Requirement | Level | Score | |
|---|---|---|---|
| 3.1 | Adding image dialogue does not include extraneous elements (e.g. border, spacing etc.) NB: width/height attributes are allowed, but should be automatic. |
Core | |
| 3.2 | Adding image dialogue does include location (or a selection mechanism), alternative text, and (optionally) a style drop-down that selects a class. | Core | |
| 3.3 | Images cannot be re-sized within the editor (unless the re-sizing actually re-saves the image). | Extra | |
| 3.4 | There is guidance for good alt text available with the image-adding interface. |
Core | |
| 3.5 | There is a warning for potentially poor alt text (e.g. ending with '.jpg'), and spell check on the text. |
Extra | |
| 3.6 | There is a warning for potentially poor heading use. | Extra | |
| 3.7 | If an image library is used, allow the author to change the alt text before including. |
Extra | |
| 3.8 | Images (primarily jpegs) are processed on upload to fit a configured size and quality limit. | Extra | |
| 3.9 | Table cell properties (those allowed) should be available from a context menu. | Extra | |
| 3.10 | Authors can upload a folder or zip-file of images, and the editor provides an interface to add/edit the alternative texts. | Extra | |
| 3.11 | Adding table dialogue does not include extraneous/presentational attributes (e.g. border, alignment, spacing/padding.) | Core | |
| 3.12 | Table must include a method for the author to identify which row/column is made a heading. A good default would suffice, e.g. only the top row is a heading. |
Core | |
| 3.13 | Tables have several pre-set structures/styles. | Extra | |
| 3.14 | Table properties can be edited after creation, e.g. swapping the structure or style. | Extra | |
| 3.15 | Editor can import data from a CVS or similar file, then allowing editing of table structure/style. | Extra |
4. Interface accessibility
| Requirement | Level | Score | |
|---|---|---|---|
| 4.1 | Each element of the interface must be perceivable, i.e. available to screen readers for adding/editing the core elements and core attributes. In practice this means that icons have suitable alternatives.
(NB: Score out of 20 from the two tables.) |
Core | |
| 4.2 | Each element of the interface must be perceivable, i.e. available to screen readers for adding/editing the extra elements and extra attributes.
(NB: Score out of 10 from the two tables.) |
Core | |
| 4.3 | Each core element and core attribute of the interface must be keyboard accessible (without needing a screen reader).
(NB: Score out of 20 from the two tables.) |
Core | |
| 4.4 | Each extra element and extra attribute of the interface must be keyboard accessible (without needing a screen reader).
(NB: Score out of 10 from the two tables.) |
Core | |
| 4.5 | The editor provides a usable mechanism (or allows access device mechanisms to work) for going from the editing interface to the control bar(s). | Core | |
| 4.6 | Ensure that user-style sheets and system settings apply to the editing interface (i.e. the content area) in the same way as the final content. | Extra | |
| 4.7 | Include a skinning mechanism for the interface, and make available an example high-contrast, large-size skin. | Extra | |
| 4.8 | Ensure that the content area can be navigated in the same (accessible) fashion as the final content. (e.g. that screen reader short-cuts like skipping through headings work.) To do: check that this is possible/practical. | Extra | |
| 4.9 | Allow the author to search within the content, and move to the location of the found item. | Extra | |
| 4.10 | Provide user-set accesskeys.
(NB: Only core so that implmenting arbitary accesskeys scores -1.) |
Core |
NB: The accessibility of the interface posts weren't particularly covered in the blog posts (as there is only one that I know of so far), but are well covered in ATAG V1's techniques. This last section is probably the most in need of development.
Core Elements
To do: There are some 'test pages' to be produced, one of all the allowed elements, on of all the disallowed elements, and one of all the extra elements. Could also do with some custom CSS to apply to each test page post 'save', which highlights issues.
Each of the following tables scores 1 for each supported element/attribute in each of the ways it is supported, and -1 for each that is not supported.
Items marked with an asterisks (*) might not be directly manipulated within the interface, but added/changed by an indirect process. Basically, they shouldn't be filtered out (so score +/-1 for 'Is allowed?'), but score 0 or 1 for the remaining 3 columns. Theoretically an editor could score over the maximum, in which case the score is the max score.
Some elements are grouped together, all of the group should be supported to score +1.
Add one point for each supported element. For each total score, make it out of 10. E.g. for 9/29 do: 9/29 * 10 = 3.1 (and round to nearest integer) = 3.
| Element | Is allowed? | In interface? | Perceivable? | Keyboard? |
|---|---|---|---|---|
| Totals | /24 | /18 | /18 | /18 |
a |
||||
abbr |
||||
acronym |
||||
blockquote |
||||
br * |
||||
dl, dd, dt |
||||
em |
||||
h1 - h6 |
||||
hr |
||||
img |
||||
ul |
||||
ol |
||||
li * |
||||
p |
||||
span * |
||||
strong |
||||
sub |
||||
sup |
||||
table |
||||
caption * |
||||
colgroup, col * |
||||
tbody |
||||
thead, tfoot* |
||||
td, tr |
||||
th * |
NB: A br element would not have a button as such, but should be creatable via the keyboard (e.g. shift-space).
Core Attributes
| Attribute | Is allowed? | In interface? | Perceivable? | Keyboard? |
|---|---|---|---|---|
| Totals | /18 | /11 | /11 | /11 |
class |
||||
id |
||||
title |
||||
dir |
||||
div * |
||||
lang |
||||
href (on a) |
||||
cite (on blockquote) |
||||
span (on col) * |
||||
alt (on img) |
||||
src (on img) |
||||
archive, classid, codebase, codetype, data, declare, standby, type (on object) * |
||||
name (on map, object or param) * |
||||
type , value, valuetype (on param) * |
||||
summary (on table) |
||||
axis, scope (on td or th) * |
||||
colspan, rowspan (on td or th) |
||||
headers (on td or th) * |
Extra Elements
These are not considered as essential as the 'core' elements, but none the less useful in some circumstances, as you can tell by the weighting.
For each total score, make it out of 5. E.g. for 9/20 do: 9/20 * 5 = 2.25 (and round to nearest integer) = 2
| Element | Is allowed? | In interface? | Perceivable? | Keyboard? |
|---|---|---|---|---|
| Totals | /12 | /9 | /9 | /9 |
address |
||||
area * |
||||
cite |
||||
code |
||||
del |
||||
dfn, samp, var |
||||
ins |
||||
kbd |
||||
map * |
||||
object, param * |
||||
pre |
||||
q |
Extra Attributes
| Attribute | Is allowed? | In interface? | Perceivable? | Keyboard? |
|---|---|---|---|---|
| Totals | /11 | /7 | /7 | /7 |
charset, hreflang (on a) |
||||
coords (on a and area) * |
||||
rel, rev (on a) |
||||
alt, href, nohref, shape (on area) |
||||
cite (on del, ins or q) |
||||
datetime (on del or ins) |
||||
width, height (on img or object) * |
||||
imap (on img) * |
||||
longdesc (on img) |
||||
usemap (on img or object) * |
||||
abbr (on td or th) |