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

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 01 Aug 2011 21:14:18 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-13504-2486@http.www.w3.org/Bugs/Public/>

           Summary: Automation-friendly mMarkup for flagging spelling,
                    grammar, etc. errors and warnings
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: a11y, a11ytf
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: gcl-0039@access-research.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-html-a11y@w3.org

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.)

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 1 August 2011 21:14:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:15 UTC