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.

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!

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?

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?

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.

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.

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.

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.