RE: Conveying metadata unobtrusively in HTML

Nick Kew wrote:

> Colour - and other visual styling - is a great tool for conveying
> information.  For example, if we are evaluating something, we may
> use red to highlight an error, amber for a warning, and green for OK.

Or preferably some other colour combination, since there are so many people
who have difficulties in distinguishing between red and agreen. But colors
are, indeed, very valuable in visual modes of communication.

> But of course, that raises the obvious accessibility issue for the
> visually impaired.

And people using black and white or greyscale monitors, or reading a normal
paper copy. After all, an evaluation report is typically something you might
wish to print, and color printers are not always at hand.

In the long run, I think the only feasible approach is to introduce
"abstract colors" or "generic colors", i.e. a set of predefined class-like
properties for elements, with no pre-assigned semantics but with the
requirement that user agents present them in _some_ manner that
distinguishes them from each other and from normal content. Then the author
would just need to provide brief descriptions of _his_ semantics for the
abstract colors, expecting browsers to make them available through some
"show/read the legend" function.

But during the decades we need to wait for that, what can we do? Classes
have no semantics, and this is problematic enough. Any essentially _new_
mode of presentation will start with the situation that there are so many
"class'ed" documents. Even if authors have provided presentational
suggestions for several modes of presentation, such as graphics with color,
graphics with greyscale, multi-color text, single-color text, and aural
presentation (how many authors actually consider such issues?), they cannot
possibly anticipate presentation environments that they were unable to
imagine.

The technical problems are serious too. Suppose we decide, for reasons
explained above, that we need to provide the ultimate fallback as text in
the document itself (as body text, not metadata), e.g.
<div class="errmsg"><span class="n">Error:</span> Some error message.</div>
with the intent of using CSS to suppress the display of anything in class
"n" and using some method of making class "errmsg" look prominent and
important. The parts of this plan can be carried out in CSS as currently
defined, but how can you put the pieces together? There's no way of saying
"ignore such-and-such elements in the presentation _if_ you are able to
support such-and-such methods elsewhere".

The conclusion seems to be: Use text - or at least short textual codes, like
"E" for error, "W" for warning - to make sure that essential information is
always present. And use visual highlighting in addition to that, without
trying to wipe out the text when the visuals work. As a side effect, if
consistent label texts or codes are used, people will have more comfortable
ways of finding the next error message using some Find function, or grepping
just the error messages, etc.

Actually, it might be better to highlight texts like "Error:" only, not the
actual texts. After all, colored text is impressive, but it can be hard to
read.

> In Page Valet, visual information is duplicated in text: in 
> particular, accessibility messages are prefixed with, for example,
"WCAG2/High"
> to indicate a WCAG level 2 checkpoint that we have diagnosed with
> a high level of certainty.  This is visually obtrusive, and I don't
> really like it.

You mean the output from http://valet.webthing.com/page/ I suppose. (I
always find that particular page hard to find. It would be better if the
main page contained a simple and prominent link to it, very near to the
beginning.)

I don't find a prefix like WCAG2-AA/High that obtrusive. But the code could
be simpler and easier. Does "WCAG2-" really serve a communicative purpose
there?

The worst problem with the report from Site Valet, both as a general
useability issue and as an accessibility issue, is that the report does not
begin with a summary and it does not _first_ list the problem, then
(optionally) show them in context, in a "source listing". The mere volume of
output is really too much to be _listened_ to, for example. And it's awkward
to scan the report visually too, if you have just a few potential problem in
a large document. (And for a document with lots of accessibily problems and
markup errors, checking tools are not very effective anyway.)

> Another option I'm playing with is to abuse the "title" attribute
> for this kind of thing.  The logic is that this becomes unobtrusive
> for visual users, but accessible to non-visual devices.

Others have commented that it doesn't really work that well. The "title"
attribute shouldn't be taken as anything more than an optional hint. It's
like text written in invisible ink that miraculously but unpredictably
becomes visible at times.

> <URL:http://valet.webthing.com:8000/html-form.html>.
> This uses the title technique to highlight whether an attribute is
> valid, deprecated or bogus, duplicating visual information conveyed
> by colour.

Viewed on Lynx, there is no highlighting and (as far as I know) no access to
the title texts.

And, in general, I don't think the title attribute changes the fact that you
are relying on color alone.

-- 
Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi
Phone: +358 9 4763 0397 Fax: +358 9 4763 0399

Received on Monday, 3 June 2002 06:31:36 UTC