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

Re: Question about access to ALL content - UAAG 2.1 P1

From: Hans Riesebos <HRiesebos@alva-bv.nl>
Date: Wed, 29 Mar 2000 11:56:00 +0100
Message-Id: <s8e1f081.090@mail.alva-bv.nl>
To: <pjenkins@us.ibm.com>, <w3c-wai-ua@w3.org>
I do not think that the source of a page can considered to be the content of that page. When in the browser, interaction with a page can change the content. (E.g. The DOM-content was modified after a some mouse-event by some java script). Showing the source would now be essentially different from access to the DOM.
The source is used by the user-agent to form the initial content. Even if we can expect a human to repeat this process when confronted with the source, we cannot expect him to keep track of interactive changes to the pages content. 
Right now source may seem accessible. Pages might well be (much) more complex in the future. 

Thus, in my opinion a source view would not satisfy checkpoint 2.1 because source is not content.

Hans Riesebos
ALVA BV, The Netherlands
HRiesebos@alva-bv.nl

>>> <pjenkins@us.ibm.com> 03/23/00 03:51PM >>>


After reading the user agent proposed rec guidelines [1] document and the
associated techniques [2], I have a question about how to interpret the
priority 1 checkpoint 2.1 Ensure that the user has access to all content
... The techniques [2] give examples about AMAYA's ability to show the
attributes of an element - which is nice,  but more like what I would
expect from an editing tool and environment than what I would expect from a
user agent that majors in rendering content.  But my question is;  -  would
the current technique of rendering the source view of the content meet this
checkpoint?  If not, it needs to be explicitly stated.  If it would be OK,
then the instances for which it would be O.K. need to be stated in the
techniques.

My concern is over priority 2 or 3 content from the WCAG [3].  For example,
why is it a priority 1 for the browser to render the title attribute on the
HR element?  Sure the author and/or authoring tool went to the trouble to
put a title there, but what is the benefit in this case for accessibility?
Would not access to the source view meet the checkpoint?  Content is
defined in the glossary [4] as including comments, in addition to elements
and attributes.  Would the browser need a separate accessible user
interface for rendering the comments?   - other than the source view?

More examples from the WCAG checklist need to be considered.  I have listed
the ones that first come to mind here for further discussion:
1.1 Object types (not to be confused with objective alternative which is
   P1)
2.1 Color attributes (not to be confused with high contrast requirement)
4.1 Natural language (identifying - not rendering)
4.2 ACRONYM and ABBR expansion
4.3 Primary language of document (identifying - not rendering)
5.2 Table elements and attributes (i.e., what kind of a cell is this? TH vs
   TD vs TFOOTER, etc.)
12.3 LEGEND for FIELDSET, OPTGROUP for SELECT, etc.
12.4 LABEL FOR vs what is it's LABEL
13.2 Metadata added as semantic information about page and site navigation

I believe access to the source view would meet the checkpoint in the above
cases.  More easier to use accessible user interfaces are up to the user
agent designer upon which they will compete.

Also, the wording of the checkpoint is interesting.  Is the phrase "ensure
... access to all" meant to be different  than say for example,  "render
all"?

[1]
http://www.w3.org/TR/2000/PR-UAAG10-20000310/uaag10.html#gl-content-access 
[2] http://www.w3.org/TR/UAAG10-TECHS/#content-access 
[3] http://www.w3.org/TR/WAI-WEBCONTENT/ 
[4] http://www.w3.org/TR/2000/PR-UAAG10-20000310/uaag10.html#def-content 

[previously posted to AU in error]

Phill Jenkins
http://www.ibm.com/able 
Received on Wednesday, 29 March 2000 04:59:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:52 GMT