We do a lot of things with Ajax In our web applications these days. Standard practice Is to fire off some sort of visual effect to give the user a clue that something has changed on the page. However, a person using a screen reader obviously isn’t going to be able to see any visual cues. The WLA-ARLA specification provides a pretty nice alternative solution that currently works in IE, Firefox, and Safari with various popular screen readers.
The AwesomeCo executive director of communications wants a new home page. It should have links to a “services” section, a “contact” section, and an “about” section. He insists that the home page shouldn’t scroll because “people hate scrolling.” He would like you to implement
a prototype for the page with a horizontal menu that changes the page’s main content when clicked. That’s easy enough to Implement, and with the aria-live attribute, we can do something we haven’t been able to do well before—implement this type of interface in a way that’s friendly to screen readers.
Let’s build a simple interface like Figure 5.1, on page 106. We’ll put all the content on the home page, and if JavaScript is available to us, we’ll hide all but the first entry. We’ll make the navigation links point to each section using page anchors, and we’ll use jQuery to change those anchor links into events that swap out the main content. People with JavaScript will see what our director wants, and people without will still be able to see all the content on the page.
Creating the Page
We’ll start by creating a basic HTML5 page, and we’ll add our Welcome section, which will be the default section displayed to users when they visit the page. Here’s the code for the page with the navigation bar and the jump links:
<!DOCTYPE html>
<html lang=”en-US”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<t i tle>Awe someCo</ti tl e><1 ink rel=”stylesheet” href=”style.css” type=”text/css”>
</head>
<body>
<header id=”header”>
<hl>AwesomeCo </hl>
<nav>
<ul>
<1 i x a href=”#wel come’VWel come</ax/l i>
<1 i x a href=”#services”>Servi ces</ax/l i>
<1 i x a href=”#contact”>Contact</ax/l i>
<1 i x a href=”#about”>About</ax/l i>
</ul>
</nav>
</header>
<section id=”content”
role=”document” aria-1ive=”assertive” aria-atomic=”true”>
<section id=”welcome”>
<header>
<h2>Welcome</h2>
</header>
<p>The welcome section</p>
</section>
</section>
<footer id=”footer”>
<p>© 2010 AwesomeCo.</p>
<nav>
<ul>
<1 i x a href=”http://awesomeco.com/”>Home</ax/l i>
<1 i x a href=”about”>About</ax/l i>
< l i x a href=”terms.html”>Terms of Servi ce</ax/l i>
<1 i x a href=”privacy.html “>Pri vacy</ax/l i>
</ul>
</nav>
</footer>
</body>
</html>
The Welcome section has an ID of welcome, which matches the anchor in the navigation bar. We can declare our additional page sections in the same fashion.
<section id=”services”>
<header>
<h2>Servi ces</h2>
</header>
<p>The services section</p>
</section>
<section id=”contact”>
<header>
<h2>Contact</h2>
</header>
<p>The contact section</p>
</section>
<section id=”about”>
<header>
<h2>About</h2>
</header>
<p>The about section</p>
</section>
Our four content regions are wrapped by this markup:
<section id=”content”
role=”document” aria-1ive=”assertive” aria-atomic=”true”>
The attributes on this line tell screen readers that this region of the page updates.
Polite and Assertive Updating
There are two types of methods for alerting the user to changes on the page when using aria-live. The polite method is designed to not interrupt the user’s workflow. For example, if the user’s screen reader is reading a sentence and another region of the page updates and the mode is set to polite, then the screen reader will finish reading the current sentence. However, if the mode was set to assertive, then it’s considered high priority, and the screen reader will stop and begin reading the new content. It’s really important that you use the appropriate type of interruption when you’re developing your site. Overuse of “assertive” can disorient and confuse your users. Only use assertive if you absolutely must. In our case, it’s the right choice, because we will be hiding the other content.
Atomic Updating
The second parameter, aria-atomic=true, instructs the screen reader to read the entire contents of the changed region. If we set it to false, it would tell the screen reader to only read nodes that changed. We’re replacing the entire content, so telling the screen reader to read it all makes sense in this case. If we were replacing a single list item or appending to a table with Ajax, we would want to use false instead.
Hiding Regions
To hide the regions, we need to write a little bit of JavaScript and attach it to our page. We’ll create a file called application.js, and then we include this file as well as the jQuery library on our page.
<script type=”text/javascript”
charset= “utf-8″
src=”http://ajax.googleapis.com/ajax/1ibs/jquery/1.4.2/jquery.min.js”>
</script>
<script type=”text/javascript”
charset= “utf-8″
src=”javascripts/application.js”>
</script>
Our application.js file contains this simple script:
Une l // HTML5 structural element support for IE 6, 7, and 8
document.createElementC”header”);
document.createElementC”footer”);
document.createElement(“section”);
5 document.createElementC’aside”) ;
document.createElement(“artic7e”) ;
document.createElementC”nav”);$ (function (){
$(“#services, #about, #contact”) .hide() .addCl ass (“hidden”) ;
$(“#welcome”).addClass(“visib7e”);
$(“nav ul”).click(function(event){
target = $(event.target);
if(target.is(“a”)){
event.preventDefault();
if ( $(target.attr( “href”)) .hasdass(“hidden”) ){
20 $(” .visible”) . removed ass ( “vi si ble”)
.addClass(“hidden”)
,hide() ;
$(target.attr(“href”))
.removed ass(“hidden”)
25 . addCl ass (“visible”)
. show() ;
};
};
so });
} ) ;
On line 11, we hide the “services,” “about,” and “contact” sections. We also apply a class of “hidden” to them, and then on the next line we apply a class of “visible” to the default “welcome” section. Adding these classes makes it really easy to identify which sections need to be turned off and on when we do the toggle.
We capture any clicks to the navigation bar on line 14, and then we determine which element was clicked on 17. If the user clicked a link, we check to see whether the corresponding section is hidden. The href attribute of the clicked link can easily help us locate the corresponding section using jQuery selectors, which you can see on line 19.
If it’s hidden, we hide everything else and then show the selected section. That’s all there is to it. The screen readers should detect the region changes.
Falling Back
Like roles, this solution can be used right now by the latest versions of screen readers. By following good practices such as unobtrusive JavaScript, we have a simple implementation that can work for a reasonably wide audience. Older browsers and screen readers will ignore
the additional attributes, so there’s no danger in adding them to our markup.
The Future
HTML5 and the WIA-ARIA specification have paved the way for a much more accessible Web. With the ability to identify changing regions on the page, developers can develop richer JavaScript applications without worrying so much about accessibility issues.