ISSUE-26: accessibility/usability of HTML5 and W3C default stylesheets [W3C publications]

ISSUE-26: accessibility/usability of HTML5 and W3C default stylesheets [W3C publications]

http://www.w3.org/html/wg/tracker/issues/

Raised by: Gregory Rosmaita
On product: W3C publications

In the editor's draft of HTML5, there are 6 CSS style rules which need to be translated from hexadecimal 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. 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


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


4. 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"

Received on Monday, 3 December 2007 17:16:20 UTC