WYSIWYG editor spec – checklist

Posted in WYSIWYG editors.

After the 10 previous posts on WYSIWYG editors, I have compiled all the ‘tips’ into a checklist of things to look for in an editor. However, it’s pretty detailed! In an article, you can say “allow these useful elements, and disallow everything else”, but in a checklist, you have to be a bit more precise!

At this stage, I’d like to ask for any comments, questions or criticisms before I start applying it to editors.

You can scroll down for a link to the checklist, but I feel I have to outline the aim & what it is supposed to do, and hopefully prevent misunderstandings.

Aim and purpose

This checklist is intended to see how well a browser-based WYSIWYG editor will perform in terms of accessibility, usability and output code quality. An intended side-effect of this is that the people creating editors also use this to improve their products. (Creating an editor is a horrifically difficult thing to do, I’d like to make improving them easier.)

Please note: If you want general accessibility guidelines for other products that produce HTML, the best method would be to sue the W3C‘s Authoring tool guidelines. Although the domain is similar, this checklist is very specific and does not have nearly as wide a scope.

Going through the process of scoring an editor against this checklist should indicate how easily it will allow you to set up an accessible site for editing, and help authors (the people using it) to maintain accessibility.

It is not intended as a pass/fail, (although a very low or negative score is not a good sign), so I’m not going to set a score that should be achieved. Although a few items are considered ‘core’ (i.e. if these are not in place, the output is almost certain to be inaccessible), most editors should get a positive score. These things are relative, and with a few tests completed, I should be able to set up a table of results to compare editors, and allow people to make an informed choice.

Process

The document itself is intended to be saved off, filled in and posted, the instructions are on it. Results for the same editor between different people should be very similar, although it is likely that the largest variance will be due to how well people manage to configure the editor. (You could test the default set-up, but the scores are likely to be very poor at the moment).

It’s published under a creative commons license, so others are welcome to use it to publish their results if they wish to.

No one test of an editor should be considered final, and with comments and suggestions we can figure out how to get the best out of each editor, and hopefully feed that back into their development.

Last call…

There are a couple of to-do items left in the checklist (HTML test cases), but I’d like to ask for comments now in case I’ve missed something vital! Please feel free to leave a comment below, or email me (ac at this domain) and I will endeavor to update the checklist.

Without further ado, here it is: The WYSIWYG editor checklist.

10 contributions to “WYSIWYG editor spec – checklist”

  1. #1.1 – should be re-written:

    Does not generate or has the facility to remove elements and attributes not on the best-practice X/HTML list.

    #1.7 – there is absolutely no need for this. HTML 4 templates can support XHTML content. The article The XHTML Way I wrote a few years back talk about this.

    #2.3 – don’t know if I agree with this. But in XStandard you can group Styles in the Styles menu so this is possible if one feels this is necessary.

    #2.7 – not necessary if the user is not misled to use blockquote for indent. #2.5 should take care of this.

    #2.8 – The TAB key must be used for form navigation otherwise the editor will not be keyboard accessible.

    #2.9 – Only if the title for this abbreviation is not already defined on the page. You don’t want assistive technologies to read out the title for an abbreviation again and again.

    How about things like:

    – Distinguish between data and layout tables. Layout tables should not contain th, caption, thead, tbody, tfoot, summary attribute or header/cell associations.

    – Separate content from formatting – no inline CSS or font

    – Generate markup according to specification (ie: valid markup)

    – Ability to identify images as decorative or informative. If an image is decorative, the author should not be able to enter alt, title or longdesc.

  2. Hi Vlad,

    Thank you very much for taking the time to read it through and comment. On the specific points I’ll read through in detail an either make updates, or comment back here.

    With regards to the more general points at the end:

    • I was running under the assumption that layout tables would not be allowed, but I realise that isn’t explicit in the checklist (although it is in an earlier article). I’ll make that explicit.
    • Inline CSS and fonts (and others) should be removed with checkpoint 1.1. Do you think this should be added to elsewhere?
    • Apart from removing unrecognised elements & attributes, are there other checks I can add for valid markup? Perhaps add an HTML check after 2.2
    • I thought about decorative images, but couldn’t see a use-case for a content area image to be decorative.

  3. Responding to Vlad:

    1.4 Some things allowed in XHTML Family documents aren’t valid in HTML (such as embedding SVG, MathML and suchlike). Also, XHTML templates cannot contain some things which are valid in HTML. For example, <br> would not be well-formed and must be closed explicitly in XHTML.

    Incidentally, some of the other information in “The XHTML Way” isn’t quite right. For example, XHTML labelled as text/html is always slightly slower than the equivalent HTML.

    2.9 When the title attribute is on every <abbr>, users can choose to get the expansion at any point in the document. Such as by using the mouse or a command in their screen reader. If the title attribute is only used on one <abbr>, users can only get the expansion by querying that one instance.

    In some cases it may be desirable to get the expansion every time in a screen reader. For example, “vs” to be read out as “versus” every time in a long page of sports fixtures.

    If users don’t want every instance of every abbreviation to be expanded, they can configure their device not to expand them, or to only expand them at the user’s request. I believe this tends to be the default setting.

    If a content author wishes to provide an expansion which is always read out, it can be expanded in the content. Using “CSS” as an example:

    Cascading Style Sheets (CSS) would be done like that, in the same way a book would.

    This makes the expansion available to sighted users who don’t understand what a dotted underline means…which is everyone except markup enthusiasts! 🙂

    Alternatively (or additionally), the website could provide a glossary where all shortened or otherwise exotic terms can be expanded and defined.

  4. Hi Ben,

    Could you point me to some more info on:

    XHTML labelled as text/html is always slightly slower than the equivalent HTML.

    I would have thought browsers either treat it as HTML and it’s the same, or as XHTML/XML, and that shouldn’t be slower, surely?

    Regarding acronyms, I don’t think that it should be dictated how acronyms are used. It is fine (according to WCAG) to expand it in the content in the first instance and not use acronym at all.

    The point of that check was to say: if the author wraps something in an acronym, they should be prompted to provide the full expansion.

    The default handling on apps like Jaws is not read out the title by default. I would have thought it should be to indicate the presence, e.g. with a ‘ding’, and the user can then read it, but unfortunately that isn’t an option (yet).

    If adding acronyms to everything was a desirable thing to do, then an integrated glossary/acronym generator would be the way to go, but that is somewhat beyond the scope of an editor.

  5. I’ve modified the checklist: this is the current draft version. The drafts have a change-log at the bottom, which will be removed when the ‘index’ is updated. I’m also tracking additions/removals with ins & del.

    The only outstanding thing is that I’m not clear on why the tab should not be used, I’m hoping you could explain that Vlad?

  6. Ben, all I am saying is that if an authoring tool generates XHTML in a backwards compatible way, then there is no need to have a “configuration to produce either HTML or XHTML”. The backwards compatible XHTML will work in HTML and XHTML templates. This is what XStandard does. Maybe the wording for this checklist item needs to be re-written?

  7. The only outstanding thing is that I’m not clear on why the tab should not be used, I’m hoping you could explain that Vlad?

    I added by comments about this in the adding structural code post.

    Here is a question. You have a Web page with a textfield, WYSIWYG editor and submit button. The WYSIWYG editor has 20 buttons on the toolbar and contains very long document which inludes tables, lists, images, etc. How may times should an author press the TAB key to navigate to the submit button? And why should this number be different is the WYSIWYG editor was replaced by another control such as a multi-line textarea?

  8. I had thought that including a self-closing ‘slash’ on elements in HTML was invalid, but just testing now, it is only on head elements that it is invalid.

  9. Thank you for creating such a valuable resource. Your timing is perfect – we have just started an evaluation of the WYSIWYG editors supported in the recent version of Interwoven’s TeamSite: Ektron and TinyMCE.

    I hope you don’t mind if I include my comments for the entire series here, since many are discussed in more than one installment.

    I agree that users should not be given an opportunity to manipulate image dimensions, but the image widget should generate the actual dimensions. It has great value for prompt page loading and rendering.
    I could not find anything on forms. We give our users the ability to use shared scripts to capture data with a web form, so it seems reasonable to give them the ability to create the forms as needed! If they do, the editor should ensure that they are creating and using labels properly, that they are using form CSS instead of layout tables, etc.
    Ahh, indenting… Nested lists… Our current editor uses the indent/outdent buttons to create blockquotes (agreed that this is Bad!) but also uses it to do list nesting if the focus is on a list item or one or more list items are selected. This dual behavior is very intuitive and easy, and I would fear violence if we ever tried to take it away
    Checklist:

    4.9 should include replace as well as search as an extra.
    Core Elements NB: br is usually shift-enter rather than shift-space – or did you mean nbsp?
    Core Elements tables: From what I’ve seen of WYSIWYG editors, you can either include/exclude tags and elements, or you can’t. Other than testing out-of-the-box functionality, you would be giving the same values for each in each column. That being said, don’t remove them! I hope to use them as development checklists.

    Again, thank you for putting this effort in. I plan on sharing this with other concerned people in Mass. state governmemt as soon as you get your doamin situation squared away!

  10. Hi Sarah,

    Thanks for that, on the specific points:

    • I won’t penalise either way, but I think there is a case for doing dimensionless images. They are easier to handle with CSS when they don’t have dimensions, and can be re-used more easily.
    • I didn’t cover forms because I’ve not come across a WYSIWYG editor that does them, and I’m not convinced they should be part of an editor. A CMS perhaps, but separately from the editor.
    • Thanks for the support on the use of tab, I fear the same thing!
    • On 4.9, good point.
    • On br, thank you, that was a typo.

Comments are closed.