By now just about every web designer knows about web accessibility in some form or other. Whether it was noticing high profile legal cases in the US, or reading web development blogs, most people except that it's a good thing and should be part of any site design.
So why is it that whenever the accessibility of various sites is checked, they usually come up short? Nomensa was commissioned by the United Nations to conduct the first ever global audit of web accessibility. We tested 100 sites from 20 different countries and only three completely passed basic web accessibility checkpoints. None passed them all. Some high profile, long standing websites don't seem to apply the basics, issues that have been covered in the World Wide Web Consortium's (W3C) accessibility guidelines [8] since the last century.
The key stumbling block in the early days (until 2003) was creating attractive and accessible websites. The dominant development methods were using tables and spacer gifs to create pixel perfect layouts. Even website owners worried about web accessibility would not consider a basic looking site. The gateway technology was CSS, which allows the separation of content and styling, so you could have your cake and eat it – an accessible and attractive web site.
However, in the rush to adopt this 'new' technology, not everyone has really understood what it enables. For the purpose of this article, I'm going to assume you've joined the web standards revolution so I can focus on how to make your websites barrier-free for all.
Where web accessibility happens
Information Architecture
Ideally, accessibility considerations are included from the beginning, from when you define the content, structure and navigation of a site.
If navigation is not considered from the start you might end up with pages that have hundreds of links. Hearing a screen reader announce there are over 200 links on a page can give you a real sinking feeling. Although there are ways around the issue (for example, using headings to separate the page into sections), only providing the options the user needs at the time is beneficial to everyone. If you create a sitemap, check that none of the main sections have too many options. There isn't a hard and fast rule, but if your main navigation has more than 20 items at once it is probably worth re-thinking it. I tend to use an expanding hierarchical navigation that shows the top level and local navigation, but the principle is a usability one: don't provide too much choice.
Another check you can do at the sitemap stage is that links don't clash. Some people will get links names out of context, so check for duplicate page names. A common one is 'contact', where an organisation may have several different sets of contact pages. With a global 'contact' link you will get clashes unless you alter the links for the other contact pages.
If you produce page sketches or wireframes before the design stage, you can check how well sign-posted the pages will be. Knowing what the current page is and how you got there is something we might take for granted, but for people with memory issues, or using a screen magnifier, it isn't as easy. The main page heading should strongly relate to the link the person selected to get there. The title element should also match, I tend to use the format: Page name: Site name > section name. This puts the important information first, and the page name would be the same as the main heading.
Consistency of navigation is important for usability and accessibility, it also happens to be great for search engine optimisation (SEO) when combined with good HTML code.
Design considerations
Although most aspects of accessibility are taken care of at the HTML level, there are a few things to check at the storyboard stage.
The obvious aspect is contrast, is there enough contrast between foreground and background colours? This applies to all text on a page; however, it's most important for text within images, as that is difficult for the user to change. How much contrast is enough? The easiest way to check is using a small tool called the “Colour Contrast Analyser” [1]; it compares the foreground and background colours and gives you a green tick, or a red cross. I do tend to use the numbers suggested by Hewlett Packard, which allow for slightly larger range of colours and hasn’t caused any problems when testing with people.
Layout is another factor to consider at the design stage, although it will depend heavily on how it is coded later. One of the least common (but most useful) things you can do for accessibility is to use a flexible layout which scales well over a range of conditions.
At Nomensa, layout behaviour is accounted for at the design stage, and is probably the hardest thing for a designer to get used to. As part of the handover from design to coding, a description is provided to describe the intended behaviour of the design, which parts should flex and how. Also, large images are provided for the background images so that they cope with scaling well.
Front-end code
This is where the action is, and where most accessibility issues are created and solved. Separating style and content forms the basis of accessibility, and combined with valid, meaningful (X)HTML is the best foundation to start with.
Defining your underlying code by the meaning of the content is essential. Although HTML doesn't have elements to use for every situation, there are plenty to learn about and extend using 'XHTML compounds' as Tantek Çelik described at Web Essentials '05. [2]
One of the main problems recently is that many people have 'got' CSS, but not semantic (X)HTML. So instead of styling a heading, they will add <div class=”mainheading”> rather than <h1>.
When translating from design to code, it is important to know what you are trying to achieve, which is not pixel perfection. Even if it is just slight differences in how browsers render a font, you will never get pixel perfection across all circumstances. As Nate Keochley of Yahoo! said at @Media 2005:
“Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web.” [3]
Yahoo's graded browser support [4] is a practical approach, and fits nicely with accessible web development.
Before applying the design, you will need to establish what the order of the page sections are within the HTML document. Ideally, you would put the content first (well, after the logo and perhaps search box). The exception to this would be when the main navigation is text based and intended to be displayed across the top visually, in which case I'd put navigation at the top of the source order. Because people can increase the font-size, and it is virtually impossible to absolutely position things dependant on words wrapping, the navigation must go first in this scenario. Whichever is first, just make sure that you include a skip link to either the main content, or navigation, whichever is last.
We touched on flexible layouts in the design section, but it is at the coding stage that it has to come together. The range of possible methods are far too wide to cover here, but this is what a flexible layout should be able to cope with:
- A resolution of 800×600, at the largest font size in Internet Explorer, preferably with the accessibility options set to ignore font sizes.
- 1024 at regular and large font sizes.
- 1600 at regular and large font sizes.
There are no black and white rules about layout, but if you're layout is usable under those conditions you have made a best effort to make it accessible. For some example layouts, I wrote an article on the topic previously [5]. If you are prevented from using a flexible layout (for example, your client insists), I would seriously consider providing a CSS style switcher to allow switching to a flexible layout.
With a good HTML document and flexible layout, the biggest hurdles are over. As you use CSS to convert that document into the desired design, the main problems will be cross-browser issues. Dan Cederholm's “Bulletproof Web Design” is an invaluable book to have at hand, as he covers many of the CSS techniques needed for flexible designs in a variety of situations.
If your site uses JavaScript to add behaviour, there are a couple of things to consider. JavaScript is not evil, nor is it intrinsically inaccessible; however, it is a powerful tool that is easily misused. The aspects to look out for are that a website's content and functionality do not rely on JavaScript, and that it does not rely on mouse input. In general, if you follow the separation of behaviour from style and content, you won't go far wrong. Christian Heilmann wrote the original “Unobtrusive Javascript” article, which was written with accessibility in mind. The tests are to check are whether it works without JavaScript, and whether it works with a keyboard only. See the Nomensa.com example for what to look out for in accessible JavaScript and Flash.
This wouldn't be an article about accessibility without mentioning alternative texts, it tends to be something many people know of, but few do well. At the template stage, images tend to be place-holder images, logos, and perhaps spacers. Logos are something of a special case as they tend to be on every page, so should be very concise, often just the name. Spacer images in templates are not needed with a CSS-based layout.
For place-holder images, just make sure that the alternative text you use is either what it should be, or checked before going live! Jim Thatcher has done a great alternative text tutorial online [10].
Template Integration
Once you have your perfect template, the next stage depends on what you use to publish the site. In many cases you will be putting the templates into a Content Management System (CMS) of some sort, whether it is Adobe's Contribute, a blog, or a fully blown CMS.
How easy that process of integration is will depend on the application, but it's important to make sure everything is ready and tested before anyone starts adding significant content. Separating the presentational aspects usually makes this process much easier, but sometimes the application won't be able to keep the HTML as simple as we'd like.
Handing over responsibility
If you are hand crafting your own website, this won't be a problem, but many of us have to hand over the site to regular (non-technical) people and with it the responsibility for maintaining accessibility.
How much the author needs to know will depend entirely on the system you are using. Ideally, the program would prevent people from creating inaccessible markup, but in practice very few do. [6]
Anything you can do to prevent inline or custom markup will help in the long run, for example, if you are using a 'What You See Is What You Get' (WYSIWYG) editor, can you customise it? Remove items such as the font-chooser or colour picker, and add custom styles that the author can select. This is very useful for keeping to a style guide as well.
Also make sure that authors know to use list-buttons rather than just dashes at the beginning of lines, that blockquote is for quotes rather than indentation, and bold isn't a replacement for headings. If you can't enforce things through the editor, you can set up some styles to highlight problems, such as:
blockquote blockquote {background: #f00;} /* highlight double-quotes */
img {border: 2px #f00 dotted !important}
img[alt] {border: none !important;} /* set to default style. */
img[alt=""] {border: 2px #00f dotted !important}
The CSS above could be applied in the editing environment to highlight images without alternative text, and even with blank alternative text, which would be useful in the content area. Ideally, contextual help within the editing interface would support authors deciding on the best alternative text.
A common sight for homepages and overview pages is the 'more' link, where an overview finishes with “read more >”. Tabbing through a page and just getting “more, more, more”, isn't very helpful, so these tend to be better re-phrased as “read more about this subject”. Meaningful link names are important for accessibility, but they also help most people when scanning through a page. It can be a difficult habit to break, but always try to think how the linked pages title would fit into a natural sentence.
The best thing to drill into a new web-author is the importance of writing usable content for the web. Everyone has horror stories of off-line materials being dumped onto websites, but a good, concise writing style will help more people than any of the other tips so far. The Plain English guidelines [9] are a good resource for helping people, and there are training courses available as well.
Putting it all together
This has been a whirlwind tour of accessibility, if you take anything away, I hope it's the importance of using HTML for meaningful structure and CSS for style. There are a host of resources referenced, but if you still have questions head over to Accessify's forum [7], there are plenty of knowledgeable folks there only to happy to help, including me.
References
1) Colour contrast checker: http://www.nils.org.au/info.aspx?page=628
2) Tantek Çelik at web essentials '05: http://tantek.com/presentations/2005/09/elements-of-xhtml/
3) W3Schools taglist: http://w3schools.com/tags/
4) Nate Koetchley's @media slides: http://nate.koechley.com/blog/2006/07/12/my_atmedia_2006_slides/
5) Accessible layouts: http://alastairc.ac/2006/05/accessible-layouts/
6) Accessible WYSIWYG editors: http://alastairc.ac/2006/08/accessible-wysiwyg-editors/
7) Accessify Forum: http://www.accessifyforum.com/
19) DRC statistics: http://www.drc-gb.org/newsroom/key_drc_facts_and_glossary/number_of_disabled_people_in.aspx
8) Web Content Accessibility Guidelines: http://www.w3.org/TR/WAI-WEBCONTENT/
9) Plain English guidelines: http://www.plainenglish.co.uk/guides.htm
10) Alternative text tutorial: http://www.jimthatcher.com/webcourse2.htm
Picture annotations
1. You on Earth
The homepage in general is well focused without too many options. The pages are well sign-posted, with a clear main heading and navigation that highlights you’re current location.
The page also has a a flexible layout that expands and contracts with the window with of the users browser, fitting a wide range of settings.
The contrast of each background/foreground colour combination was checked, and even with the ‘rough’ look, maintains a good contrast.
1. The main heading on the page is marked up as an <h1>, and subsequent headings structure the page sections (for example, “Who on Earth?” is an <h2>). The heading is text; the look is achieved with an overlay image.
2. The main navigation is marked up as a list (<ul> and <li>s), sub-pages are a nested list within the main navigation.
3. The highlighted t-shirts are marked as a list, with an image, paragraph and link within each one.
(To view a larger version of the below images, please click on the relevant image)
This content page from PPUK again has a flexible layout, with good heading structure and general use of meaningful HTML.
1. The ‘skip link’ for people using a keyboard is implemented in a way that pops-up when a user tabs through the page, but does not appear otherwise.
2. The image is given a useful alternative text, for people using non-visual technology like a screen reader.
3. The content area is edited by people without HTML knowledge, but the interface is locked down so that styles outside of their design guidelines are not used.
Also, the link text used for each item is meaningful, rather than using a ‘read more’ or ‘click here’.
(To view a larger version of the below images, please click on the relevant image)
3. Nomensa.com
Our own homepage demonstrates accessible use of Flash and JavaScript. Whilst many people shy away from these technologies, sometimes their use is appropriate, and can be done accessibly. The key factors to ensure accessibility are:
- The pages starts as a standard HTML page, with content for the banner area (in this case an image with a ‘next‘ button.
- A script is used to detect Flash, including version, and then replaces the HTML area with the Flash.
- The Flash itself is accessible; you can tab into the area and hit the play button, and read the alternatives for objects within the Flash movie.
- If the user doesn’t have Flash, a small prompt to install or update is added.
- The buttons are standard links, added with the script. They control the Flash, whilst being fully keyboard accessible.
- The movie does not play by default, so as not to create an un-due distraction for people with cognitive issues.
- There is a link to disable all the scripting, in case anything is causing an issue and the user would rather fall-back to standard content.
(To view a larger version of the below image, please click on the image)
