IBM HTML 5 Accessibility Review - contenteditable (Sections 7.5 and 7.6)

Michael,

Please update the spec. review WIKI (
http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review). This is IBM's review of
sections 7.5 and 7.6 of the contenteditable section:

http://dev.w3.org/html5/spec/editing.html#contenteditable

IBM has products in development and deployment that use both
contentEditable and DesignMode. I reviewed this section with those product
teams. We have the following issues:

Issue 1: Section 7.5 should be renamed "editing host" or something like
that as the name implies the section only applies to the contenteditable
attribute. The section should be reworked.

   Where it becomes confusing is designMode. designMode places the entire
   document in an editing mode and should also be considered an editing
   host.
   DesignMode (section 7.5.2) is a subsection of 7.5, the contenteditable
   attribute. Yet, 7.5.1 defines User Editing Actions. It is not clear that
   User Editing Actions apply to both contenteditable and designMode. I
   think we agree that it should and it is intended but that is now how
   section 7.5 is structured. Where this becomes important is that 7.5.1
   describes the user functions apply to an editing section. This is
   important for main stream clarification and for accessibility to ensure
   access to Editing Hosts. These also need to apply to designMode.
   Fortunately, the user functions (move the caret, etc.) are defined in a
   device independent way. 7.5 should be restructured as follows:

7.5 Editing hosts

Introductory text should state that this applies to elements having
contentEditable in the true state and design Mode in the enabled state.

7.5.1 contentEditable
7.5.2 designMode
7.5.3 User Editing Actions for Editing Hosts

Another approach could be to state that designMode="on" means the
equivalent of "contentEditable" being true as applied to the entire
document.

Issue 2: Section 7.5 The specification must mandate and specify consistent
navigation across browsers or at least across browsers on the same
platform.

Specifically, One of the major problems we see between different browsers
is how each one implements navigation and default editing (e.g. delete,
backspace etc.) differently. This has resulted in CKEditor implementing
special keyboard handling and strange DOM manipulations in order to try and
get the experience the same (or close to) between browsers. Here's a common
example: in IE, if the caret is at the end of a link and the user hits a
backspace, IE deletes the link but leaves the caret in the same position
with the text of the link unchanged. In FF, the backspace will delete the
last character in the link, preserving the link element.

This problem impacts people with disabilities, mainstream keyboard users,
developers that use editing hosts in the web applications.


Issue 3: 7.6 Spelling and Grammar checking, Spelling and Grammar checking
should be made available for designMode as well. By mentioning only the
contenteditable attribute when referring to a editing host the text gives
the inference that designMode is not applicable when in fact the entire
document becomes an editing host.

This text:

"User agents can support the checking of spelling and grammar of editable
text, either in form controls (such as the value of textarea elements), or
in elements in an editing host (using contenteditable)."

Should change to:
"User agents can support the checking of spelling and grammar of editable
text, either in form controls (such as the value of textarea elements), or
in elements in an editing host (using contenteditable or designMode)."


Rich Schwerdtfeger
CTO Accessibility Software Group