W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2011

[Bug 13504] Automation-friendly mMarkup for flagging spelling, grammar, etc. errors and warnings

From: <bugzilla@jessica.w3.org>
Date: Tue, 02 Aug 2011 06:59:03 +0000
To: public-html-a11y@w3.org
Message-Id: <E1Qo8wR-0000yd-1Z@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13504

Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bhawkeslewis@googlemail.com

--- Comment #2 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-02 06:59:02 UTC ---
(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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 2 August 2011 06:59:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:43 GMT