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

I thought the discussion was going a bit differently. I believe there is
content that is not intended to be read by the user, but instead by the User
Agent. For example, URIs for links, or the markup elements themselves.

Unfortunately, unless we live in a world where User Agents and web content
are both perfect, there are going to be problems for some users which can
only be solved by the people who understand the source code being able to
read it and do "running repairs".

The example I used recently was the Sydney Olympics Website (the old
version). The only way I could get through it was to manually interpret the
scripts and work out what they were doing to find my way through the
site. Having access to the source (in some form) is essential for this. But
there is no reason why this should typically be presented to the user.

Charles McCN

On Wed, 26 Apr 2000, Al Gilman wrote:

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

--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia

Received on Wednesday, 26 April 2000 12:06:18 UTC