Developer's manual

The need for duplicate menu links

Whatever method you use for creating menus, some browsers will never be able to see them; this includes partially-supported browsers such as Opera 5 and 6, and any fully-supported browser with CSS enabled but javascript disabled.

Therefore, since the navigation bar (the top-level of links) is the only component which is universally accessible, you will need to provide duplicate links for sub-menu content - anything which is accessible from the menus must also be accessible without them.

You'll probably find this happens quite naturally, in the form of section indices, inline links, a sitemap and so on. But nonetheless it's worth keeping an eye on - don't rely on the menus alone for universal access.

Navbar headings

If you put a heading immediately before the navigation, it's useful to people who use a serial device such as a screenreader or text-only browser - this type of browser will generally have a "headings list" or "headings-reading mode", which can be used to jump directly to the navbar if it's labelled with a heading.

If you put headings inside the navigation as well - such as an <h3> around each navbar link - it should improve usability for serial browsers by allowing them to skip from branch to branch; again, using their headings-reading mode or equivalent. Internal headings also provide additional semantics that should help to distinguish a navbar link from a menu link.

<h2 id="navbar">
	<a name="navbar">Site navigation</a>
</h2>

h2#navbar {
	position:absolute;
	top:-10em;
	left:-10em;
	}

<ul id="udm" class="udm">
	<li><h3><a href="/">Home</a></h3>
	</li>
	<li><h3><a href="/menu/">About</a></h3>
	</li>
	<li><h3><a href="/contact/">Contact</a></h3>
	</li>
</ul>

"Skip" links

A "skip" link is an an internal page anchor, that allows people using a serial browser to jump past, or to, a particular section of content.

In the case of "skip past" links, the purpose is so that a reader doesn't have to listen to, or manually tab through it. I've added such links to the code examples in this manual, and the same thing is necessary for your navigation bar, unless it's at the very end of the source code.

In the case of "skip to" links, the purpose is convenience since it allows quick access to commonly-used page areas, such as site navigation, or main content.

Please note: for the benefit of this script you must not use any of the links in the menu tree itself as a named-anchor for "skip to navigation", or it will create an accessibility problem for some browser-based screenreaders. Please see Notes about browser-based screenreaders for more about that.

Notes about browser-based screenreaders

The menus are accessible to any browser-based reader using Opera, Mozilla, Safari, Konqueror or Windows Internet Explorer. This works because the menus are neither hidden nor undisplayed by default - they are rendered and visible, but positioned off the screen so that they appear to be invisible to sighted users, a technique that's become known as "offleft positioning". This has been tested and confirmed in JAWS 5.0 - 7.0, Windows Eyes 5.0 - 5.5, Connect Outloud 2.0, Hal 6.5 and Home Page Reader 3.

Modern browser-based readers fall into two broad categories, as far as this script is concerned: those that generate focus events when navigating links, and those that don't. In those that do the menus will behave exactly as they do for anyone who navigates with the Tab key (although of course a user who's blind won't see the menus, they will open and close). In devices that don't generate focus events, the menus will remain closed at all times, but the user will still be able to navigate their links, because of this offleft positioning.

In fact the screen reader user themselves won't notice any difference - the entire structure is accessible at all times in all supported devices, and all links can be navigated to, heard and actuated.

But opening and repositioning a menu which has this offleft positioning is very processor intensive, particulary if it has many child branches, so to prevent a significant slowdown of the script for all users, any mouseover or focus event which causes a menu to open will reset the styling back to regular display toggles, and from that point onwards the menus are no longer accessible to screen readers which don't generate focus events while navigating. Of course this shouldn't normally matter, because if they don't generate the events, they'll never trigger the scripting that causes this.

However there are unique circumstances in which this group of devices will generate focus events:

1. If you target an internal page anchor to a link in the navigation bar, the focus event that's generated will trigger a reset; you can avoid that by not using navbar links as targets.
2. Some screenreaders scroll the browser window as they read, and if the computer has a mouse attached, and the mouse should happen to pass over any menu-triggering navbar items, the mouseover event will also trigger a reset; I don't think that can be prevented, but neither do I think it particularly likely.

For someone who navigates with a mouse and a reader, it should be just the same as navigating without a reader, functionally speaking.