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

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.

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.

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

Received on Friday, 24 March 2000 14:49:38 UTC