- 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