TW Blog :: Entries for Accessibility

Key Press Event Handling

Also relates to DOM Scripting and Firefox and Co

On a current project, where accessibility is essential, I have integrated a stylesheet switcher on two pages where a mouseover affect on an image montage displays an introduction to each page in a separate box below the montage. The montage is structurally defined as a definition list, since it is a visual representation of links to pages on the site, with a brief description of each page. The stylesheet switcher allows users to switch the view to an actual list representation, if, for example, they are using only the keyboard. For CSS-enabled browsers without Javascript, the switcher loads a fresh page with the list display, and for non-display browsers the montage is just represented as a list from the outset.

While, I hope this will be effective under most conditions, I found a frustrating problem with supplementing the onclick event with an onkeypress event for keyboard users in Mozilla and co. When tabbing through the links on the page, as soon as the user tabs off the switcher (containing the event handler) the key press event is triggered. Well, of course, this is the correct behaviour, but Inte$net Exploder actually only triggers the event when the Return key is pressed, which is misleading to the developer, and incorrect interpretation.

The solution was to integrate a filter function that is called by the onkeypress event and this in turn only calls the style switcher function if the key pressed was Return

Here is the code:

function checkKeyPressed(evt, func, params)
{
  evt = (evt) ? evt : (window.event) ? event : null;
  if (evt)
  {
    var charCode = (evt.charCode) ? evt.charCode :
                   ((evt.keyCode) ? evt.keyCode :
                   ((evt.which) ? evt.which : 0));
    if (charCode == 13) func(params);
  }    
}

Where 13 is the ASCII value for the Return key. As well as passing the event as argument, I passed the function to be called and its parameters, to make the function generic. The scenario is just as relevant if using the event handlers to open a new window from a link (although this is strongly discouraged). The resulting anchor is as follows:

<a href="#" onclick="setStyleSheet('sheet'); return false;"
onkeypress="checkKeyPressed(event, setStyleSheet, 'sheet');"
>Switch to List View</a>

It is important that a false value is not returned in the key press event since this would prevent the user from tabbing beyond the style switcher link. The DHTML cookbook suggests the key detection in the filter should work in Netscape and Exploder back to v.4. It resolved the issue for this project.

Posted on Sep 14, 2003 at 16:44:31. [Comments for Key Press Event Handling- 7]

A Few Quick TitBits

Also relates to PHP and Peregrinations

Been very busy the past couple of weeks, so not much time for blogging…Here's a few bits and pieces from around the web…

• Need to hone those Photoshop skills? I rediscovered some handy tricks within Janee's Photoshop Tutorials.
• The new Accessify.com Forum is well and truly active and already looks set to be the topical place for accessiblity-minded developers.
• What's it like to be without power for 29 hours…Let Zeldman tell you.
• The best Chicken pie I have had for a long time, and a picturesque setting at the Saracen's Head.
• After a quick perusal of the PEAR IT/ITX modules for templating, finally dived into Smarty to speed up some CMS based PHP development and to avoid mainifesting globular chunks of XHTML within the API.
• A good starting point for developing DOM based Client Side Table Sorting scripts.
• The main set of Chrome URLs for Mozilla and Firebird (Still using it and loving it!)
• XForms is getting ever closer to REC status, and what a difference it will make to the laborious task of developing user forms. Of course you can easily test the benefits and potential in X-Smiles Java Browser during the inevitable laborious wait for implementation in the main player…
• Symantec's ever efficient security response to that sneaky critter lurking the web. Some friends fell foul within 48 hours of Blaster's release, and we had an arduous clean up session over the phone. Of course if your infected, you probably will not be reading this, at least not beyond the page title!!! At least XP users now know they are not 100% secure, as a certain corpora$ion would make them believe!
• Oh, and in less than 10 days I will finally be able to see what happens in the last 15 minutes of the Two Towers following an unexplained shut down of the cinema last Christmas. Still scouting for the official release of the RotK Trailer…

Posted on Aug 17, 2003 at 21:20:43. [Comments for A Few Quick TitBits- 0]