• A link to Google Maps when JavaScript is disabled.
• Support for the Google AJAX API Loader.
• Using the small map control.
• Keyboard accessibility for all control elements within the map.

As a fallback without JavaScript — because people disable it, because their mobile device doesn’t support it, or because it gets filtered by corporate proxies — Patrick used the little known Google Static Maps API, but for some reason he missed adding the link to Google. Here is the fix:

1. <div id="map">
2. <a href="http://maps.google.com/maps ?f=q&amp;output=html &amp;q=50.110950+8.684666" title="Google Maps">
3. <img src="http://maps.google.com/staticmap?hl=en &amp;center=50.112267,8.678384 &amp;markers=50.110950,8.684666,red &amp;zoom=15&amp;size=500x300 &amp;key=[Your API Key]" alt="City map of Frankfurt" width="500" height="300" />
4. </a>
5. </div>

Then I changed how the map is embedded. As it seems that the API loader is more current, I preferred that way:

1. <script type="text/javascript" src="http://www.google.com/jsapi?key=[Your API Key]"></script>
2. <script type="text/javascript" src="/js/accgmap.js"></script>
3. <script type="text/javascript">
4. google.load( 'maps', '2', { 'language' : 'en' } );
5. google.setOnLoadCallback( GMAP.initMap );
6. </script>

Using the small control elements is trivial: SmallMapControl(). The next thing I wanted to change was keyboard access to all controls, in particular for the map type, i.e. Map | Satellite | Hybrid. Patrick refers to an id, but I found that all relevant controls have a title, so I just checked for that attribute. I also dropped setting the style attribute in JavaScript as that belongs in the CSS file. His original function GKeyboardPatch() now looks like this (note the while loop for a slightly better performance):

1. GKeyboardPatch: function( map ) {
2. var button, divs = map.getContainer().getElementsByTagName( 'div' );
3. var i = 0;
4. while ( divs[i] ) {
5. if ( divs[i].getAttribute( 'log' ) || ( divs[i].getAttribute( 'title' ) && divs[i].getAttribute( 'title' ) != '' ) ) {
6. button = document.createElement( 'button' );
7. button.setAttribute( 'value', divs[i].getAttribute( 'title' ));
8. divs[i].appendChild( button );
9. if ( divs[i].getAttribute( 'log' )) { // only control buttons
10. // override the IE opacity filter that Google annoyingly sets
11. divs[i].style.filter = '';
12. // should really set to 'transparent'
13. divs[i].style.background = 'url( http://www.google.com/ intl/en_ALL/mapfiles/transparent.png )';
14. }
15. }
16. i++;
17. }
18. }

Now remember I said I’d rather separate style and behaviour, so here are a some lines of CSS with the setting of width and height for the #map being most relevant, otherwise it will collapse:

1. #map {
2. height: 300px;
3. overflow: hidden;
4. position: relative;
5. width: 500px;
6. }
7. #maps-static, #maps-static img {
8. display: block;
9. }
10. #map span.note {
11. display: none;
12. }
13. #map button {
14. background: transparent;
15. border-style: solid;
16. border-width: 0;
17. cursor: pointer;
18. height: 100%;
19. left: -2px;
20. margin: 2px;
21. overflow: hidden;
22. padding: 2px;
23. position: absolute;
24. text-indent: -100em;
25. top: -2px;
26. width: 100%;
27. }
28. #map a:focus, #map a:active, #map button:focus, #map button:active {
29. outline: 2px dashed #61bf1a;
30. }

And that’s it, thanks again to Patrick for the solid foundation I built upon. Now download the JavaScript code and try to tab through the map below.

Actually on the other website I extracted hCard microformats from the page as well and displayed the addresses on the map, but I was lazy and used jQuery. I thought it doesn’t look well here mixed with Patrick’s clean DOM scripting, but feel free to take it from the original website.

1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?