[html4all] a11y issues with HTML5 draft and W3C default stylesheets

[Gregory J. Rosmaita]

aloha, josh!

apologies for the brevity of my (initial) reply, but i have to 
answer an emessage from dan with the subject line: "let's leave 
editorial issues out of the tracker"

http://www.w3.org/2002/02/mid/1196738806.3767.60.camel@pav

but i wanted to at least touch upon the topics/questions you raised in 
relation to CSS-generated content

the type of CSS-generated text to which i referred is that defined in 
the CSS 2.0 technical recommendation, in particular, section 12, 
"Generated Content, Numbering, and Lists":

http://www.w3.org/TR/CSS2/generate.html

in a concept which is closely akin to the cue-before and cue-after aural 
properties of CSS2:

http://www.w3.org/TR/CSS2/aural.html#propdef-cue-before
http://www.w3.org/TR/CSS2/aural.html#propdef-cue-after

through the use of the ":before" and ":after" pseudo-elements, it is 
possible to -- quite literally -- add "content":

.issue:before { content: "Issue: "; }
.example:after { content: "end Example"; }

or, in an example from section 12 of CSS2:

<begin quote 
  cite="http://www.w3.org/TR/CSS2/generate.html#before-after-content">

BODY:after {
    content: "The End";
    display: block;
    margin-top: 2em;
    text-align: center;
}

Note that an audio user agent would speak the words "The End" after 
rendering the rest of the BODY content.
<end quote>

in the area of accessibility and general usability, these pseudo-elements
can be used to add contextual text to a document instance via a 
stylesheet, information which "normally" doesn't need explicit markers -- 
such as text which is styled uniquely to communicate to the viewer 
contextual information about a block or string of text by creating a 
visual shorthand which is then reused on the page (for example, this is 
an example, this is text marked for deletion, etc.) -- so, it has been 
viewed (and was viewed when CSS2 was in review) that it is an 
"unobtrusive" means of adding contextual information to documents for 
users, without affecting the aesthetics of the visually rendered document 
instance...

i think that the UAAG example illustrates the concept from a number of 
facets -- a textual string, marked with the "lang" attribute to 
declaratively express that that string of text is in a different language 
than the natural language declared for the page -- in many cases, the 
user agent and/or operating system may not support the character-set for 
the string of text marked as thai, and may only be able to render only 
visual garbage in place of individual thai glyphs, so the user doesn't 
readily know anything about the string of text, other than that it is 
unintelligible...  a quick and easy means of providing a repair mechanism 
for such a scenario is to explicitly mark the text with CSS-generated 
text, such as "Being Thai" and "End Thai" -- or, in the case of the HTML5 
draft, "Issue" and "Big Issue" (although as i have pointed out, since the 
style rules for both .issue and .big-issue are the same, no one can tell 
the difference, and only some of us can tell that there is an issue by 
the red box containing red text on a white background, AND, as i've also 
pointed out, i'd rather have issues and big issues explicitly marked up 
in the document source of the draft, the former with EM and the latter 
with STRONG, as a reinforcement of the concept of what EM and STRONG 
actually semantically signify, rather than the common misconception that 
EM equals italics, and STRONG bold)

the problem, of course, is that CSS-generated text is NOT included in 
the DOM -- something i've been complaining about to anyone who'll listen
(and plenty who don't want to listen), since the days of drafting the 
first round of the WAI troika/trinity -- if pseudo-elemental information
is going to be used to, for example, control the punctuation and symbols
in a list, so that that list has the structure and typography of a 
legislative document, or to provide content in response to a user or 
script activated/initiated event, or as a repair mechanism for documents 
that rely on color alone to convey context, then CSS-generated text MUST 
be included in the DOM (especially the "DOM Core"), so that it is 
programmatically available to an AT and/or user agent; i failed to get 
such a requirement into UAAG 1.0, but during the TPAC sessions of the 
UAWG, it was agreed that in UAAG 2.0, whenever content is generated, 
either by CSS or script, it must either be included in a UAAG compliant 
browser's DOM or exposed directly to the appropriate accessibility API 
for communication to the user via an AT

CSS-generated content could/should also be used in conjunction with actual
semantically meaningful elements, such as INS and DEL, which SHOULD be 
used in each editor's draft to indicate new text and text marked for 
deletion -- and, of course, there should be an explicit documentation of 
the stylistic conventions used in the draft in the introductory materials

i'm neither promoting nor panning the use of CSS-generated text -- 
although i have no reservations formally stating for the record that i
vastly prefer CSS-generated (and, hence, user-controlable) content to 
scripted content -- but am merely attempting to discern the advantages
and shortcomings of all CSS-generated content in relation to today's 
technology; in particular, those ATs and user agents that are available 
for use and are in use now -- MSIE, as many of you may know, does NOT 
support CSS pseudo-elements, for example, and the research i've been 
conducting via wai-xtech shows very weak support for exposition of CSS-
generated content in existing configuration options (browser plus 
operating system plus assistive technology)

of course, i am merely scratching the surface of the issue with this 
hurriedly composed post, but i hope that what i've written (a) makes 
sense and (b) helps provide some context for what i am hoping will be a 
collaborative effort that will benefit not only the HTML5 draft, but all 
W3C templates, as well as applying techniques documented in WCAG2 to the 
W3C style guide, in order to ensure that all W3C publications are as 
accessible as possible by default...

gregory.
------------------------------------------------------------
The more things are forbidden, the more popular they become.
                                               -- Mark Twain
------------------------------------------------------------
Gregory J. Rosmaita: oedipus at hicom.net
     Camera Obscura: http://www.hicom.net/~oedipus/
        Oedipus' Online Complex: http://my.opera.com/oedipus
------------------------------------------------------------