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

Denis Anson wrote:
> 
> Ian,
> 
> I would say that the source view would meet this requirement only if two
> other conditions are also met:
> 
> 1. The source view itself is accessible to assistive technology.  If the
> viewer that is used for source view does not allow complete keyboard
> control, or does not expose the text in a fashion that is visible for a
> screen reader or braille display, the condition is not met.

Yes, those requirements for an accessible user
interface are covered by other checkpoints.
 
> 2. The "source view" feature somehow places the point of reguard at the
> relative portion of the page that you are trying to get access to.  In a
> multipage document, a user with cognitive limitations should not be placed
> at the top of the document and expected to find the information about a
> table that is several screens away.  In complex markup, this can present
> profound challenges even for the person who is experienced in reading HTML.
> For the typical end user, you might as well show the code in an encrypted
> format for all the good you have done.

This would be a new requirement for synchronization among views. While
I think this is a good idea, it seems like a technique to me.

 - Ian
 
> Denis
> 
> -----Original Message-----
> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
> Behalf Of Ian Jacobs
> Sent: Friday, March 24, 2000 12:36 PM
> To: pjenkins@us.ibm.com
> Cc: w3c-wai-ua@w3.org
> Subject: 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

-- 
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 14:55:31 UTC