Beginning Web Accessibility

So you finally decided to do the right thing and make sure your website is available for everyone to use. Of course, deciding to do something and actually doing it are two different things.  First you have to learn what it means and then start to do the work. I am going to assume you have learned what accessibility means, have studied the WCAG 2.0 AA success criteria and have access to the code of your website.  You will also understand basic HTML. We will work on the lowest of the low hanging fruit in this blog post, alternative text for images and image links (WCAG 1.1.1), using ARIA landmarks to identify regions of a page (WCAG 1.3.1)  and proper naming of links (WCAG 2.4.4).  

Let’s start with alternative text for images and image links.  As you can imagine, if you have visual problems the use of a image on your site for a purpose other than decorative, can make the purpose difficult to understand, so you need to provide a method to help people understand. That method is alternative text, a textual description of the purpose of the image. Notice it says purpose of the image, not a description of the image.  You have a picture of puppies playing in a field with the words use promo code puppies when checking out for a ten percent discount.  You don’t use an alternative text that talks about puppies, you talk about the promo code. How do you do this?  By using the alt parameter of the img tag as shown;

<img src="puppies.gif" alt="use promo code puppies when checking out for a ten percent discount">

When a screen reader user comes to your site the screen reader will read out the alternative text. Without the alternative text, the screen reader would says “puppies.gif”.  

The same method is used for image links.  If you have an image inside a link, a very common occurrence, you should still use the alt parameter, there are alternate methods, but you can’t go wrong with the alt parameter.  Example HTML below:

<a href="promo.html">

 <img src="puppies.gif" alt="use promo code puppies when     checking out for a ten percent discount">

</a>

Pretty simple, right?  We will now move on to a slightly more advanced topic, ARIA landmarks. ARIA (Accessible Rich Internet Applications) landmarks is a way to divide your page into logical sections. By providing landmarks, you enable users of assistive technology (AT) to more easily navigate to the sections of the page they want to interact with.  There are nine landmarks defined by the W3C and they are listed below. I wanted to be very clear about the definitions so this is directly from W3C wiki.  You can find the page here

banner: A region that contains the prime heading or internal title of a page. complementary: Any section of the document that supports the main content, yet is separate and meaningful on its own. contentinfo: A region that contains information about the parent document such as copyrights and links to privacy statements. form: A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing. main: Main content in a document. In almost all cases a page will have only one role="main". navigation: A collection of links suitable for use when navigating the document or related documents. search: The search tool of a Web document. application: A region declared as a web application, as opposed to a web document. (note: The role of application should only be used with caution because it gives a signal to screen reading software to turn off normal web navigation controls. Simple widgets should generally not be given the application role, nor should an entire web page be given the application role, unless it is not to be used at all like a web page, and not without much user testing with assistive technology.)

 

So how do you use these in your HTML?  The landmarks are defined as a role parameter to a another HTML structure, often a div, but not always. With the advent of HTML5 you can use specific tags, with varying levels of support by different browsers. Currently, you can and maybe should use both, although that can cause a repetition of the role to be spoken by the AT.  

OK, so let’s look at how you should divide up your site in a way that makes sense.  The WC3 has an example site, so we will use that as our example. The top part in gray is the banner The two reddish blocks on the right side are complementary a the green box on the left side is navigation, and the blue box is main with a teal region at the bottom of the main. Remember landmarks can be inside landmarks and often all. The typical retail site will have a banner at the top that includes a search landmark and at least one navigation.

So how do you do this in code? A banner could be defined like the following

Banner definition pre HTML5

<div role=”banner”>

<ul>

<li> your menu  other stuff ....

</ul>

</div>

Banner definition HTML 5

<header>

<ul>

<li> your menu  other stuff ....

</ul>

</header>

Remember, it wouldn’t hurt to add the roles to the HTML5 code just now, many people consider it best practice, but you need to come up with your own policy for that, perhaps do some user testing with disabled users and get their opinion.  You should be able to remove the repetition soon as browsers become more compatible. Below is a table of HTML tags to roles.

HTML 5	ARIA Role
<header>	role=”banner’
<nav>	role=”navigation”
<main>	role=”main”
<footer>	role=”contentinfo”
<aside>	role=”complementary”
none	role=”search”
<form>	role=”form”

<section> and <article> match up to role=”region” and role=”article” but these are not ARIA landmarks..

Whew, done with landmarks, they are bit more difficult but can add real value. Now let’s move on to the last topic in this tutorial, links.  The web depends on links more than any other functionality and accessibility depends on having meaningfully described links.   What is a meaningfully described link and how do you define one in HTML?

People who use screen readers don’t want to have to let the AT read the whole page.  Think about the way you use the web. You will scan the page looking for things that interest you.  People with advanced degrees in design spend a lot of time designing web pages to catch your eye.  Now assume you have vision problems. You would not want to have the whole page read off to you, would you?  Users of AT will use the tool to scan for links, images landmarks, etc. and skip around the page, just like you do with your eyes, searching for what they came for. If the page is not accessible, it is impossible. You will lose a customer.

Let’s define some accessible links and some not accessible links.  We are going to pretend we are a small retailer with three locations.  Imagine we want to have picture of the three stores with a link to a set of driving directions below each picture.  Generally you might see something like this;

<html>

<div id=”store”>

<ul>

<li>

<h3>Bingingham Store</h3>

<img id=’store1" src="store1.jpg" height="150" width="auto" ></img>

<a id="directions_store1" href="direction1_store1.html">Driving Directions</a>

<br>

</li>

<li>

<h3>Bingingbeef Store</h3>

<img id=’store2" src="store2.jpg" height="150" width="auto"></img

<a id="directions_store2" href="direction2_store1.html">Driving Directions</a>

<br>

</li>

<li>

<h3>Bingingchicken Store</h3>

<img id=’store3" src="store3.jpg" height="150" width="auto"></img>

<a id="directions_store1" href="direction2_store1.html">Driving Directions</a>

<br>

</li>

</ul>

</div>

</html>

From this you would get a page that looks like this;

As a sighted user you would imply that the Driving Directions link would take you to directions to the three different stores. As an AT user you would the list of links would each look the same with no idea what the driving direction were for.  For example, Voice Over on Mac uses a window they call the rotor to access the different parts of a page. It would read out three links that just said driving directions with no context. If you were to code the page this way;

<html>

<div id=”store”>

<ul>

<li>

<h3>Bingingham Store</h3>

<img id=’store1" src="store1.jpg" height="150" width="auto" aria-hidden="true" ></img>

<a id="directions_store1" href="direction1_store1.html" aria-label="Driving directions to the Bingingham store">Driving Directions</a>

<br>

</li>

<li>

<h3>Bingingbeef Store</h3>

<img id=’store2" src="store2.jpg" height="150" width="auto" aria-hidden="true"></img>

<a id="directions_store2" href="direction2.html" aria-label="Driving directions to the Bingingbeef store">Driving Directions</a>

<br>

</li>

<li>

<h3>Bingingchicken Store</h3>

<img id=’store3" src="store3.jpg" height="150" width="auto" aria-hidden="true"></img>

<a id="directions_store1" href="direction3.html" aria-label="Driving directions to the Bingingchicken store">Driving Directions</a>

<br>

</li>

</ul>

</div>

</html>

As you can see from the above code, I have added two new parameters, aria-hidden=”true” and aria-label=”description of link”.  The aria-hidden=”true” parameter will cause the AT to ignore the image completely.  It will not be a tab stop and the screen reader will skip over the image.  I have done this because the image adds no value.  It is meant to attract the eye.  Secondly, I added a detailed description of the link. Now the screen reader will read that label instead of the original text of Driving Directions. Makes sense?  There are other ways to make the page accessible, this example is just one way.

We have now addressed three different WCAG success criteria.  Be aware that the examples shown do not fully illustrate the success criteria, they only describe one item each of each of the success criteria.  Opening up code is not the best place to start.  Get a third party like Usablenet to do an audit of your website to show you all the accessibility issues you may have and work your way through them. Thanks for taking time to read my tutorial and I welcome your comments and questions. Check back periodically for new blog entries on accessibility topics.