Accessibility issues in CSS3 Colour

REPLIES GO TO: www-style@w3.org
(Eudora won't let me set that myself-- I hate it when Eudora 
embarrasses me like that)

Al Gilman wrote me to ask:

>Would you have the time or interest to review this module and see if 
>they have broken, or failed to add, anything that is needed for 
>accessibility?

I have only a couple of comments, but a few of them are biggies.

>  4.4. CSS System Colors
>
>     4.4.1. CSS2 User preferences for colors

I have disputed the need for system colours in the first place 
(you'll see it in the "Type & Colour" chapter of my upcoming book, 
_Building Accessible Websites_ <http://joeclark.org/book/>). I am not 
convinced it is a good idea to make Web sites or Web applications 
look like native-operating-system applications. I just don't see the 
need, and I am reminded of designers who make banner ads or even 
graphical Submit buttons look just like MS Windows or Mac OS X 
buttons. And Mozilla developers went to extreme lengths to design 
their own user interface for forms widgets, including menus and 
buttons, which exactly contradicts the ethos of system colours even 
though it results in very odd-looking interfaces on Macs. There is no 
clear need for system colours, and they are poorly implemented.

In any event, given the W3C's principle of device independence--

<http://www.w3.org/TR/2001/WD-di-princ-20010918/#section-Goals>

>The goal of this document is to suggest that Web content and 
>applications can be authored, generated or adapted for a better user 
>experience when interacting with presentations via many different 
>Web-connectable access mechanisms. The general phrase "device 
>independence" is used for this, although the access mechanisms may 
>include a diversity of devices, user agents, channels, modalities, 
>formats etc.

-- there are a few additional forms of system colours that need to be 
added. I would point out that system colours already defined seem to 
indicate a narrow focus on application development (e.g., window 
colours). That is, application developers figure "These are the only 
system colours anyone could possibly ever need."

But we can think of a couple of access-related system colours:

	* Highlights for low-vision people (screen magnification 
and/or colour substitution)
	* Subtitle and caption colours


HIGHLIGHT COLOURS

You already have ~4 system highlight colours. I could suggest adding:

	ZoomHighlightForeground
		Colour for foreground when using display magnification.
	ZoomHighlightBackground
		Colour for background when using display magnification.
	ZoomPerimeter
		Colour for outside edging of magnified area during 
display magnification.
	ReverseColourForeground
		Foreground colour used during reverse display.
	ReverseColourBackground
		Background colour used during reverse display.
	SubstituteColourForeground
		Foreground colour used during substituted-colour display.
	SubstituteColourBackground
		Background colour used during substituted-colour display.

Rationale:

Low-vision users can zoom the display on their computers or other 
devices. They may wish to alter the underlying original colours to 
make the zoomed version easier to read-- typically there will be a 
rounding up to simple black-and-white. They may wish to add a 
different colour around the edge to delineate that edge.

Example:

	ZoomHighlightForeground = white
	ZoomHighlightBackground = black
	ZoomHighlightBackground = white

This gives you white text (and other content) on a black background 
with a white border.

Or:

	ZoomHighlightForeground = yellow
	ZoomHighlightBackground = black
	ZoomHighlightBackground = gray

Now, it is possible that you have a colour deficit but have adequate 
visual acuity. You may wish to simply invert the colours displayed on 
your screen. Usually this will mean two steps: (1) simplify colours 
by reducing the variety of colours and (2) change to white on black 
(remember, without magnification this time). But you could set any 
colours you wanted, like white on blue if you remember and liked the 
old DOS WordPerfect colours. Example:

	ReverseColourForeground = white
	ReverseColourBackground = black

Or your system may use more complicated logic that will *substitute* 
specific colours for other colours. If you have a red-green 
colourblindness (usually protanopia or deuteranopia), you may want 
everything red to become blue and everything green to become purple. 
You could then use:

	SubstituteColourForeground(red) = blue
	SubstituteColourBackground(green) = purple

(In all these examples, exactly how you configure your software or 
adaptive technology to do this isn't the Working Group's problem. 
We're just setting variables.)

Reversing and substituting colours apply display-wide, hence we don't 
need an edging colour.


CAPTIONS AND SUBTITLES

First of all, the two are not the same.

	<http://joeclark.org/understanding.html#cc>
	<http://joeclark.org/understanding.html#st>

Captions are visible words that transcribe the dialogue and other 
important sound effects, move to indicate speakers, and use other 
forms of speaker identification. Intended audience is deaf (though in 
practice more hearing people watch captions in North America 
<http://joeclark.org/hearing-maj.html>). Subtitles are visible words 
that translate dialogue and occasional onscreen type. Intended 
audience is hearing.

I define "accessibility" to include accommodating any characteristic 
a person cannot change or cannot change easily. I am aware this is a 
more sweeping definition than disability-obsessed advocates 
particularly like, but just as you can't stop being deaf when you 
want to watch _Run Lola Run_, you can't suddenly start to understand 
German, either.

And actually, the W3 definition is compatible with mine:

<http://www.w3.org/WAI/GL/Glossary/Overview#A>

>>Accessibility
>>
>The art of ensuring that, to as large an extent as possible, 
>facilities (such as, for example, Web access) are available to 
>people whether or not they have impairments of one sort or another.


Moreover, it is quite possible to have separate captions and 
subtitles-- often in the same language-- on a single program or film. 
So we have to consider them as two peas in a pod.

Now, in furtherance of the goal of device independence *while also* 
providing increased compatibility with devices we already know exist, 
I am suggesting the addition of a few system colours. They deal with 
foreground, background, mask (background area extending well beyond 
the characters themselves), and edging (shadow on characters-- 
already found in system colours). I'm using the term "character" 
rather than "display element" here, since the latter is overly 
general and hard to understand in this context. The "mask" colour 
would extend well beyond the character bounding box, e.g., the bottom 
third of the screen could be grey.

Device-independent tokens:

	CaptionForeground
		Foreground colour for caption characters.
	CaptionBackground
		Background colour for caption characters.
	CaptionMask
		Colour for large background region behind caption characters.
	CaptionShadow
		Colour for edging or shadow on caption characters.
	SubtitleForeground
		Foreground colour for subtitle characters.
	SubtitleBackground
		Background colour for subtitle characters.
	SubtitleMask
		Colour for large background region behind subtitle characters.
	SubtitleShadow
		Colour for edging or shadow on subtitle characters.

The above tokens provide compatibility with:
	* Any generic subtitling or captioning system
	* Analog captioning (Line 21 or 22; World System Teletext), 
which really only has
	foreground and background colours (no mask or shadow)

You'd use language codes to differentiate captions and subtitles in 
various languages. No need to reinvent that wheel.


Device-specific tokens:

Here we provide compatibility with

	* DVD (four available colours).
	* U.S. digital television (see notes).

There is no compatibility for European digital television because 
subtitles and captions are sent as bitmaps. Searching the available 
standards documents <http://pda.etsi.org/pda/home.asp?wki_id=3653> 
(you need to register; but try 
<http://pda.etsi.org/exchangefolder/ets_300743e01p.pdf>) shows next 
to nothing to do with colour. It seems to be unselectable by the 
viewer. In any event, the generic tokens above could be used.


	DVDB
		DVD Background colour.
	DVDP
		DVD Pattern colour.
	DVDE1
		DVD Emphasis 1 colour.
	DVDE2
		DVD Emphasis 2 colour.

	DTVForeground
		Foreground colour for DTV characters.
	DTVBackground
		Background colour for DTV characters.
	DTVMask
		Colour for large background region behind DTV characters.
	DTVShadow
		Colour for edging or shadow on DTV characters.
	DTVEasyForeground
		Foreground colour for easy-reader DTV characters.
	DTVEasyBackground
		Background colour for easy-reader DTV characters.
	DTVEasyMask
		Colour for large background region behind easy-reader 
DTV characters.
	DTVEasyShadow
		Colour for edging or shadow on easy-reader DTV characters.
	DTVWideForeground
		Foreground colour for wide-aspect DTV characters.
	DTVWideBackground
		Background colour for wide-aspect DTV characters.
	DTVWideMask
		Colour for large background region behind wide-aspect 
DTV characters.
	DTVWideShadow
		Colour for edging or shadow on wide-aspect DTV characters.

Notes:

DVDs use four colours for subpictures (called B, P, E1, and E2, 
though the names are not cast in stone). Subpictures are full-screen 
bitmaps that can be put to any purpose, though usually they're used 
for subtitles/captions and menu elements. (And karaoke!) 
<http://www.dvddemystified.com/dvdfaq.html#3.4> (gigantic file)

Note that the four transparency values associated with the four DVD 
colours can already be handled by this proposed CSS3 spec.

Even after reading the books _DVD Demystified_ and _DVD Authoring and 
Production_, the exact role of the colours is unclear to me, and in 
any event, the subtitler/captioner may provide TIFFs of subpicture 
bitmaps with certain values for the colours and the authoring house 
may go in and change them.

In any event, if the authoring house can change them, so should the 
viewer be able to-- it's not unimaginable.

Now, in U.S. digital TV, no terminological distinction is given 
between captions and subtitles. Arguably this is a mistake. There is 
a reliance on language codes to solve the problem, but all that means 
is that if you ask for ENG captions, you may end up with ENG 
subtitles. Or if what you really want are ENG subtitles, you cannot 
ask for them specifically; you can only ask for ENG captions and hope 
that the *form* of the visible words is subtitle-like.

The DTV spec provides for regular, easy-reader, and letterbox or 
widescreen captions. The same program can carry all three in each of 
several languages. The spec documents are Word files available here: 
<http://www.dvddemystified.com/dvdfaq.html#3.4>. You want ATSC 65 
<http://www.atsc.org/standards/A65-A.doc>. There is no Google 
HTMLified version.

Note that there are no colours defined in the DTV spec. It's left up 
to the receiver, which really implies a relationship between the 
receiver and the viewer (e.g., receiver could give you white captions 
on black *and that's it* or could let you select any colours you 
like). The same four generic parameters-- foreground, background, 
mask, and shadow-- are applicable here, so that's what I listed.

Remember, the principle here is device-independence (hence the 
generic tokens) as well as acknowledging the real world, which W3C 
standards docs are usually not very good at.


COLOURBLINDNESS

The spec currently says:

>   4.5. Notes on using colors
>
>    Although colors can add significant amounts of information to 
>document and make them more readable, please consider the following 
>guidelines when including color in your documents:
>
>      * Don't use color combinations that cause problems for people 
>with color blindness in its various forms.

That pretty much tells you nothing. I wrote an entire chapter on the 
topic; it's hard to sum up. And you *can* use confusable colours in 
unconfusable ways.

>      * If you use a background image or set the background color, 
>then be sure to set the various text colors as well.

I wish that advice were fine-tuned. If you have a CSS that does 
nothing but add a background colour and you assume foreground will 
inherit (I use these all the time), it is actually better not to set 
the foreground so that the background-setting style will be more 
easily applied to a range of entities. The CSS validator warns me all 
the time about this even though I of all people know what I'm doing. 
I suppose the validator cannot quite be educated enough to know when 
the user is smart or stupid. And anyway, they're just warnings, not 
errors.

>      * When practical, adopt common conventions to minimize user confusion.

Oh, maybe. <http://www.spiked-online.com> uses different colours for 
each section, and it makes perfect sense to me (and isn't 
inaccessible). I don't see why this clause is necessary.


Now, then.

DO WE HAVE TO INCLUDE ALL THIS?

I know this is last call for this spec, and I am arriving very late 
to the party, but if you want to do more than just *say* you're using 
the CSS3 colour module for accessibility, you have to look after a 
few details. I don't see any harm in adding a few dozen more system 
colours, since, as we all know, they will continue to be ignored by 
most devices. Except, actually, *access-related* devices may 
*specifically* pay attention to the tokens I suggest we add. Suddenly 
system colours will actually be used-- just not by IE Version 
Whatever on Windows, which isn't the be-all and end-all in the first 
place, but by (for example) software DVD players and Web-enabled DTV 
receivers.


WHAT'S WITH THE Us?

I write in Canadian English, which spells "colour" with a U.
-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Weblogs and articles <http://joeclark.org/weblogs/>
     <http://joeclark.org/writing/> | <http://fawny.org/>

Received on Monday, 13 May 2002 17:44:29 UTC