WEB STANDARDS CREATIVITY

Screen readers
Testing this solution with screen readers reveals a problem. If we return false when hijacking the hrefs (a common practice
to avoid the page “jumping” to the internal anchor/id that the href points to), then we leave the screen reader’s “cursor”
where it is. While we move the related navigational pane to the top visually, we are not providing the same access to a
screen reader. In fact, returning false removes functionality from the screen reader user—we’ve created a barrier by not
allowing the in-page jump.
How do we solve that problem? This is where we must examine accessibility and JavaScript again. If we had simply stopped
at making sure that our pages were usable with scripting on or off, we wouldn’t have realized the problems we are creating
for screen reader users. To reiterate, the scripting on/off scenario is more about basic interoperability than it is about accessibility
for people with disabilities.
One possibility is to not return false, and allow the history stack to take its course. In some cases, it may even be desirable
to do so. However, this would mean that we get the visually jarring “jump” within the page and also end up hiding the main
navigation, removing our toggle points from view. This solution is not particularly useful, and is likely to be annoying to users
and unacceptable to the people who sign off on the solution.
The other possibility is to return false, but use the href in the link and focus on that navigational pane. If we do this, we’ll
allow screen reader users to continue reading in the correct place and ensure that we are not covering up our navigation or
jumping all over the screen. This solution is implemented in the final files for this chapter.
Another screen reader issue is the close link. This may be confusing to screen reader users. In their minds, they have simply
moved to another part of the page, so why would they need to close anything? This link makes sense only to someone who
is visually looking at the page. To attempt to solve this, we use a close icon (the typical x graphic), with alt text that says
“return to main navigation,” with an appropriate href. Using the same strategy as applied for our main navigational links, we
hijack the href to place the screen reader cursor in the next logical place.
Keyboard-only use
A keyboard-only user will experience many of the same issues as the screen reader user. In particular, placing the focus in
the navigational pane will be critical to allowing a keyboard user to navigate properly.
One solution that may gain popularity over time is the use of an invalid value for the tabindex attribute. Assigning a tabindex
value of -1 to an element allows that element to receive the focus programmatically, but does not add it to the natural tab
order of the document. This solution is a bit controversial because of the invalid value—by specification, HTML requires
tabindex to be a number between 0 and 32767 (see www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex for
details).
Is the tabindex solution an acceptable one? IBM, Mozilla, and Microsoft all seem to think so, although representatives from
IBM imply that they know this solution is not quite right (see www.csun.edu/cod/conf/2005/proceedings/2524.htm):
Keep in mind that this is not yet part of any W3C or other official standard. At this time it is necessary to bend
the rules in order to have full keyboard accessibility.
chapter 10 Accessible Sliding Navigation
259