- From: <bugzilla@jessica.w3.org>
- Date: Mon, 01 Aug 2011 21:14:18 +0000
- To: public-html@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13504
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 on the CC list for the bug.
Received on Monday, 1 August 2011 21:14:20 UTC