Re: notes on current draft.

At 12:37 PM 6/2/1998 -0400, David Poehlman wrote:
>Below you'll find document excerpts and coments from the 5/30 draft.  In
>places there are comments surrounded by ** and in some places I've used
>*dp* to indicate my comments.
>Please note: I worked with the document as it stands not taking into
>account any broad enterpretation of material when referred to and looking
>with the eye of someone not familiar with it and also from a designer's
>point of view re browser/user agent.
>
>I feel wee need to tackle the ratings issue in discussion but offer the
>thought that some priority 1 items may be conbinable as to decrease the
>actual number and still achieve the same results.
>My hopefully valuable input is below.
>   
>  2.3 Selection, Focus, and Events
>          
>   Focus
>          The focus is a control element (link, form, DHTML events, etc.)
>          that is used by keyboard commands to indicate which control is
>          currently active. A document can only have one focus at a time.
>*dp* events should be replaced by event
>   
>3 Presentation Adjustability
>
>  3.1 Control over Browser Defaults and Author Styles
>  
>    1. [PRIORITY 1]
>       Allow the user to override default values for the following
>       properties: font face, font size, and foreground and background
>       colors.
>*dp* strike the last "and".
>    
>2. [PRIORITY 1]
>       Allow the user to override author styles for the following
>       properties: font face, font size, and foreground and background
>       colors.
>*dp* strike the last and.

JRG: Items have been combined

>
>4. .
>*dp* what goes here?
>    7. [PRIORITY 1]
>       Allow the user, through a keyboard command, to switch between
>       browser default values and current values.
>*dp* what is "current"? perhaps custom or user defined could
>be substituted here?

JRG: We need to clarify current.  maybe change to user.

>
>         3.2 Alternative Representations of Images
>  *dp* note: see criptic comments surrounded by **
>    1. [PRIORITY 1]
>       Allow the user to turn off the display of images inserted by
>       HTML's IMG element (see [HTML40]) and display descriptive
*alternative* text 
>       in place of the image. There are potentially two sources of
>       descriptive text information (in order): the "alt" and "title". If
>       both "alt" and "title" are specified, "alt" should be used as a
>       description  of *replacement for* the image, and "title" as a tool
tip. 
>       If only "title" is available it should be used as the description
of the
>       image.
>       If none of these attributes is specified, the name of the file
>       designated by the "src" attribute should be used as the
>       alternative text.
>       The entire text should be rendered no matter what the source of
>       the text or the dimensions specified for the original image. Text
>       should be wrapped so the user doesn't need to do a vertical scroll
>       to read the description.
>*The text should wrap so that the user need not scroll
>horrizontally in order to read it.*
>
>    2. [PRIORITY 1]
>       Allow the user to turn off the display of images inserted by
>       HTML's OBJECT element (see [HTML40]) and display descriptive
>*alternative, alternate or replacement?*text
>       in place of the image. The innermost text of the OBJECT is
>       considered its alternative text. In the element has no content,
>       the name of the file designated by the OBJECT's "data" attribute
>       should be used as the alternative text.
>       The entire text should be rendered no matter what the source of
>       the text or the dimensions specified for the original image.
>
>    4. [PRIORITY 3]
>       When an IMG element has a value for the "longdesc" attribute and
>       the user has already defined a "description link" (D-link) for the
>       image, the "longdesc" D-Link should be suppressed. Therefore if an
>       IMG element has both a value for "longdesc" and a hard coded
>       D-Link only one D-Link should be presented to the user.
>*dp* what does "user has defined" mean here?
>       
>  3.3 Alternative Representations for Video, Movies, and Animations
>*dp* should not the word audio be inserted here and throughout this
>section as well?
>       
>  3.5 Alternative Views of Document
>  
>    1. [PRIORITY 2]
>       Allow the user to identify quickly the important elements of a
>       page. For example, when used properly, header elements (H1-H6) may
>       be used to create an outline of major topics. The user should be
>       able to select headers in the outline view, causing the
>       corresponding locations in the main view to be displayed.
>       If the browser provides more than one view, the user should be
>       able to toggle between the full and outline view of the document.
>       Selections between views should be synchronized.
>*dp* "full and outline" might be replaced with "various views" or just views.
>
>4 Orientation Information
>
>  4.1 Maintenance of Document View and Focus
>  
>    1. [PRIORITY 1]
>       Maintain the document view and focus as a user moves between
>       documents. As a user activates links and
>*dp* is this finished or tied to the below?

JRG: Fixed in current version

>    2. [PRIORITY 1]
>       When the user changes the view of a document, the focus is shifted
>       to a location in the current view. Thus, after changing the view,
>       if the user uses keyboard commands to move or select the focused
>       element, the view does not abruptly change to another portion of
>       the document with the focused element.
>       
>  4.4 Element and Event Identification
>  
>    1. [PRIORITY 1]
>       Display information about elements and dynamic HTML events when
>       certain events occur (e.g., focus, hover, etc.). Element
>       information should be displayed on the status line of the browser
>       when an element receives the focus or an occurs.
>       *dp* the word event is missing after an above.
>

JRG: Fixed in current version

>5 Navigation and Control
>    
>  5.2 Hierarchical Navigation
>  
>   Question. How is the hierarchy defined?
>*dp* does the d o m speak to this issue?
>    1. [PRIORITY 2]
>       or [PRIORITY 3]
>       Allow the user to use the keyboard to navigate a hierarchical or
>       outline representation of the document. Highlight the focus within
>       the hierarchy in a way that is compatible with third-party
>       assistive technology. The user should be able to expand or
>       contract the hierarchy based on keyboard and pointing input.
>       
>  5.3 Direct Navigation
>  
>   Question. How are elements named and numbered?
>*dp* a link is named by the text in it much the way of an
>address in an addressbook.  anything between the > and the </a>
>is fair game.  presumably, going from lefto right.  Numbering
>begins at top left and moves sequentially as you read.
>Other processes govern special cases such as tables and frames.
>HOwever, if you activate a frame, the links with in it can
>be numbered beginning at 1.

JRG: Updated in curent document

>    1. [PRIORITY 1]
>       Allow the user to use the keyboard to move the focus directly to
>       links and controls on a page. Users should be able to search for
>       (and shift the focus to) a link or control by its position or by
>       its name.
>
>
>    2. [PRIORITY 2]
>       Allow the user to use the keyboard to move the focus directly *to*
>       elements that are not links or form controls.
>    
>  5.6 Dynamic HTML Events
>*dp* What does create mean in the two items here?
>    2. [PRIORITY 1]
>       Allow the user to use the keyboard to create a list of elements
>       and their associated dynamic HTML events, and to select and
>       execute an event on the list.

JRG: Changed to access

>       
>  5.7 Navigation among Pages
>  
>    1. [PRIORITY 1]
>       Allow the user to use the keyboard to create a history of visited
>       documents, and to select and visit a document on the list.    
>
>6 Visibility of Accessibility Features
>       
>  6.2 Documentation
>    3. [PRIORITY 1]
>       Print and on-line information should be available in alternative
>       formats for people with print impairments. This includes large
>       print, *an accessable electronic form*
>audio tape and Braille. Information on how to obtain
>       information in alternative formats should be available in both
>       on-line and print materials.
>

JRG: added electronic form

>7 Compatibility
>    
>  7.2 Compatibility with Third-party Assistive Technology
>
>    Using Accessibility Application Programming Interfaces
>    
>   [PRIORITY 1]
>   Some operating systems have developed accessibility application
>   programming interfaces (APIs). The accessibility APIs are designed to
>   provide a bridge between the standard user interface supported by the
>   operating system and alternative user interfaces developed by third
>   party assistive technology vendors to provide access to persons with
>   disabilities. Applications supporting these APIs are therefore *generally*
>more compatible with third party assistive technology. A list of currently
>   available accessibility APIs can be found in Appendix B.
>*dp* note: at the present time, some third party access
>applications are rendered useless by at least one access api, and
>backward compatability can be an issue as well.
>the future holds promise.
>

JRG: Is this good or bad?

>
>
>Hands-On-Technolog(eye)s
>touching the internet
>voice: 1-(301) 949-7599
>poehlman@clark.net
>ftp://ftp.clark.net/pub/poehlman
>http://www.clark.net/pub/poehlman
>
>
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
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
	http://www.als.uiuc.edu/InfoTechAccess

Received on Friday, 5 June 1998 17:30:19 UTC