The additional layers of markup for both the contact details and search layers are requested from the server using Ajax, which jQuery makes really easy. It’s common for such layers to be embedded in the page markup and hidden using CSS when the page loads. The information in these layers are for convenience and is available on other pages of the site, so it doesn’t need to be on every page. Using Ajax in this way also allows the markup for those layers to be easily maintain server-side.
That’s all fine for the majority of users. Let’s make sure we think about other users who may have different, and diverse, needs.
A more accessible interface
Sighted users see the lovely jQuery slide down effect when they click one of the activating links; it grabs their attention and shows them that new information is on the screen. If you can’t see, you need different feedback to tell you what’s happened when you followed the link, otherwise you might think that nothing has happened.
Using focus for feedback
We need to pick a focusable element in the new layer we’ve added to the page, i.e. a link or a form element. Conveniently – although, some might say by design – there are appropriate elements at the start of our new layers. In the search layer, it makes sense to focus on the search input of the form. In the contact layer, the first element is an email link, so we can put focus on that.
Keyboard focus can be brought about easily by calling
focus() on the required element, so long as the element is focusable. For example, after injecting the layer, we can pick it out the target element and give it focus:
Ironing out some creases
Where Ajax is involved, problems can occur when the screen reader updates its virtual buffer before the Ajax call is complete. The response to the Ajax call may result in a change in the browser, but that change is not passed on to the screen reader. As our Ajax calls are only executed when the script is initiated, that’s unlikely to be the case this time.
As a focusable element, the target link should be able to receive focus with no trouble, but in conjunction with injecting elements into the DOM, it doesn’t always work. However, there’s a fix.
Technically, setting a
tabindex value of -1 on our link before we give it focus results in more reliable behaviour from JAWS.
Update: I found out from Christian Heilmann that this is likely to be a symptom of Internet Explorer’s
hasLayout issues, which should mean that it can be fixed by triggering
hasLayout on the target element.
We’ve got one last problem to iron out. In some browsers, setting a tabindex value of less than zero will remove the element from the tab order of the page. Keyboard users will often make use of the Tab to navigate around the focusable elements of a page. The tab order is the sequence in which these elements are given focus as a user tabs around a page. As our link should be in that tab order by default, we’ve just removed it by messing with its tabindex. Setting the tabindex value to zero (and possibly blank, but I’d need to double check) will put the link back in its place in the tab order. I don’t recommend setting tabindex in markup, but if you happen to be doing so, you should set the tabindex back to its expected value.