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

pjenkins@us.ibm.com wrote:
> 
> 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.

I believe that, while not an ideal solution, a source view would meet
this
requirement. A navigable source view would be better, but still forces
people
to read the markup, which is not very desirable.
 
> 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?

Last Call issue 111 [1] was about introducing a relative priority scheme
(for checkpoint 6.1, implement the accessibility features of supported
specifications). The issue was raised by Charles [2] in light of the
Authoring Tool Guidelines experience. The UA Working Group, at the
Austin face-to-face meeting in December 1999 [3], decided to leave this
checkpoint a priority 1 checkpoint for several reasons:

  1) If user agents only implement P1 and not P2 and P3 accessibility
     features, no authors will be able to use the P2 and P3 features.

  2) The UA Working Group did not want to introduce a relative priority
     schema for a single checkpoint, arguing that it would complicate a
     system that some developers might already find challenging.

  3) The WG argued that non-conformance to specifications was one of the
     most important barriers to accessibility, and therefore it was
considered
     a high priority to implement all, not just some, of the
accessibility
     features of the supported markup languages.

While these arguments were used for checkpoint 6.1, I believe that
they also apply to checkpoint 2.1. 


[1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#111
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0211.html
[3] http://www.w3.org/WAI/UA/1999/12/ftf-19991210#issue-111

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

Yes, but not very well.

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

As Jon points out in a later email [4], we do not use the term "render"
since
content may be available through an API. There is a cross reference
from 2.1 to guideline 5 for that reason.

 - Ian

[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0518.html

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

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 429-8586
Cell:                        +1 917 450-8783

Received on Friday, 24 March 2000 12:36:06 UTC