- From: Joe Clark <joeclark@joeclark.org>
- Date: Wed, 15 May 2002 12:24:19 -0400
- To: www-style@w3.org
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 Wednesday, 15 May 2002 12:24:36 UTC