Accessibility for Websites – A practical guide

Posted on: October 21st, 2009 by dominicj

In this article we look to bring you a practical guide to accessibility guidelines on the web – what they are, what they mean and how to adhere to them. We then look at the top 5 myths surrounding website accessibility as well as giving you some helpful tips to make your website as accessible as possible. Please feel free to leave feedback.

1) Introduction to the Disability Discrimination Act 1995

The Disability Discrimination Act 1995 came into force on the 1^st of October 1999. Part 3 of the act refers to the provision of goods, facilities & services, this includes the provision of websites.

Relevant points from the 175 page document:

2.2(page 7) ” The DDA makes it unlawful for a service provider to discriminate against a disabled person by refusing to provide any service which it provides to members of the public.”

4.7(page 39) “From 1^st October 1999 a service provider has to take reasonable steps to change a practice which makes it unreasonably difficult for disabled people to make use of its services.”

2.13 – 2.17(pages 11 – 13) “What services are affected by the Disability Discrimination Act? An airline company provides a flight reservation and booking service to the public on its website. This is a provision of a service and is subject to the act.”

5.23(page 71) “For people with visual impairments, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include…accessible websites.”

5.26(page 68) “For people with hearing disabilities, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include…accessible websites.”

The Code of Practice, published in May 2002, which specifically mentions websites, can be downloaded in its entirety from the DRC (Disability Rights Commision) website.

2) How do we comply with the Disability Discrimination Act

As the act is untested in reference to websites (as at 9^th April 2006, all tests have been settled by the site in question being made accessible rather than going to court for a ruling, this is most likely due to the adverse publicity that may be involved) it is hard to ascertain how we should comply (or how much). However, the common consensus is that should the act be tested, the W3C Accessibility Guidelines will be used to assess a given websites accessibility. To complicate this, though, there are three levels of compliance.

Priority 1 guidelines (which must be satisfied according to the W3C).
Priority 2 guidelines (which should be satisfied and are the EU recommended level of compliance).
Priority 3 guidelines (which may be satisfied to enhance websites accessibility to the limits of current technology, and most likely future technology as future technologies are likely to be built with accessibility compliance).

Priority 1 will almost certainly have to be adhered to, with all or part of priority 2 having to also be adhered to.

3) Top 5 myths about website accessibility

1. Its complicated & expensive to create accessible sites

To develop an accessible site will cost virtually the same amount as to develop any website. Fixing a large inaccessible site may take some time but the benefits can far outwiegh the costs (through increased customers & increased usability or search engine friendliness etc.).

2. Creating a text only equivalent is sufficient

This is not necessarily true as text only versions are not necessarily any more accessible than their all singing all dancing siblings. For example, a list of items in a table may be read in a confusing manner by screen readers, whereas, in an html list it will always be read in a correct manner. On top of this a further version of the website may be costly and could involve a time investment. But, possibly more importantly, it may not be the best marketing strategy or good for society as a whole, to marginalise blind and disabled users from our websites by creating a separate version.

3. Accessible websites place restrictions on design & creativity

This is not true. For an example of the multitides of approaches to a single accessible website design see Dave Shea’s CSS ZenGarden [www.csszengarden.com].

4. Blind & disabled people don’t use the internet

This is possibly the most bizzare of all the myths surrounding website accessibility. This quote from Tim Berners-Lee illustrates the use of the internet in levelling the playing field (if you’ll pardon the cliché) for all users:

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, W3C Director & inventor of the World Wide Web

5. Accessibility is not a legal issue as it is not mentioned by the Disability Discrimination Act.

This is untrue, as part 3 of the Disability Discrimination Act refers to the provision of goods, facilities and services. It is true, however, that this part of the act does not mention websites specifically, but then it does not mention any specific services. However, other parts of the act do mention websites.

5.26(page 68) “For people with hearing disabilities, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include…accessible websites.”

These passages from the act cover creating websites that makes sense and are usable to those using text browsers, screen readers and braille pads as well as other assistive technologies. This will need the correct use of lists, alt text or longdesc tags on images, labels on forms, well drawn and annotated graphics, transcriptions and subtitles.

4) Testing a websites accessibility…

The basic tests you can do to test your site for accessibility include:

1) Check informational images for alternative text

To test this in IE is relatively simple as Microsoft have incorrectly implemented the alt tag to display as a tool tip when hovering over an image. For users with images turned off, browsing by screen reader or braille pad or whose browsers do not support images, this is what they will see or hear in place of the image. Does the text make as much sense as the graphic it replaces? Could it be better written?

2) Check decorative or dummy images for alt text

Like informational images, decorative or dummy images should have alt text, however, the alt text attributes value should be blank [i.e. alt=""]. This is due to the way screen readers in particular read out pages to their users. If a screen reader comes across an image without alt text it will alert the user to the images existence but not to any context of the image. This will get pretty old for a user who is sitting through a site with rows of dummy gifs hearing “image” read out by their screen reader twenty or thirty times in a row before they have even got to any content. Also beware of giving the alt text for decorative or dummy images a value such as null or image, this would exascerbate the problem. Imagine sitting through twenty dummy gifs hearing either “image null” or “image image” read twenty times, that is 40 times of hearing the word image repetitively in the second case, which is enough to send anyone postal. This can be worsened if alt text is left out altogether for dummy images as some screen readers read out the file path to the image.

Writing alt text for images:

Dummy images [spacers, null, shim etc.] should be assigned an alt value of nothing e.g. alt=”".
Bullets and icons will also need an alt value of nothing if they are using images.
Eyecandy should also be assigned an alt value of nothing, as they have no meaning to the user other than to make things pretty.
Textual images, i.e. Any image where the image is only text using a fancy font or similar e.g. headings, navigational images etc., should only repeat the text within the image and not expand upon the image.
Company logo should have alt text repeating the text in the image, although some people may use the term “logo” in the alt text too, this is not wrong but is often not necessary. If the logo is also a link to the homepage this link information should be correctly put in the title attribute of the image tag.

3) Turn of your volume for video or audio content

This test will help you judge whether the content of the audio or video is correctly delivered for people with hearing impairments. The use of transcriptions and captioning can help with this. A useful captioning tool for Windows is Magpie [http://ncam.wgbh.org/webaccess/magpie/]

4) Check that forms are accessible

If you click on the prompt text next to each box of a form does the cursor appear in the relevant box? If so good, the form is accessible, however, if not consider the use of labels to help create an accessible form. See the section on creating accessible forms later in this report.

5) Ensure that text can be resized

Try resizing the text on the site using the browser controls [View>Text size>Largest on IE on windows]. If it doesn’t resize then you may have a problem. This could be due to the way you are sizing text in the CSS. For more on this see the next section.

6) Check your site in a text only browsers

Websites can be checked in the Lynx browser to see how it will render in a text only interface. This might reveal not only problems with your code but also in the documents architecture, for example is there a lot of extraneous information on the homepage before you get to any navigational links, are the navigational links easy to understand, will the user understand where they are going?

7) Try navigating the site without using your mouse

Not everyon can use the mouse to click around. Assistive technologies allow users to use keyboards to navigate and voice commands, try using the tab, shift tab and return keys to navigate in IE.

Is there a site map?

This is a good tip for general usability as people may get lost on your site so can use the site map to find their way around.

9) Is all the link text contextualised?

Often people use “click here” as the actual link text to click. People using assistive technolgies can cycle through the links on the page without hearing the text or images surrounding those links so will this text make sense out of context? Using correct text to contextualise the link itself will help not only the accessibility but also may help with SEO.

10) Use automated accessibility checking programs

These programs can not be relied upon for all accessibility checking as they will not be abe to tell you whether the context of the link is correct. However, they may be able to help spot some areas of your site that need improving. WebXACT [http://webxact.watchfire.com/] and Wave [http://www.wave.webaim.org/index.jsp] are two free programs that you can ceck your site with.

5) Making your site more accessible

Accessibility is not only about making sites more accessible to those using assistive technologies. You can also make sites more accessible to everyone by considering how we all look at web pages and designing for that. It is true that most users do not read the whole of a web page but they will more likely scan it looking for relevant text to them and their objectives. We can help by laying out our pages with the more important information and links towards the top of the page using contextual links [no "click here" link text], heading, bold [strong], bulleted or numbered lists etc. Each of these should be descriptive so the user can make a judgement on what they need to read and what they do not.

Separating style and content can help you site to be more accessible. This means that the pages style is all contained within the style sheet rather than the html. This will help your pages be ready for the future with the emergence of handheld devices, webTV etc. The main tenet behind this is to layout pages using CSS for all style and layout and remove as much styling from the document as is possible. The idea also encompasses semantic coding, i.e. Using lists for lists of items such as navigational links. For the purposes of web accessibility though you should avoid using styling elements [often referred to as presentational elements] in the page as this may cause accessibility problems.

As mentioned earlier text should be resizable by the user. This is due to users either needing smaller or larger text for it to be readable to them. Within the style sheet text should be sized in %ages, or ems and not in pixels. Pixel sizing is not resizable in Internet Explorer although it is in other browsers. Somewhere around 75% is equivalent to a 10 pixel sizing so a font-size of 75% in the body rule of the style sheet should allow you to have a base to work from across your document.

Forms are one of the main areas that can be helped with regard to accessibility. Forms are usually the main objective of many commercial websites whether they are used for buying products, registering for an event or membership or even contacting a person to ask a question.

Making forms accessible:

All form items should have prompt text, e.g. if there is a text field requiring a users name it will labeled with prompt text “Name”.
Use the label tag for prompt text and make sure its for attribute matches the id of the form element it relates to,

e.g. <label for=”name”>Name</label> <input type=”text” id=”name” />

Position prompt text in its correct position. This is generally held to be to the left or above of input boxes, textareas, and dropdown boxes and to the right of radio buttons and checkboxes. This needs to be positioned correctly within the HTML code before any CSS positioning so it works this way even when CSS is turned off or unavailable.
If for whatever reason you can not use a label for your form element then use the title attribute of the input tag.
Grouping items in the form such as all the personal details or questions relating to a particular area can help with accessibility and usability. This is done using the <fieldset> and <legend> tags. A fieldset would wrap the part of the form and legend gives this grouping its heading.
Grouping dropdown information can also be helpful by using headings within a dropdown box if needed.
Do not use Javascript to activate a form on clicking a choice in a drop down select box as it is totally inaccessible to screen readers or users with Javascript turned off. Always use a go button or relevant submit button.
Using Placeholding text. Some older screenreaders do not allow users to edit an input box if it does not have any placeholding text. This is a priority 3 guideline from W3C. However, it is debatable how many people are using such archaic screenreaders so it is debatable whether it is useful. [I tend not to use it as it can often confuse other users from a usability point of view if the form is already filled in].

6) Benefits of Accessibility

The benefits of accessible websites include:

Reaching the largest possible user base
Future compatibility with emerging technologies [handheld devices etc]
Compliance with the law
Easier management of the site [e.g. changing the style sheet can redesign the whole site. See: www.csszengarden.com for an example of this]
Making a site accessible automatically helps to optimise the site for Search Engine visibility
Quicker download times
Enhanced usability
Extra press release to let everyone know about your accessible site