Accessible menu test

This is a test for replacing the menus on the TexasOnline website with non-proprietary, DOM-compliant, semantic, accessible, unordered lists. Toggle the CSS on this page to see what they look like without stylesheets.

I've also done another style experiments. Check out these menus with different stylesheets. Note: The other examples do not include the section skips and are listed as visual style examples only. The horizontal layout (demo2) does not work in Opera 7 do to a browser bug.

Note: The sub-menus are not available without JavaScript, but these are supplemental navigation. The TexasOnline site has redundant links available from each main section to every sub-section and is therefore completely accessible. Please do not note this as an error in your comments.

Bugs

Current bugs are noted here. Previous bugs are also available.

Mac IE 5. This browser does not correctly handle the "skip section" links added in the September 4th enhancement. I'm working to fix this problem, but email me if you have any ideas.

Enhancements

Enhancements noted by date.

September 4, 2003: sub-menu keyboard navigation (skip section links)

I haven't touched these in about 5 months (been busy at work), but a usability issue had been lurking that always bugged me: The menus were "accessible" from the keyboard (You could tab through all the links.) but not "usable" from the keyboard (Who wants to tab all the way to the last link?). I believe I've found an acceptable solution.

I originally wanted to allow the user to use the keyboard arrow keys to navigate the menu. This seems intuitive but has four drawbacks.

This solution would not be accessible if JavaScript was turned off and would probably only help sighted users using the keyboard.
Cross-browser arrow key events on links are overly complex and inconsistent. Letter key events on anything and arrow key events in form elements seem to work fine.
This solution would override or conflict with most GUI browsers' default use of the arrow keys to scroll vertically and horizontally.
This solution would no longer separate style from functionality. I have tried hard to keep the script independent of the stylesheets but implementing arrow keys would require knowing how the menus were supposed to look. Example: These lists should use the right arrow key to open submenus but drop-down lists (like demo2) should use the down arrow key.

Since the arrow keys were no longer an option, I thought about sub-menu anchor navigation. This has the benefit of working with screen readers and with JavaScript turned off, but has the unfortunate side-effect of scrolling the page to the link.

I used JavaScript to enhance this and cancel the link functinality but focus the target. If JavaScript is turned on, the user experience is the same, but the page only scrolls to the target link if it is offscreen.

Test by tabbing through the list with your keyboard. Please let me know if you have any comments or feedback for this solution.

Previous bugs

These DHTML menus had a few bugs on Windows browsers. In fixing these, I may have opened some new Mac ones. Any additional testing you can help with will be appreciated.

Windows IE 5.0 (that does not appear in IE 5.5 and IE 6.0). When you roll over the menu list, you'll see some movement due to what appears to be an extra space added to the containing <li> when the sub-menu <ul> is displayed. I have tried removing any inline space around these elements and I have also tried setting them to display as block and inline. Fixed. With comment hacks for WinIE 5.0, I removed display:block; on the links. The problem was that IE 5.0 would give extra line-space to the li when it contained two block-level elements (a and the sub-menu ul). This was incorrect behavior because the sub-menu had position:absolute; specified and should therefore have not taken any document space. There are still some slight cosmetic differences in Windows IE 5.0, but for the most part, it is much better.
Windows IE 6 bug. Replication steps: Go the the very last sub-menu in the third item: Education and Training > Community and Junior Colleges > Military. Hover over that item for at least 1/2 second and then mouse off without rolling back to the parent menu. Now when you mouseover Education and Training, you will see a ghost background-color of the descendant <ul> that should be hidden. The contents of that <ul> are not visible, but the background color is. Fixed. When hiding all menus, there is apparently an IE6 bug that does not set the display property to none correctly if the element has an ancestor whose display is already none. By modifying my 'for' loop to go through the element collection backwards, I could guarantee that I would hide all children menus before their parents. (I've seen this bug once on a different sub-menu since the fix, but can't seem to reproduce it now. Perhaps it was a cache issue or perhaps the bug just crawled in deeper. Let me know if you spot it.)
Windows Opera 7 bug. Inconsistent, but the most consistent reproduction steps follow: Mouseover the last menu item "Texas Sports". If the menu appears, "Road Reports" will most likely be the last item in the sub menu. Slowly mouse off the bottom of this sub-menu and you should see other items appear. The same thing happens with submenus of submenus. If you see no menu from the root menu, mouse out to the right anyway. It should appear as you roll over it when the hover color kicks in. Fixed. CSS positioning bug. I was previously relying on margin-left and margin-top to position the sub-menus. I added a relative position on the parent list-item and modified each submenu to use top and left properties instead of margins.
Netscape 6.x line-height defect. Not an issue in any other Gecko build I've tested. Looked fine the last time I checked in Netscape 7, Mozilla 1.3, Camino 0.7, and Phoenix 0.5. Cosmetic, functions more or less accurately. Can display a little better with height:1em; on the list-item, but this throws off Mozilla and more recent builds where this bug is fixed. Fixed. Added height:auto; to list-item anchors in a CSS2 selector. They were previously being set to height:100%; to compensate for incorrect IE rendering.
Gecko bug (Netscape 6, Camino 0.7, etc. but fixed in Mozilla, Phoenix, Netscape 7). The after hovering over some of the submenus, the margins start to run away and the body content moves to the right. I'm not actively pursuing this one because it is obviously fixed in recent builds and was therefore a browser defect, not a code defect. Fixed. Added float:left; to the containing element with a clearing element immediately following the nav.

Last updated: September 9, 2003.
If you have any other feedback, please email me.
Thanks to Karen Oh and Marilyn Matty for helping with the Mac testing.