A website I’ve just been working on (Pobol Peblig Partnership) is currently being audited by the RNIB under the RNIB See it Right accessibility standard. This article covers some of the things we learned through the audit process, with background information to help understand how to approach building accessible sites and then gives some practical tips and things to remember.
Who are your visitors?
Your website visitors are likely to be a diverse group of individuals with different levels of experience, using a variety of different web browsing technologies as well as having a range of needs and preferences. Someone who is partially sighted, for example, may have difficulty viewing a particular webpage but increasing the text size will allow them to read it. A visitor with a slow internet connection may decide to turn off the images to make download times quicker.
Note: Mark Pilgrim introduces us to a diverse bunch of internet users who use the net in a variety of ways in his excellent download Dive into Accessiblity.
What are they using to view your site?
There are different assistive technologies out there to help you if you have particular browsing needs such as screen readers, brail displays or alternative user input devices. Many of these work along side a visual browser. Alternatively you may prefer not to use additional assistive technologies but instead, tailor your visual browser to meet your particular requirements. Or do a bit of both.
The key thing to remember is that users have found their own way to do things based on the technology they use, practical necessity and personal preference. As web designers, who are we to tell our users what to do? An interesting piece anecdotal evidence that illustrates this, relates to website keyboard shortcuts or “access keys”. Although aimed at users with motor difficulties, apparently the majority of users who use access keys are actually web developers who routinely use keyboard commands in their day to day jobs.
Although including access keys is necessary for WAI priority 3 compliance, there are issues with its use and it is not required for See It Right. For more info read the RNIB’s article on access keys.
Anyway, to give your visitors the potential to have the best experience possible, whatever their browsing needs or preferences, your web design must be as robust as possible, allowing for text and colour change and able to be viewed with images turned off both with or without css styles. You should also be able to use your website without scripting or plugins. This is known as graceful degradation which means the same thing today as it did in 2002 when Peter-Paul Koch suggested:
The first step in adapting [graceful degradation] successfully is fluid thinking: accepting the unpredictability that rules the user interface of the Web.
See It Right
Although our design ticked quite a few of the accessibility boxes, we missed the mark on a number of points. Although we were thinking about accessibility from the beginning of the build, our main error was to follow our perceived wisdom as web developers/designers rather than thinking first and foremost about how the site would be used.
Bim Egan who did the audit for us was extremely helpful and her explanations were clear, and solutions offered, logical and practical. The common thread through all the different solutions we implemented was “empathise with your users”. Read more about how See It Right can benefit your visitors.
The following tips are not a how to or check list but just a few of the key issues we tackled during the audit.
Text size and positioning
You should be able to increase and decrease text size by 3 times without any text being obscured. This can be a challenge when absolute positioning has been employed and elements have been pulled out of the flow of the document.
However, by using a combination of relative (em) and absolute (px) units for position, dimensions, margin and padding, most layout designs can display at 3x decrease and 3x increase. If it isn’t possible you may need to rethink the way you’ve implemented your layout. That’s the last thing you want to do at the end of a build so its a good idea therefore to test that 3x text size increase and decrease (in different browsers) from the beginning.
Alt text
Alt text can do more harm than good. Badly written alt text can be confusing and make a passage of text difficult to understand. Use an empty alt attribute on purely decorative images.
How do I decide if an image is purely decorative? Well, ask your self if the meaning of a document can be fully understood by reading the text. If so, the image could be considered decorative as the text provides enough explanation for the meaning to be expressed. For users with images turned on in their browsers the meaning may be enhanced by a decorative image. But for a user browsing without images, the use of an ill considered piece of alt text can be very confusing. We were given the following advice in the audit
It might be pertinent to consider all content images decorative, unless they are linked images, images of text, or convey real information that helps to make sense of adjacent text.
You may decide that alt text is needed to give your page equal meaning to those browsing without images or those who find it difficult to see images. If you do, check how the alt text ‘reads’ in the context of the rest of the copy.
The key is to ensure that ALT text is given to images that convey content or bring meaning to a page. Using null ALT text for other images prevents the user experience becoming cluttered with redundant information for a screen reader user. Web Access Centre
Examples
The following examples from the audit show how alt text can be confusing for screen reader users:
… the image “Ty-Cymunedol.jpg” immediately below the question “What is the Pobol Peblig Partnership?”, audibly follows with the information from the ALT attribute “outside Tyˆ Peblig”.
In another example on the same page, the question, ” Who is the Partnership?, the image ALT appears to answer “2 Peblig Pensioners”
The Audit goes on to say:
Ideally, ALT attribute text should not appear to be a change of subject, interrupt reading flow, nor be misleading
When images are used as links
Functional images such as links use a combination of plain text and alt attribute to make the meaning of these non-text elements clear to text only browsers and screen readers. Read the link text plus alt attribute to check they make sense. Remember screen readers can’t just ignore links, and will announce the file path to the image, when there is no text available.
Our helper links to ‘print page”, “download pdf’ or ‘email to a friend’ used the following images 
, with respective alt attributes: PDF, Print, E-mail. The problem with this code was that users without a mouse wouldn’t get a tool tip and, if they hadn’t seen the icons before or couldn’t see very well, the purpose of the links would be unclear.
The solution was to include link text (PDF, Print, E-mail) next to the image then add the following alt attributes
- “pdf_button.gif”: ” version of this page: (new window).”
- “printButton.gif”: ” of this page : (new window).”
- “emailButton.gif: ” to a friend: (new window).”.
The end result will be three links, announced by screen readers as:
- “PDF version of this page: (new window).”
- “Print version of this page: (new window).”
- “E-mail to a friend: (new window).”
The right tool for the job (or the riddle of the nested lists)
Inspired by Andy Clark’s book Transcending CSS I tried to make sure my site template had a meaningful order underlying the page organisation and attempted to make the most of the xhml elements available. During this process I decided to use unordered lists to create a structure within my document. For example I created a list to hold supplementary information which highlighted features in the rest of the site. I used css to display the list as a colourful side bar. This is the xhtml I used:
<li class="supp2"> <h3>Get Organised</h3><p><a href="">Resources pages</a></p></li> <li class="supp3"> <h3>Reports</h3><p>The partnership is drawing up reports</p></li> </ul>
Unfortunately I hadn’t taken into account the complexity of the content of each box. Some of the feature boxes contained lists of events or related projects, some contained archive links or project summaries. So my sidebar list items were expanding as the website was populated
Lists are used to describe a group of objects or bits of information that are similar in some way. It might also be useful to have a preceding header to describe the list. . A website user will use bullet points and the header to quickly get information about a list and the items within it. A screen reader user will receive the same information, but by listening to the information being read out.
Here is an example of a simple list of events being read out by a screen reader:
- What’s on?
- List of 4 items
- bullet SBARC!
- bullet Arts & Craft
- bullet SBARC!
- bullet Storm O Stori Calan Gaeaf
- list end
Unfortunately this simple list was nested inside my supplementary list, so if you are listening to a screen reader to access this page you will hear:
- What’s on?
- List of 4 items nesting level 1 (contains 4 nested lists)
- bullet List of 1 items nesting level 2
- bullet SBARC!list end nesting level 2
- bullet List of 1 items nesting level 2
- bullet Arts & Craftlist end nesting level 2
- bullet List of 1 items nesting level 2
- bullet SBARC!list end nesting level 2
- bullet List of 1 items nesting level 2
- bullet Storm O Stori Calan Gaeaflist end nesting level 2
- list end nesting level 1
It may sometimes be useful to code headings inside lists item content. However it is worth remembering headings also provides extra wordage in a screen reader which can add to confusion rather than enhance meaning. As it would probably be stretching the useage of a list to use it as a structural element, I will be using it in the future with more caution!
Semantic Flow and Tab Index
It’s important that the content in a document makes sense without css style information to guide the user around the page.
Equally when style information is being used to position elements on the page the order should still be logical. In other words the focus should move in a consistent, regular manner and not hop back and forward when tabbing through the document.
Although we’d carefully planned the semantic flow throughout the document, the way we’d positioned some of the elements on the page meant a jump across the page while tabbing through. When we fixed this by repositioning some of the elements, the page actually worked better visually, as well as allowing a logical tab order through tabbed elements on the page.
Remember if your page content is organised logically there is no need to use tab index and often, if tab index is used inconsistently resulting in an illogical tab order, it can be confusing and obstructive.
Validation, validation, validation!
… And finally if you validate your code, both xhtml and css, you are probably well on the way to being accessible without even trying!