ACTION-24
suggest accessibility improvement for "Big issue" marker
- State:
- closed
- Person:
- Dan Connolly
- Due on:
- 2008-02-21
- Created on:
- 2007-11-16
- Associated Issue:
- ISSUE-26
- Related emails:
- {minutes} HTML WG teleconference 2007-11-06 [resend] (from mike@w3.org on 2007-12-11)
- Re: ACTION-24: suggest accessibility improvement for 'Big issue' marker (from ian@hixie.ch on 2007-12-03)
- ACTION-24: suggest accessibility improvement for 'Big issue' marker (from unagi69@concentric.net on 2007-12-03)
Related notes:
2007-11-16 22:23:18: http://www.w3.org/2007/11/01-html-wg-minutes#action05 [Dan Connolly]
2007-11-22 18:29:46: 1. in the editor's draft of HTML5, there are 6 CSS style rules which need to be translated from hexidecimal to named colors:
[1] pre.idl { border: solid thin; background: #EEEEEE; color: black; padding: 0.5em; }
[2] @media screen { code { color: rgb(255, 69, 0); background: transparent; } }
[3] .example { display: block; color: #222222; background: #FCFCFC; border-left: double; margin-left: 1em; padding-left: 1em; }
[4][5] .issue, .big-issue { color: #E50000; background: white; border: solid red; padding: 0.5em; margin: 1em 0; }
[6] .element { background: #EEEEFF; color: black; margin: 0 0 1em -1em; padding: 0 1em 0.25em 0.75em; border-left: solid #9999FF 0.25em; }
GJR is working on specific alternate proposals, which will be linked-to these notes
2. since the style rules defined for .issue and .big-issue are identical, no one (sighted or otherwise) can determine from the styling what is an "issue" and what is a "big issue"
3. the offer/attempt to add context using CSS-generated text (for example, using :before and :after to generate content which marks the beginning of a "big issue" and the end of a "big issue") is appreciated, but support for CSS-generated text is extremely spotty to non-existent; most GUI screen readers, which have to scrape the screen (technical term: create an on-screen model) of the page (in effect, a snapshot of the page as rendered at a particular time) in order to scrape the generated content, so as to expose it to a screen reader or refreshable braille display... since AT and UA support for CSS-generated content is poor to spotty, research is being conducted to ascertain what works with today's technologies... to this end, i have begun to mount some tests of generated content to gather hard data on support for generated content in screen readers - consult:
http://lists.w3.org/Archives/Public/www-archive/2007Nov/0062.html
to which a simple test document is attached:
http://lists.w3.org/Archives/Public/www-archive/2007Nov/att-0062/GeneratedContentAccess.html
the results of tests of this resource are archived in the following thread:
http://www.w3.org/mid/20071120023818.M89422@hicom.net
4. the inability of screen readers and other AT to detect background and foreground colors using hexadecimal or RGB values as a bug with several developers of open source assistive technologies (such as Orca and NVDA) and such functionality has been submitted as a "feature request" to major commercial AT developers; currently the capacity to detect font color changes to effect a vocal characteristics change is not supported by any of the screen reader developers or implementors -- however, the lead of the Orca project, Willie Walker, agreed that the capacity to detect changes defined with hex or rgb notation is an eminently implementable feature for a screen reader, and it
has been entered into the Orca bug queue
[Gregory Rosmaita]
2007-11-22 18:45:51: 1. what would be of great assistance would be semantic markers in the text of the HTML5 draft indicating inserted and deleted text, using <INS> and <DEL>, as well as considering encasing asides, ToDo, and other markers which currently use visual conventions to express their function, in the EM and/or STRONG elements, so that there are structural markers which are capable of communicating the state of the text -- rendered visually via the style sheet -- declaratively. of course, the EM and STRONG elements (and their sub-classed children) can be styled in whatever manner the editor desires, as long as that styling is tied firmly to semantic markers (which is why i suggest using EM and STRONG and not SPAN) -- EM and STRONG have meaning (for example, an ISSUE might be marked by an EM in the document source and styled however the editor wants, whilst a "big issue" could be marked using the STRONG element to identify it declaratively (rather than stylistically) as a "Big Issue" [Gregory Rosmaita]
2007-12-18 22:07:39: please update the due date, GR [Dan Connolly]
2007-12-18 22:15:48: GR, you're welcome to make a better estimate; meanwhile, I'm postponing to 10 Jan [Dan Connolly]
2008-01-23 17:51:13: I closed/withdrew this action w.r.t. the 1st WD of the HTML 5 spec, but I see there's an ongoing issue about accessibility of our WDs, so I'm re-opening this action under that issue. [Dan Connolly]
2008-02-15 00:49:39: postponing, and moving to Dan since he reopened it. :) [Chris Wilson]
2008-03-10 02:16:01: GR, feel free to re-open this, provided you set the due date in the future. [Dan Connolly]
Display change log.