- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Wed, 05 Dec 2007 00:07:37 -0500 (EST)
- To: Dan Connolly <connolly@w3.org>, <public-html-wg-issue-tracking@w3.org>,"Gregory J. Rosmaita" <oedipus@hicom.net>
aloha, dan! if you prefer, i'll close the "issue" and reassign it as an action item on me, but i do believe that the issue is not merely "editorial" but technical (which is why i categorized it as a "W3C Publications" issue, not an HTML5 issue) dan wrote, quoting me: > > In the editor's draft of HTML5, there are 6 CSS style rules which > > need to be translated from hexadecimal to named colors: and then dan commented: > "need" is a strong word; if we do in fact need to make this > change, you will please explain why in some detail. i have, but here goes again -- if one cannot detect the color values defined for background and foreground styling changes that specify a block or string of text as distinct from other blocks or strings of text, how is one to set rules for voice characteristics changes to indicate that that string of text is an issue, an example, or whatever the color coding is intended to convey? the problem is that one cannot set numerical values to set aural or tactile rules which respond to the hexadecimal or rgb values of a background and foreground color combination -- using color alone, even through the agency of stylesheets -- clearly violates the WCAG proscription against using color alone to convey meaning; simply because the color-coding is achieved via stylesheets, does not make the color-coding any more accessible than if it had been defined using the deprecated FONT element -- what is missing is the ability of ATs to allow the user to assign specific values for foreground and background color changes which signify that a string of text is an example, an issue, a big issue, inserted text, deleted text, comments/asides, etc. the reality of the situation, as i documented in ACTION 24 as well as ISSUE 26, is that there are NO screen-readers that can discern hexadecimal or rgb values, which means that -- in the absence of actual semantic markup, the draft is using color alone to convey information, which is a clear violation of WCAG1 and WCAG2 -- it matters not whether the background and foreground colors are controlled using the deprecated FONT element or via CSS -- simply separating presentation from content doesn't assist anyone, if there is no means for an AT to convey the stylistic changes which are intended to communicate to the user the status or meaning of the styling applied to a block or string of text... that is why i suggest a two-pronged approach: 1. use declarative markup attached to a specific style rule to indicate status of the text so marked as well as documenting explicitly the stylistic conventions used in the document 2. working with AT vendors to support recognition of numerical color values (there has already been buy-in to this, as noted in the tracker) these issues are larger than just the HTML5 Editor's Draft's stylesheet; most DIFF-marked versions of W3C documents use color alone to indicate changes between drafts -- if the color changes aren't perceptible to a screen reader, then the state/status of the text so marked cannot be communicated to the aural or tactile or monochrome monitor or color-blind user... simply using stylesheets to achieve separation of presentation from content isn't sufficient -- the styling has no meaning to a non-visual user or that user's AT that's why: a) i didn't mark the big issue versus issue action as closed, as i realize that there is going to be some-to-a-lot of negotiating over the ramifications of my findings b) i don't want to limit anyone's palette, but since this is an accessibility issue, and since trying to discern pseudo-semantics expressed via style rules is a documented problem with today's technologies, the W3C has an obligation, under WCAG, to make a reasonable accommodation -- i am more than willing to meet anyone half-way and not object to the use of numerical color values AS LONG AS there is actual markup in the document source that serves the same purpose -- semantic markers of a section of content with special meaning or status... c) i'm not a fan of the named colors chosen as named colors, but i don't have any control over that particular issue, which is why i have begun working on a proposed stylesheet revision there is also a need for reform of the DIFF marked documents in W3C space -- many use color alone to signify what has been deleted, what has been added, what is in danger of deletion, etc. -- it is also common practice in editors' drafts to DIFF mark text to indicate its status so as to provide a history of the development of the draft, but this is not being done with the HTML5 editors draft, where markup such as INS and DEL would be of inestimable aid in comprehending the differences between drafts, as well as the status of each segment of the draft in relation to working group consensus, notation of editorial changes, etc. nor have i concentrated on color-detection alone -- i have also addressed, and plan on addressing further, an implementation strategy which has been suggested -- the use of pseudo-elemental text to provide contextual markers and delimiters... i have also demonstrated that CSS-generated content -- which theoretically would ameliorate many of these issues -- is not very well supported, either by ATs or UAs, and even when one uses a user agent that does support CSS-generated content, it is not exposed to any non-visual renderer, such as a screen reader simple test of CSS-generated content: explanation: http://lists.w3.org/Archives/Public/www-archive/2007Nov/0062.html test: http://lists.w3.org/Archives/Public/www-archive/2007Nov/att-0062/GeneratedContentAccess.html results of simple test of CSS-generated content begins at: http://www.w3.org/mid/20071120023818.M89422@hicom.net let me know if you want me to re-class this as an action item, but i would ask you to note that it is not an editorial, but a technical issue which i have raised, gregory. ------------------------------------------------------------ The more things are forbidden, the more popular they become. -- Mark Twain ------------------------------------------------------------ Gregory J. Rosmaita: oedipus@hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ Oedipus' Online Complex: http://my.opera.com/oedipus ------------------------------------------------------------ ---------- Original Message ----------- From: Dan Connolly <connolly@w3.org> To: public-html-wg-issue-tracking@w3.org, "Gregory J. Rosmaita" <unagi69@concentric.net> Sent: Mon, 03 Dec 2007 21:26:45 -0600 Subject: let's leave editorial issues out of the tracker [was: ISSUE-26 ...] > This doesn't look like a design issue nor requirements issue. > > I'd rather use the issues tracker for technical issues > and not editorial issues like this. > > I don't mind if you assign yourself an action to work on this, > but I'd rather you didn't burden the whole WG with an issue. > > I'm inclined to close this issue without a WG decision. > I'll stand by for feedback for a day or so first. > > Also... > > On Mon, 2007-12-03 at 17:15 +0000, HTML Issue Tracking Issue Tracker > wrote: > > 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: > > "need" is a strong word; if we do in fact need to make this > change, you will please explain why in some detail. > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E ------- End of Original Message -------
Received on Wednesday, 5 December 2007 05:07:48 UTC