- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Mon, 01 May 2000 10:52:02 -0500
- To: Ian Jacobs <ij@w3.org>
- Cc: w3c-wai-ua@w3.org, w3c-wai-pf@w3.org
Responses in JRG: > > 3. All views need to be accessible > >I don't think this is true. Some views could not be accessible, >as long as the user can get equivalent functionality in other views. >Just like for the documentation: some documentation may be inaccessible >as long as at least one version is. JRG: I think saying that all views do not need to be accessible is problematic. A developer could say that the source view is the accessible view for their application and I don't need to make any other views accessible. I think we need to have a requirement that all views are accessible. > > > 4. A source view is one way to make content available, but not the only way > > it should be made available > >This is a comment on 2. > > > 5. Access to the attributes of an element is useful and should be easy for > > the user to obtain. > >This is a special case of 2. JRG: AG and JW think this is a critical need. Others on telecons have said this is important too. I agree though that most people will not know what to use it for. > > > I like Ian's [1] splitting out the alternative equivalent part of the > > checkpoint into a separate checkpoint. > > > > I would like to propose the following 5 checkpoints to help make the > > requirement for checkpoint 2.1 clear. The proposal is based on the > > comments that I have hearing for the past couple weeks. > > > > Proposal: > > > > Checkpoint 2.1a Ensure that the user has access to all > content. [Priority 1] > > > > Note on 2.1a: > > 1) The combination of views offered by a user agent must provide access to > > all author supplied resources. A source view is typically one of the views > > offered by a user agent, but is not a requirement for satisfying this > > checkpoint if resource information is available in the combination of other > > views. > >Yes, that seems ok. > > > 2) When a users change the default rendering configuration (colors, style > > sheets, font size and style...) the view must provide access to all the > > content defined for that view. > >I don't understand this now. Why is it only necessary to provide a >scrolling mechanism when the default config has been changed? JRG: I should have said maybe. For example, in a graphical user agent this may require the ability of the user to scroll the contents of a view in a view port so that information rendered in larger fonts can still be viewed. The example is just a technique. In general we would want to encourage implementations the minimize horizontal and vertical scrolling. > > > Checkpoint 2.1b Allow the user substitute alternative equivalents for > > primary content in views where alternative equivalents are not rendered by > > default. [Priority 1] > > > > Note: For example, substituting the ALT text associated with an image > > and/or a link to the LONGDESC resource of an image for the original image. > >I think "substitute" is too strong. Is it sufficient to provide >alternative content in addition to (e.g., in a tool tip) primary >content? Can we just say "Ensure that alternatives are available"? JRG: I used the word substitute to emphasize that the alternative must be in the same view as the primary content. Substitute may not be the best word, I would encourage other suggestions that make clear the requirement of rendering the alternative equivalents in the same view as primary content. > > > Checkpoint 2.1c For synchronized alternative equivalents, provide a > > synchronized view of the alternative equivalent with primary > > content. [Priority 1] > > > > Note: This supports the current checkpoint for a means to provide > > positioning of a separate view in checkpoint 4.7 > >Checkpoint 4.7 gives very precise instructions for graphical >positioning. The proposed 2.1c, makes a larger requirement. >Hos is 2.1c different from 2.6? JRG: This is the same as 2.6 and I with draw the proposed 2.1c. > "Allow the user to specify that text transcripts, > collated text transcripts, captions, and auditory > descriptions be rendered at the same time as the > associated auditory and visual tracks. Respect > author-specified synchronization cues during rendering." > > > Checkpoint 2.1d Provide synchronized views of content. [Priority 2] > > > > Note: If a user agent provides more than one view of content, allow the > > user to synchronize the views. For example, when an element is selected in > > > one view and the user switches to a source or a DOM tree view of the > > resource, the portion of the resource associated with the selected element > > is also selected in the source or DOM tree view. > >I don't think we should add this checkpoint to the >guidelines at this time. Synchronized views are undoubtedly useful, but >this is a brand-new requirement. I'm pretty sure this is covered >in the techniques document. Can we just consider it a technique? JRG: This seems to be a requirement from the group. But if the group doesn't want it, we can move it to the techniques document. > > > Checkpoint 2.1e Provide access to only the attributes of a selected > > element. [Priority 3] > > > > Note: In some cases the user needs access to the attributes of a selected > > element to determine the purpose or relationship of the element to other > > elements in a resource. > > > > This is priority 3 since it is a convenience function. The information > > would be required to be available through the user interface in 2.1a and > > partially supported in 2.1d. AG and JW have said this maybe a common > > technique for XML, until more is understood about how XML will be used and > > made accessible. > >I don't think this will be useful to many people in practice. How >many users know that an attribute is, let alone attributes of an XML >application they've never used before? This is a special case of >checkpoint 2.1a that I don't think needs its own checkpoint. I propose >instead that we suggest techniques that ensure that this is done. JRG: I agree, but many people have said this information is very valuable to the few users with disabilities that understand it. > _ Ian > > >-- >Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs >Tel: +1 831 457-2842 >Cell: +1 917 450-8783 Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Chair, W3C WAI User Agent Working Group Division of Rehabilitation - Education Services College of Applied Life Studies University of Illinois at Urbana/Champaign 1207 S. Oak Street, Champaign, IL 61820 Voice: (217) 244-5870 Fax: (217) 333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund WWW: http://www.w3.org/wai/ua
Received on Monday, 1 May 2000 11:52:05 UTC