What is Web Accessibility?
What is Accessibility?
Accessibility is treating everyone, no matter what their ability, the same.
Most discussions of accessibility first talk about disability. This implies that people with a disability deserve special treatment. This isn’t what accessibility is about—it’s actually a symptom of the way people have traditionally built buildings, web sites, and pretty much everything else in fact.
When you build things with the assumption that everyone is the same as you, then they will always be wrong for some other people. .
So, what does this mean for web site developers? The short answer is that you need to try to be more aware of the needs of the entire audience that might look at your site. A longer answer might require you to learn a little about the differing levels of ability people can have, and how they use computers. Your web sites should be usable by people whether they:
- Are blind or severely visually impaired, and listen to web sites using a screen reader, or feel them on a braille display.
- Are shortsighted, and blow them up to 200% font size.
- Have motor disabilities so can’t use their hands to manipulate a mouse, and therefore use a pointing stick to manipulate the keyboard, or an eye pointer to manipulate the web site.
- Use trackballs, or other more unusual types of computer control system.
Why is Accessibility important?
Accessibility is important for one big reason and a whole lot of little ones. The main one is that we are all different and yet we all have an equal right to use web sites, but there are lots of other reasons why you should make accessibility considerations a part of how you build web sites:
- In some countries it’s the law.
- You don’t want to exclude any potential customers/visitors from using your site.
- Accessible sites tend to rank higher on search engines.
- You are demonstrating good ethics—something that customers will value.
- Once you build web sites with web standards it hardly requires any extra effort to make it accessible, which gives so many benefits; there is also a lot of crossover between sites being more accessible, and sites being more compatible with mobile phone browsers—another circumstance that makes web site harder to use, although for different reasons. In fact, some work has been done on analysing the relationship between web accessibility and mobile web development best practices—see the WAI “Web Content Accessibility and Mobile Web” page for more.
- Techniques that help people with disabilities benefit all users.
Designing with Accessibility in mind
The key to accessibility is thinking about a problem and knowing you are going to solve it for more than one kind of user. If you try to treat accessibility like something you can bolt on at the end then you will get a nasty-bolted-on-at-the-end thing. It’ll take longer, won’t work as well and look damned ugly.
The best way to achieve a well-engineered solution is to design with all the requirements in mind from the start. This doesn’t mean you shouldn’t change your plan or add some things you missed, but you should try to be aware of what the complete problem you are trying to design for is. In the case of web sites this means creating a solution usable by all your users including those who may not be able to use a mouse, or a keyboard, or a monitor, etc.
Features of an accessible web page
One of the foundations of web standards is the use of semantic structure in HTML. Semantic structure is also extremely important for accessibility. This is because it provides the framework for the information on the page. When people can’t see the visual style of the page, the semantic structure helps to indicate a number of things to them. It can indicate their position in the hierarchy of the document and the ways they can interact with the different elements of the page, as well as providing emphasis to textual content in the right places.
A good example of how the semantic stucture of a document is important to accessibility is navigation. A well structured navigation menu is a list of items. You can mark this up as an HTML list:
<ul> <li>Menu Item 1</li> <li>Menu Item 2</li> <li>Menu Item 3</li> </ul>
By having navigation menus structured as lists it is easy to let someone using a screen reader, who can’t see the list, know it’s a list. This is because their screen reader tells them it’s a list. If you don’t use list markup then the screen reader has no way of knowing it’s a list and telling the user.
As mentioned in the section about search engines, ensuring that there is an accessible alternative to content and navigation is essential. Text is considered the universal currency of content with one caveat, as you’ll see below. Text can be easily read aloud by a screen reader, made bigger or smaller, have its contrast easily altered and many other transformations. It’s because it is so easy to manipulate text that more exotic forms of content should have a text-based alternative to them. Some formats, like the newer versions of Flash, have text access built into them so that the textual content within them can be accessed directly without needing to provide an alternative for the whole medium.
How should you implement text alternatives on your site? The first step is to identify things that aren’t already text. In HTML there are only so many things that aren’t already text. Images are the most obvious ones. Here is an example of an accessible use of an image:
<p>An interesting piece of art is Michelangelo’s “God creates Adam” <img src="images/adam.jpg" alt="A painting of a man reaching up to touch God’s hand reaching down. It is cracked with age." longdesc="adam.html">.</p>
The image in this example is an integral part of the content. The alt attribute contains a short description of the image for people (or search engines) that might not be able to see the image correctly. The longdesc attribute allows you to link to an HTML page containing a full description of the image. This is generally only used to describe complex images that are used as central content. It also suffer from poor support in browsers. Most of the time you will only use the alt attribute.
When images are used for things other than content, such as navigation, or purely visual decoration you should treat them differently from content images. Images used to make buttons or page navigation look more attractive should have an alt attribute that matches the text in the image. The alt attribute simply functions as an easy way to allow the computer to read the text contained in the image (and hence read it to the user of a screen reader).
In the case of purely decorative images, images used for tracking adverts, or any other image that a user wouldn’t be expected to be interested in or interact with, you should set the alt attribute to be empty. This does not mean omitting the attribute but setting alt=””. This is because of a tactic screen readers have used to help their users cope with very inaccessible pages. When an image doesn’t have an alt attribute, especially when it’s part of a link, the screen reader reads the URL of the image to the user. This is so they can guess what the image is from the URL, for example if the image is named something like add_to_cart.gif. Therefore, you should set alt=”” on images that you know the user won’t be interested in, so that screenreaders won’t read out every image’s URL, which could be rather frustrating for the screen reader user.
Not all forms of content are as simple as an image. More complex media like Flash (Flash files can be whole web sites in themselves) or movies require more complex descriptions. The most recent versions of Flash allow you to provide text alternatives for the items within the Flash movie, just like in HTML.
Standards for Accessibility
Web Content Accessibility Guidelines 2.0
Since publishing WCAG 1.0, the W3C has been working on WCAG 2.0. This updated version of the standard is still in draft at the time of writing. Subject to the process of the W3C it will probably be a published standard by early 2009.
WCAG 2.0 is slightly different in it attempts to be more technology-agnostic than WCAG 1.0, ie it could be applied to HTML, CSS, Flash, etc. WCAG 2.0 is based on 4 principles for accessibility. These are:
People can access the content through a medium available to them. For example people who can’t see should be able to hear the content
People can interact with the web application or content.
The content and user interface is understood by the people who are using it.
Any solution provided should be using widely available on different platforms or systems. This is to stop people inventing solutions that the majority of people wouldn’t be able to use because the hardware/software is restricted or prohibitively expensive.
It’s important to note that web sites aren’t expected to fulfill all of these requirements. The technology a user has should do some of the work too. For example it is expected that a screen reader will read pages to people who need it, rather than every web site providing an audio version of the content. However, the web site is expected to provide pages that can be read using common screen reading technology in order to make this possible. This difference is important, as it’s the difference between a web site with an “accessibility widgets” (like a button to make the fonts a bit bigger) and a web page that will work in a multitude of different situations (eg varying browsers and devices that would be impossible to anticipate).
Above material from The Web Standards Curriculum. This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.