RE: URL for the New Format for the UA guidelines

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.  


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..."

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.



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).


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.


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?  


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?


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>).  


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.  


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.)



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?.


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?  



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).

Acknowledgements:  this is the most unique misspelling of my last name:
"Chilstrom"  it's actually spelled "Chisholm"  <smile>


wendy chisholm
human factors engineer
trace research and development center
university of wisconsin - madison, USA

Received on Monday, 1 June 1998 13:40:36 UTC