- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 24 Mar 2000 12:35:55 -0500
- To: pjenkins@us.ibm.com
- CC: w3c-wai-ua@w3.org
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