Re: let's leave editorial issues out of the tracker [was: ISSUE-26 ...]

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 

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:

results of simple test of CSS-generated content begins at:

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,

The more things are forbidden, the more popular they become.
                                               -- Mark Twain
Gregory J. Rosmaita:
     Camera Obscura:
        Oedipus' Online Complex:

---------- Original Message -----------
From: Dan Connolly <>
To:, "Gregory J. Rosmaita" <>
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]
> > 
> >
> > 
> > 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
> 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