Weblogs: Web Accessibility

Thinking About Accessibility - Select Menus

Tuesday, February 08, 2005

Before DHTML drop-down menus, the select list form element was used to provide navigation options for a website. Strictly speaking select lists (as well as other appearing/disappearing forms of navigation) suffer from usability problems related much to the fact that its difficult to see all the menu options in one go.

Many select-based menus are not well implemented, especially in terms of accessibility. Most people when faced with the requirement of accessibility tend to offer an alternate list of links. But it is possible - and worthwhile - to accessify the select list. (Of course, the usability problems of hiding navigation items is still with us)

It is worthwhile implementing select-based navigation scheme accessibly. Consider this: one of the difficulties screen reader users face on websites are reams and reams of links that make up a navigation scheme. The typical workarounds are skip links to jump past these menus. An accessible select menu allows a screen reader user to tab to the dropdown menu, and then they can make a choice of tabbing over it, or actually working their way through the list of items.

The typical problems people run into with making select lists accessible are:

Dependencies on JavaScript
Hardware dependent event-handlers

A real world example

The Treasures of Battye Library is a repository for public information based in Western Australia, with items dating back to the 17th century. Their website is intended to give the audience a flavour of the rich material being treasured.

The site itself is a good example of accessibility, its smart looking. Not surprising it won the GAWDS Site of the Month award for January 2005.

As discussed in my previous article on Equivalent Content, the alternative text of the listed images adds equivalent content which already is present, resulting in a needless, and perhaps disconcerting duplication of content. Of course, the simple alt="" alleviates this problem.

What caught my eye was the select option offered at the bottom of the page - a menu called Treasure Quick Link. The markup for the menu currently looks like this:

<form action="#">
 <h2>
  <label for="quick_link_bar">
   Treasure Quick Link
  </label>
 </h2>
 <p>
  <select id="quick_link_bar"
   onchange="jump_menu('parent',this,0)">
   <option selected="selected">
    Select a treasure...
   </option>
   <option>
    ----------------------------------------
   </option>
   <option value="pelsaert/index.htm">
    Pelsaert Journal
   </option>
   <!-- truncated for brevity -->
   <option value="stewart/index.htm">
    Ray Stewart Collection
   </option>
  </select>
 </p>
</form>

The form actually depends on a fragment of JavaScript - a function called jump_menu, which contains the following code:

function jump_menu(targ,
 selObj,restore){
  eval(targ+".location='"+
   selObj.options[selObj.selectedIndex].
    value+ "'");
  if (restore) selObj.selectedIndex=0;
}

A brief summary of the problems with this particular implementation:

Using the onchange event handler is problematic. It triggers when the current focus leaves the field - which then causes the page to change without the user intending it. Without a submit button, the user is not in control of the widget.
Its dependent on JavaScript.
Selected one of the first two options triggers a 404 page

Nothing insurmountable. We can make this menu more accessible, and at the same time more usable. Or we could say, let them use the alternative menu instead - in which case the user has to chose the lesser of two evils - mindless duplication, or JavaScript dependencies.

`onchange` accessibility barriers

Open up the page in Internet Explorer 6, and tab down to the select menu. When the select box has the focus - how do you present the list of options? Pressing the down arrow triggers off the onchange making it impossible to see the actual list. The selection is deemed to be made before the visitor has even seen the list of options. This is an obstacle to keyboard access.

The simplest and logical answer is not to use onchange as a means of triggering a navigation select list. The alternative is to use a submit button, and there we can avail ourselves of more accessible solutions.

JavaScript dependency

Removing the JavaScript dependency involves nothing more than using the form elements properly. For starters, the form action should be the URL of a form handler (for example /cgi-bin/redirect.pl, and the select element needs a name attribute. All the form handler needs to do is read in the received values and return a correctly formed HTTP response. A simple Perl script which does this (redirect.pl):

#!/usr/bin/perl
use CGI;

if(param('quick_link')) {
 print redirect(param('quick_link'));
} else {
 print header(-status=>'204 No Response');
}

Perl is not the only solution. Any server-side language that can return a properly formed HTTP response can be used.

With the above script in place, and the action attribute on the form pointing to the URL of this script, we now have a graceful degradation when JavaScript is unavailable. We now meet checkpoint 6.3 without the use of an equivalent alternative. I'm not particularly fond of multiple navigation schemes where some work and some don't - its inconsistent and frustrating.

Improving the JavaScript

One piece of advice given out by JavaScript experts is to avoid any and all scripts that use eval. Even more so when the exact same side-effect can be achieved with a more logical code construct. Lets analyse our example:

 eval(targ+".location='"+
  selObj.options[selObj.selectedIndex]
   .value + "'");

This one line changes a particular frame's (or window's) location attribute to a particular expression. That is exactly the same as the following statement:

 targ.location=
  selObj.options[selObj.selectedIndex]
   .value;

There is absolutely no need to dynamically create a JavaScript statement using string concatenation, then execute it using eval. JavaScript exposes these properties via a defined object hierarchy already; eval in this particular context is inefficient, and consequently not recommended programming practice. There are times and places for self-modifying code - this isn't one of them.

Conclusion

The select-based navigation menu is an often-used, and perhaps useful widget for visitors using assistive technology. Hopefully with this article we have provided a foundation where people have the confidence and knowledge to implement it in an accessible manner.