ACTION-24: suggest accessibility improvement for "Big issue" marker

http://www.w3.org/2007/11/01-html-wg-minutes#action05

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

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"

please update the due date, GR

GR, you're welcome to make a better estimate; meanwhile, I'm postponing to 10 Jan

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.

postponing, and moving to Dan since he reopened it. :)

GR, feel free to re-open this, provided you set the due date in the future.