This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
Spec Review/Editing
Under review:
Contents
Rich Schwerdtfeger
Title for section
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.
Rich to file bug Bug 13416
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.
Rich to file bug Bug 13429
Spelling and grammar in designMode
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 to file bug Bug 13431
Greg Lowney
Use case: Nadia is editing text on a web page, in a textarea or an element with contenteditable=true. Her browser's spelling checker is turned on, and the region has the spellcheck=true, so when the browser's spelling checker marks up spans with a red, wavy underline to indicate what it thinks is a spelling error, and a green, wavy underline to indicate what it thinks is a grammar error. Following the advice in the HTML5 spec (4.6.19 The mark element), the browser marks up these phrases with u elements, distinguishing them using different classes. Unfortunately, these classes are meaningless to Nadia's screen reader, which is unable to distinguish them from ordinary underlines; that is, it has no idea what the classes mean, and whether they have semantic meaning or merely stylistic effects. If only they were marked up in a standardized way, her screen reader could use spoken phrases, audio icons, or inflections to indicate which ranges were flagged as spelling errors, etc.
Recommendation: HTML5 should define a standardized mechanism for marking up phrases flagged by a spelling checker or the like, so that content scripts or assistive technology could react to them intelligently. One option would be to extend the mark element with one or more new attributes, such as a flag attribute with enumerated type whose values could be spelling (e.g. "generral") or grammar (e.g. "He run"), or syntax (e.g. coding errors such as end if without preceding if), and also a meaning attribute that could use set to a user-friendly string that would convey the meaning of the markup to the user (e.g. <mark meaning="Character Set"> in a multilingual editor, or <mark meaning="Break Point"> in a debugger). Alternatively, a new element could be created for this purpose, rather than extending the use of the mark or u elements. (It's also worth noting that the important aspect of these indicators is *not* that they're underlines, but that they're spelling or grammar errors, and therefore using the u element is really inappropriate.)
Greg to file bug Bug 13504
Andrew Kirkpatrick
Spellcheck example
The current text reads:
The element with ID "b" in the following example would have checking enabled (the leading space character in the attribute's value on the input element causes the attribute to be ignored, so the ancestor's value is used instead, regardless of the default).
<label>Name: <input spellcheck=" false" id="b"></label>
Recommend change to “The element with ID "b" in the following example would have checking enabled when a user enters a value into the rendered input control” It is a little confusing that the input is checkable but there is nothing to check.
Bug 13519 but did not add a11y keyword, appears to be editorial
Moving the caret with the keyboard
The sections under 7.5.1 Move the Caret and Change the selection provide this as a vague indication of potential keyboard support:
“This could be triggered as the default action of keydown events with various key identifiers and as the default action of mousedown events.”
It is desirable to make this more explicit, so UA's are aware that support for interaction without a mouse is a requirement.