Document 'content' includes all element types and attributes (yes/no?)

What is this all about? 

It has to do with Guideline 2 in the User Agent Accessibility Guidelines,

Guideline 2. Ensure user access to all content.

The question was raised, "Does a source view satisfy this requirement?"

This sounds innocent enough, especially since this is the current practice
which is universal in browsers and does expose everything that came over
the wire in the HTTP message.

But, of course, the working group rose up with one voice to say "No, that
is too confusing; the user can't understand it, that's not what it takes."

And as a result a discussion started to try to figure out if a source view
is not good enough, what is the minimum that is good enough.

And the idea came up that "Well, at least we agree that information that is
for users needs to be exposed through the UI of the browser."  [Note that
the UA group is not using my definition of User Agent which includes any
assistive technology, but focusing for this release of their document on
minimum requirements for broad-market browsers.]

And I am trying to tell them "You don't want to say this, because it makes
it sound like there is information in the markup that is 'not for users,'
and we as a policy want to say there is no place for any of the latter on
the Web."

I have participated vigorously in this discussion.  See messages in the
vicinity of 


http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/author.html#168

One problem is that a principal supporting document I would like to have
considered in this discussion is the whitepaper I filed on our behalf (in
Member space) at:

Re: XML Plenary straw ballot (side note)


http://lists.w3.org/Archives/Member/w3c-archive/2000Apr/0050.html

I need somebody else to look at this to see if there is anything really
private about it.  Probably some of the references to the debate on XML
Plenary need to be cleaned out.  But the basic policy claim is an expansion
of 

[Guideline] 3. Export semantics

as set forth in 

XML Accessibility Guidelines

http://www.w3.org/WAI/PF/xmlgl

To paraphrase the political standard for ethics, the Web media must create
not only no dirty dealing through secrets from the consumer, but must work
strenuously to keep it from looking to the user as though there are any
secrets messages buried in the communications between client and server
processes.

The exposure of the text values of element types and attribute-value pairs
should be a required minimum implementation, given that authors generally
are not aware of the needs of adaptive views for people with disabilities,
of exposing the information content of what the author has to say.  The
text that goes over the wire is the least common denominator of all views
of the message.  This should be presented at minimum as a DOM walk, given
success in parsing the source.  Source view is not acceptable because a
tree-walking roam-and-inspect browse of the DOM contents is readily
achievable, and is better.

The distinction between data (raw content) and meta-data (markup) is an
artifact of the view assumed by the author.  There is no fundamental
semantic difference between what is called data vs. metadata.  They both
play the same role as bearers of information  Semantically, it is all just
one class of data.  This is a little-understood fact of information science.


We are already aware that the WCAG admonishes authors to use 'class'
tokens which clearly describe or represent the general rhetorical role of
the text ranges marked with this property.  The display semantics is at
arm's length on the other side of a style rule, according to the WCAG.  My
point is that our goal as PF is to proliferate this "open code" pattern
across all markup.  The names used in markup should be mnemonic, they
should be mnemonic for abstract roles that transform gracefully across
physical display alternatives, and they should be backed up by easily
obtained documentation.  The whole Web information ecology includes not
only individual users who have a right to this information, but also
small-market third-party experts who are creating stylesheets and other
assistive technology which must have assess to the semantics of the markup
practices.

To the UA group I am willing to say baldly "We should be unified in
presenting the claim that Web content should be transferred over the wire
in an open code.  Preferably the markup should be self-explanatory, and
where not self-explanatory, the explanation should be readily available."
In this, both the markup instance in the document instance and the markup
pattern of practice in the namespace or other reusable markup vocabulary
should satisfy this rule.

How do we see if there are any proper exceptions to this rule?

Do others see that this is a general policy that we as PF should be driving
the Web toward?  Other comments?

Al

At 10:09 AM 2000-04-26 -0500, Al Gilman wrote:
>At 10:18 PM 2000-04-25 -0400, Ian Jacobs wrote:
>>Hello Working Group,
>>
>>As starting points for discussion at tomorrow's teleconference, 
>>please consider the following comments and proposals.
>> 
>>   Proposal:
>>
>>   1) Leave 2.1 checkpoint text the same.
>>      ("Make available all content, including equivalent 
>>        alternatives for content.")
>>   2) Require that for content known by specification to
>>      be for users (including information in style sheets),
>>      that a document source view does not suffice.
>
>While this may feel good as a principle, I have a problem with the "which
>content is meant for users" concept.  Let me correct that.  I think the WAI
>and the W3C should have a problem with that distinction, as it creates
>fatal flaws in e-commerce, not just disability access.  It is just the
>users of minority views [such as people with disabilities] who suffer the
>consequences first.  [Canary in mineshaft...Universal Design...]
>
>There should be no markup, ever, that is completely beyond the user's
>discovery.  It can take N steps to expose and explain it, but it should be
>reachable somehow.  This is a key element of the information architecture.
>If it isn't self explanatory, the explanation should be discoverable by an
>obvious process.  With the Web at our disposal as a way to wire in layers
>of backup, there is no excuse for less.
>
>I would like to check this with the PF WG for a formal position.  May I
>register a dependency and promise a report on this?
>
>The tactical problem with this split is that it points at a body of
>literature which is simply not clear on this point.  To put this language

>in the guidelines invites a large rathole of deferred argument.  The
>strategic problem is that the distinction should not exist in the ideal
>case, so why insert it now?
>
>"What is for display" is view-specific.  Not document-information-generic.
>
>"What is for the user" is not a valid concept in the Universal Access
>architecture.  It is a residue of "view chauvenism;" someone's assumption
>as to what view the user is using.  All the properties are informative, and
>may be exposed in the over-the-wire encoding as text or (where available)
>in a friendlier transform of that encoding.
>
>Al
>
>>   3) A document source view (or better) satisfies the requirement 
>>      of making content available when otherwise difficult
>>      (e.g., style sheets, script source) or when it is not
>>      possible to know from the markup language specification
>>      which content is meant for users.
>>   4) The "document source" view is not a view of the
>>      document object (the structured navigation view). The
>>      user should find for example, raw script and style
>>      sheet data in the source view.
>>
>>-- 
>>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>>Tel:                         +1 831 457-2842
>>Cell:                        +1 917 450-8783
>> 
>

Received on Wednesday, 26 April 2000 11:50:58 UTC