RE: URL for the New Format for the UA guidelines

Responses in JRG:

At 12:39 PM 6/1/1998 -0500, Wendy A Chisholm wrote:
>Hi,
>
>I apologize for not reviewing this sooner and for any duplicate comments.
>For each of my comments I include the text of the guideline and then a
>comment that begins with "wc::".  
>
>I'm anxious to see these guidelines implemented!
>--w
>
>
>3.2.3 [PRIORITY 1]
>     When an IMG element has a value for the "longdesc" attribute and the
>user has turned off the display of images, render a   "description link"
>(D-link) inline to give access to the long description. Provide keyboard
>access to locate and select the long description (in addition to pointer
>access for able-bodied users). The D-Link should function the same as a
>standard
>     ANCHOR element. 
>
>wc::  If a person has turned off the loading of images, then they probably
>won't mind a more descriptive link.  If the image has a "title" or "alt"
>associated with it, the text link that the browser renders could be
>"description of <title>/<alt>"  or even just "description of image <file
>name>" if no title/alt is given, or something like that.  
>
JRG: Interesting idea, I will add it to the issues page.  This may tie into
the current labeling of LONGDESC with class or rel.
>
>3.2.4.[PRIORITY 3]
>     When an IMG element has a value for the "longdesc" attribute and the
>user has already de fined 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. 
>
>wc:: I believe the first "user" in this guidelines should be "author,"
>i.e., "and the *author* has already defined a d-link..."

JRG: fixed 

>
>wc::  in general, when mentioning how object is rendered, before the file
>name is rendered (assuming this is a strategy we want to take - see Gregg
>Vanderheiden's message sent 5/30/1998) for the object check for  a title on
>the object.  Also, I assume that if there is a hierarchy of objects, the
>root object's information is what is rendered.
>

JRG: I think there is a consensus that file names are bad and I believe
TITLE is listed as an alternative source now.

>
>
>3.5 3.[PRIORITY 2]
>     Provide a "serialized" view of tables. The first line of the table
>provides the size and name of a table. Then, for each cell, render   the
>row and column coordinates of the cell followed by the cell's contents. If
>row and column heading information has been  specified in the table (TH
>element) it should be used in the row and column coordinate information. 
>
>wc:: row and column info can also be specified using "scope," & "headers"
>attributes or the COLGROUP element.  Therefore, it might not be possible to
>provide a "serialized" view of *every* table.  alternatively, if navigation
>through table cells is supported, then a querying mechanism should be
>developed to find out more about the current cell (row and column header
>info).
>

JRG: Could you write up a guideline that says what you think it should say
using scope and headers?  For navigation row and col info should be put on
the status line.


>
>4.1.1.[PRIORITY 1]
>     Maintain the document view and focus as a user moves between
>documents. As a user activates links and 
>
>wc:: unfinished sentence.

JRG: fixed

>
>
>4.1.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. 
>
>wc:: this is only required if alternative views are supported, and
>alternative views are recommended.  could these be grouped in some way?  
>

JRG: No this is a problem with the link or control that has the focus not
curently being in view window of the document.  People using Page down may
change the view but the control with the focus is still at the top of the
page out of view.  When they use the TAB key to move to the next control
the view abruptly changes to the top of the page.


>
>4.3.1.[PRIORITY 1]
>     When a page is loaded, display short document summary information: the
>size of the document, the number of structural  elements related to the
>document. The information could be displayed on a status line. 
>
>
>wc:: why is this required for accessibility?

JRG: It is no longer a priority #1.  It is useful for people with visual
impairments to get some info about the document.

>
>
>4.4.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. 
>
>wc:: the last sentence is missing an "event."  How will this information be
>rendered so that it is humanly readable without the author embedding the
>function of each event?  For example, when a mouse passes over a button, it
>changes from red to blue.  For a visual user, this indicates this is a link
>and it grabs our attention.  The author would be required to include a
>phrase to be included in the status line.  Otherwise, the browser would
>only be able to render something like, "image changes when it receives
>focus" or something less jargony (if that's even a word <smile>).  
>

JRG: I think this item needs some work.  I think the intent is that the
user be able to get information about what an element is (Header, list
item, para...) and also if the element can respond to an event.  I am not
sure the working reflects the goal or how non link and conrol elements
would get the focus.
>
>4.5.1.[PRIORITY 2]
>     Render the content of the TITLE element. The operating system may
>impose conventions about where and how title information is rendered.
>
>wc:: The TITLE element is usually used to name the current window of the
>browser.  However, TITLEs could also be displayed for titles of frames.
>Another possible use of the TITLE element is to  provide alt-text for
>images used as linke to pages when authors don't provide alt-text.  In this
>case, a brower could grab the contents of the TITLE element of the document
>being pointed to and use this as the alt-text.  
>
JRG: The title here refers to the title in the HEAD of the document, not in
an image.  I will make that clearer in the document.

>
>5.5 .1.[PRIORITY 1]
>     Highlight the focus in an obvious manner so that users with low vision
>may identify it. 
>
>wc:: and/or allow users to control how focus in highlighted (thick bordered
>box that outlines the item, or the item changing foreground and background
>colors, or  the item appearing at the top of the page,  or the item changes
>size, etc.)
>

JRG: We are recommending the implementation of the outline property in
CSS2.  WHich would provide a means to do these things.
>
>
>5.6.1.[PRIORITY 1]
>     Provide a means for third-party assistive technologies to identify
>which elements have associated dynamic HTML events. This may be done, for
>example, with visual markings.
>
>wc:: i strongly think this should not be done visually, but
>programatically.  It seems that if the browsers exposed the DOM of a
>document, most event information will be included, although i'm not
>positive about this.  does anyone know for sure?.
>

JRG: I agree and it has been changed.

>
>5.1.1.[PRIORITY 1]
>     Allow the user to use key board commands to sequentially move between
>every frame, link, IMG elements with the "longdesc"   attribute set (only
>when images are turned off?), and form controls. 
>
>wc:: it seems to me that we only have one hierarchy:  at the root is the
>page.  A page might contain two frames.  Frames might contain a heading,
>the heading might have several paragraphs, etc.  Therefore, it seems we
>need a single navigation mechanism with the following features:  
>1.  navigate to the next item in this level of the hierarchy
>2.  navigate to the next item x layers into the hierarchy (default would be
>one level).
>
>This way a user could navigate between the "big chunks" (TABLE, FORM, UL,
>OL, etc.) then a second mechanism that will allow navigation between its
>pieces (TABLEs have TR, TH, TD, etc., FORMs have INPUTs, LABELs, etc, lists
>have list items...).  
>
>As it reads now, why doesn't sequential navigation include other objects
>such as headers, applets, objects, paragraphs, lists?  
>

JRG: none of these items can currently receive the focus 

>
>
>5.6.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. 
>
>wc:: again, i think this will require the author to provide the human
>readable label for the events that the user selects.  do we want users
>selecting events, or results of the events?    it sounds like what we need
>here is a replacement function for mouse movements so the user can hear
>what will happen before deciding that they want it to happen.  This is like
>the Trace EZ Access "touch and confirm" access feature for touchscreen
kiosks.
>
>It would be very elegant if the human readable info could be extracted from
>the NOSCRIPT element, or vice versa ("NOSCRIPT" element contents could be
>generated from comment within scripts).

JRG: The element text content (this may be a problem) or ALT text would be
used along with the event that is associated with the element.

>
>Acknowledgements:  this is the most unique misspelling of my last name:
>"Chilstrom"  it's actually spelled "Chisholm"  <smile>
>
JRG: Fixed.  Thanks for your work in reviewing the document.

>
>wendy chisholm
>human factors engineer
>trace research and development center
>university of wisconsin - madison, USA
>
>
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 Thursday, 4 June 1998 17:47:44 UTC