W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2000

Re: Important: Issues relating to checkpoint 2.1 raised during 30 March teleconference.

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 05 Apr 2000 12:58:07 -0400
Message-Id: <200004051659.MAA136797@smtp1.mail.iamworld.net>
To: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>

On the one hand Jon has a point that you don't ususally think of CLASS
tokens as intended for the user's consumption.

On the other hand, they qualify as 'content' because they are exposed in
the UI in the author session and frequently are mnemonic for why a
particular styling is being applied.  They provide a 'textual equivalent'
for the pattern of formatting properties applied in the related style rule.

I believe that Phill has a point because applying Priority 1 to "all
content" and then interpreting "all content" liberally to include every
attribute that can conceivably help in the interpretation of the page seems
a bit of a stretch.

At the edges, "all content" runs into some gray areas, and these gray areas
could be considered resources for 'repair' behavior by the user agent.  It
is conceivable that they could be assigned priorities less than 1.

Simply saying "but not all of this has to be exposed through the UI" is
inadequate defense of the user.

Showing all content, with "all content" broadly construed, is readily
achievable by the user agent through the UI subject to the exclusions
provided by the "applicability clause."  The default method for this is to
expand the "context menu" into a "property sheet" containing attributes of
the current object as well as its methods.

This demand, on the other hand, is hard to prove necessary.  It is hard to
prove P1 for the items which are marginally qualified as counting in
content.  It is by the way not trivial to segregate the marginal items from
the non-marginal items [probably TITLE is equivalent to non-markup element
content in this regard].

I don't have a proposed resolution for you.  

It is important to emphasize that the user agent should make available,
through user view control, everything in the data it has received (or the
current state of virtual document data held in the DOM, if changed since
receipt) that can broadly be construed as containing evidence pertaining to
the concept the author intended to communicate.  Not that we, or the
author, think these data are essential to the user's comprehension of the
message, but that the author and their authoring tool found it necessary to
send these data to the user agent to support the communication of the
message.  As I said above, things like the mnemonic used as a CLASS token
are often the only shred of a clue the user has by which to decode why a
given text range is styled differently from its neighbors.  And that 'why'
is part of the message that the author intended to communicate, even if the
style name is not part of the author's understanding of the means of

Intrinsic in this position is the idea that the user agent does have a
responsibility to exploit all available resources fully in constructing
adapted views of the message contained in the page.  The browser's range of
supported views should not be restricted to the range of views the author
has thought about.  And the data exposed in alternate views should not be
limited to the data exposed in the author's or nominal view.

The problem is that in terms of "all content" there is no universal
dividing line between data and metadata.  The partition between data shown
and data hidden changes from view to view.  The data available to generate
alternate views should include both the displayed data and the hidden data
of the nominal or author's view, with the stipulation that the hidden data
includes element attributes and that element attributes includes the
element type name.

Whether this is a P1 [automatically makes comprehension of the message
impossible for some group] or P2 [makes content so unusable as to be
effectively useless for some group] is debatable.  The fundamental problem
is that the WCAG priority definitions  don't necessarily make the same
sense in the user agent domain.

The point is that all of alternate content (e.g. in OBJECT, NOFRAMES,
NOSCRIPT) and element attributes (not just TITLE but CLASS, NAME, and so
forth) should be reachable in the space of views that the user can command
from the user agent.  The working group does not have a reliable rule to
offer user agent implementers as to what is safe to exclude from this.  It
is easier to just do it than to follow some catalog of bogus rules about
what to exclude.

To deliver a usable message to consumers whose functional limitations the
author neither understood nor thought about, the user agent has to act a
little less like a media player and a little more like a data browser.
This is to say compose a presentation driven by a user query or view
specification.  In respect of this shift, it must be recognized that the
element attributes are part of the encoding of the content, as far as
composing alternate views is concerned.

Received on Wednesday, 5 April 2000 12:57:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:26 UTC