comments to WAI guidelines

I am teaching useability at the Engineering College of Copenhagen and 
publishing public licence web software (www.agner.org/websoftware). I have 
some comments and questions on the proposed WAI guidelines.


1. hierarchical menu
--------------------
Navigation bars and menus is a common accessibility problem. If a site has 
many pages it may not be possible to represent the index in a clear and 
structured way on a simple menu bar. A hierarchical menu may be the best 
solution, and a standardized way of implementing complex menus would be 
very desirable.

I have analysed the possibilities of making structured menus with the 
existing technology:

   a. client side programming.
This is complicated and error-prone; device-specific; only available in 
graphic devices.

   b. server side programming.
This may work with all client devices, but inefficient and flickering 
because the entire page has to be reloaded every time the user expands or 
collapses a branch. Server side programs work only as long as the document 
resides on a specific server: It doesn't work if the user wants to download 
a document or bundle of documents for offline reading, and it cannot be 
used out of the internet context. Not all authors have access to server 
side programming.

   c. <select> tag.
This still requires a little programming either on the client side or the 
server side (in the latter case, the user has to press a submit button 
after making the selection). It is simple and therefore reasonably 
reliable, but a lot of facilities are missing:
   - a label cannot be displayed on the drop-down menu itself. The author 
may be tempted to use the first option as a label.
   - no possibility of embellishing with colour and icons. Cannot indicate 
the page that the user is currently on.
   - it is not clear whether the <OPTGROUP> tag is intended to separate 
options into groups (separated by a vertical bar or the like), an 
expandable/implodable branch (like the [+] icons on a file tree in Windows 
file managers), a roll-out menu (like the popup submenu of Windows dropdown 
menus), or some other design. In some of these cases it should be possible 
to nest it to an arbitrary level.

   d. making each submenu on a separate page.
This is very clumsy, but the only method that is sure to work in all systems.

My suggestion is that support for hierarchical or structured link menus 
should be built into all client devices. The HTML or XHTML language should 
support this with so many facilities that it becomes attractive to use it, 
even on commercial sites that rely heavily on graphics for competitive 
reasons. These options may include:
   - Various menu designs, like horizontal, vertical, drop-down, 
expandable, etc.
   - Possibility of indicating which page the user is currently on (greyed 
or coloured).
   - Possibility of embellishing with colour, icons, fonts, etc.
   - Possibility of an access key for each item.
   - It should be possible to make old browsers ignore the code. The most 
elegant way of doing this would be to have all specifications for the menu 
in a separate file. This would be particularly convenient to authors 
because the same menu can be included on all pages without the need for 
frames or server side includes. A further advantage is that a possibly 
voluminous code doesn't have to be reloaded every time a new page is displayed.
   - It should be possible to specify an alternative for old browsers in 
the same way as the <noframes> tag.

This would improve general useability because the user interface becomes 
more standardized, and it would be possible to implement the structured 
menu functionality in non-graphic devices.

Standardization of code and recommendations are necessary because most 
authors only have facilities for testing their applications in a few of the 
most common browsers.


2. indication of access key
---------------------------
Many computer users (including able-bodied users) have problems with the 
mouse. The access key facility is therefore very important. However, we are 
missing a standardized way of indicating that an access key is available. 
It is recommended elsewhere to underline a letter indicating the access 
key, for example underlining the N in the link text 'Next' if the access 
key is N. It is not possible with the available codes to underline, or 
otherwise emphasize, a letter on a button or select input. Underlining a 
letter in a link text doesn't make sense because the link is already 
underlined by default. I would therefore propose:
   - a code for underlining or otherwise emphasizing a letter on buttons 
and other input controls, or a recommendation that the browser does so 
automatically when an access key is associated with the element (An 
ampersand in front of the letter does this on some old browsers, but this 
is a bug rather than a feature).
   - a recommendation for a standardized way of indicating an access key in 
a link text (bold, colour, or whatever).


3. bypassing ASCII art and other heavy text
-------------------------------------------
You recommend a link for bypassing ASCII art etc. However, such a link will 
confuse and reduce useability for the 99% of the users that use graphical 
browsers. I would therefore suggest a special code for links that are only 
intended for non-graphic devices. This code should be designed so that its 
text is ignored by existing devices. Such a link may also be used for 
providing description of graphic images.


4. alternatives to frames
-------------------------
Frames have so many useability and accessibility problems that alternatives 
should be recommended. A frame with a navigation bar may be replaced by an 
expandable menu as described above. In general, frames may be replaced by 
server side includes or server side programming.


5. simple URL names
-------------------
You may recommend using simple, understandable names in lowercase letters 
for files and directories and avoid deep directory nesting. Important 
documents may be stored in separate directories and named index.html (or 
whatever the server's default is) so that the file name can be omitted. 
Default file names should be omitted if possible when specifying a URL.


6. identifying browser capabilities
-----------------------------------
With the current technology, programmers have to rely on information of the 
brand and version number of the browser to tell whether a certain feature 
is supported (browser sniffing). This method cannot possibly cover all 
client devices, including devices for people with special handicaps. A 
standardized method of indicating which standards and features a client 
device supports is required. This information should be available to client 
side as well as server side software. There may be such a standard 
underway, but I am not aware of any.


7. the readability of your document needs improvement
-----------------------------------------------------
Useful examples are often missing or difficult to find.




I hope that my suggestions can be useful to your work and to the web community.

Agner Fog, Denmark
agner@agner.org