RE: Conveying metadata unobtrusively in HTML

On Mon, 3 Jun 2002, Jukka Korpela wrote:

> 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.

Yes, that's implicit in any model using CSS (you didn't think I'd even
contemplate using <font color=...>, did you?)

>	 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.

Indeed.  So <em class="deprecated">color=&quot;octiron&quot;</em>
should be fine.  And that's exactly what I'm using if we ignore the
title attribute.  The mapping of the "deprecated" attribute to a
colour is of course in CSS.

I'm happy with that, as far as it goes.

> But during the decades we need to wait for that, what can we do? Classes
> have no semantics, and this is problematic enough.

Exactly.  We're expecting the user to be proactive.  That relies on
both the user and his/her software being capable of defining a
meaningful presentation of things like class="deprecated".

>	 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.

Again, CSS does that in principle.  The Right Solution is improved
clientside tools for dealing with it.  Whatever I do serverside is
extra.

> 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.

I've found that tends to become harder to manage as the number of
codes increases.  If we take "W" to mean warning, that could be a
validation message of severity "Warning", or a warning generated by
a WCAG checkpoint.  Slightly longer texts such as "WCAG" seem
clearer, as do the visual cues used in Valet.

 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.

Again, that's close to how most of the Valet tools behave, so I think
we seem to be in agreement.

> > 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.)

Site Valet offers many tools - Page Valet is just one of them.
What else should be given such prominence, and why?

> 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?

Well, er, yes.  That's a compromise between informativeness (WCAG is
much more informative than, say, "W") and brevity.


> 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".

Bah, Humbug!  You have the XML (or indeed the EARL) - you are free to
do what you like with it.  A stylesheet to present it as you prefer
should be trivial to construct.

I'm less concerned about offering the presentation you describe in HTML,
because it's already widely available, in earlier Page Valet versions
(still available), and in the W3C and WDG validators.  I have no interest
in duplicating existing services, except where I know I can offer a
significant improvement on them.

>	 The mere volume of
> output is really too much to be _listened_ to, for example.

Yes, I can see that's an issue (but you still have the XML).
Maybe I'll find ten minutes tonight to put up a new stylesheet
on the server, to present a much briefer report.

>	 And it's awkward
> to scan the report visually too, if you have just a few potential problem in
> a large document.

Hmmm, the feedback I've had on that has been overwhelmingly positive:
the visual highlighting of errors and warnings causes them to stand out
prominently in a quick overview.

>	 (And for a document with lots of accessibily problems and
> markup errors, checking tools are not very effective anyway.)

I hope the new service (under construction) will help.  It will
eventually offer much the same accessibility tests as Page Valet, but
in a kinder, gentler manner, and with options to fix up broken markup.

> > <URL:http://valet.webthing.com:8000/html-form.html>.
>
> Viewed on Lynx, there is no highlighting and (as far as I know) no access to
> the title texts.

Indeed, but Lynx is a very low priority, in that users such as you and
me have the option to use a CSS-capable graphical browser, and web page
analysis is not a task that's likely of high priority when away from
the desktop.  Btw, lynx is the browser I use for most of my development
work on services such as this.

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

This is a service under construction.  Posting here is exploring ideas
for how to proceed with the construction.  Regarding my particular
question, Kelly Ford's reply was a complete answer.  Yours, as ever,
explores other related issues and provokes thought - for which I
thank you.


-- 
Nick Kew

Received on Monday, 3 June 2002 17:10:20 UTC