This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. 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: 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.)
(In reply to comment #0) > 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. This issue was also brought up in relation to canvas-based rich text editing and other custom IMEs. [ http://www.w3.org/Bugs/Public/show_bug.cgi?id=11238 ] These mechanisms are already in place when native components are used, though they are not exposed to the scripting environment due to security concerns. A malicious script might be able to identify custom dictionary entries and otherwise fingerprint the client machine based on the identification of mis-spellings. As for custom widgets: ARIA supports marking of invalid spelling and grammar ranges. http://www.w3.org/TR/wai-aria/states_and_properties#aria-invalid That handles our DOM commitments regardless of the visual presentation. Hironori Bono has been working on IME proposals for awhile, and has been testing, within WebKit, spell checking as managed by the scripting environment. He proposed several new interfaces including window.spellCheckController and SpellcheckRange. https://lists.webkit.org/pipermail/webkit-dev/2011-June/017242.html http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0545.html
(In reply to comment #0) > 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. This doesn't make sense. Browsers clearly neither need nor should modify the DOM to indicate spelling mistakes. For example, lots of browsers highlight spelling errors in textarea controls without modifying the DOM. In the case of at least Safari and VoiceOver, this spellchecking service is well-integrated with AT so that the screen reader announces misspellings as such.
(In reply to comment #0) > 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. HTML5 includes ARIA support and ARIA support includes aria-invalid, which meets this requirement specifically for spelling and grammar errors, and could be extended by WAI to include syntax errors. http://www.w3.org/TR/wai-aria/states_and_properties#aria-invalid
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>. Status: Rejected Change Description: no spec change Rationale: As comment 2 and comment 3 point this is not actually an issue.
Discussed in Bug Triage sub-team decided to agree with comments and conclusion that this isn't an issue we need to track.