Ensuring your Website is DDA compliant
by David Gilroy, Conscious Solutions
www.conscious.co.uk
This article is intended to be read by anyone who has the desire to ensure that their website is “accessible” and compliant with the demands of the Disability Discrimination Act. – There are about 10 million adults in Britain covered by the Disability Discrimination Act (1995) - you can’t afford to ignore this issue and get away with it for ever!
When I was asked to write this article, I was told to “tell it like it is” which I interpret to mean try to give practical advice rather than technical gobbledygook. Let’s start with some reminders.
- Accessibility means everyone: not just about allowing users to change the text size in the browser - that’s part of the story as such measures help the visually impaired but “accessibility” encompasses all forms of disability not just visual impairment.
- Technology standards exist – use them: The World Wide Web Consortium (W3C) “.develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential.” - their words, not mine. This is basically an industry body that sets guidelines and standards that Web developers should follow. Think of it as a cross between The Law Society and Lexcel. The major difference being we are not legislated by the W3C.
- Guidelines exist – follow them: The Web Content Accessibility Guidelines (WCAG) documents explain how to make Web content accessible to people with disabilities. Web "content" generally refers to the information in a Web page or Web application, including text, images, forms, sounds etc.
The WCAG 1.0 standard is actually quite long, and if you’re not a Web Developer, then it’s pretty turgid stuff. So, what I’m going to try and do in this article is give you some really practical examples of how each checkpoint can be interpreted into a real life situation.
There are two main themes to the WCAG standard. The first is the idea of “graceful transformation”, the second is the idea of “making content understandable and navigable”.
- Graceful transformation can be summarised as ensuring that pages are readable and accessible despite any impairments on the part of the user e.g. sight, hearing etc.
- Making content understandable and navigable includes not only making the language clear and simple, but also providing understandable mechanisms for navigating within and between pages. This part is all pretty standard stuff to any Web developer
The WCAG standard defines 14 Guidelines that Web developers should be adhering two. These 14 Guidelines then contain 64 different checkpoints. Each checkpoint is given a Priority, and there are three levels of Priority as follows.
- Priority 1 - A Web content developer must satisfy this checkpoint otherwise one or more groups will find it impossible to access information in the document. Satisfying a priority 1 checkpoint is a basic requirement for some groups to be able to use Web documents.
- Priority 2 - A Web content developer should satisfy this checkpoint otherwise one or more groups will find it difficult to access information in the document. Satisfying a priority 2 checkpoint will remove significant barriers to accessing Web documents.
- Priority 3 - A Web content developer may address this checkpoint otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying a prioty 3 checkpoint will improve access to Web documents.
Our recommendation is that people should be aiming to meet all Priority 1 and 2 checkpoints if you do so you’ll comply with the requirements of the Disability Discrimination Act.
Here is a quick summary of the guidelines with some real world examples of what you need to do on your site (the full text of the guidelines can be found at: http:/www.w3.org/TR/WCAG10/#Guidelines )
GUIDELINE 1 | Priority | Provide equivalent alternatives to auditory and visual content. |
1.1 Images need ALT text | 1 | Basic stuff here. If you use an image, you must have ALT text so if someone cannot see it, but uses a screen reader, the ALT text is read out. The text must be meaningful. If the text on a page says “see the photo of the ocean on the right” then the ALT text should explain that this “is the image of the ocean” and not just say “ocean image”. One of the great technologies that we recommend clients think about using is BrowseAloud (http:/www.browsealoud.com/) which will “speak” your Web page if you have the application installed on your PC. Numerous public bodies are starting to use it on their Websites. |
1.2 Provide alternative navigation for image maps | 1 | This means that if you have an image map i.e. a map of the country that has different regions to different pages, then at the bottom you need text links such as :- North South East West that people can click on, or that screen readers can follow. |
1.3 Provide spoken commentary to accompany any use of video | 1 | If for example you have a video on your site, with no text, perhaps showing your law firm in action, you should provide a spoken commentary alongside it that non-sighted people can follow. |
1.4 Ensure that commentary is synchronised with any video | 1 | If you have a video, and do have a spoken alternative, they should be synchronised. Just like dubbing a movie for the cinema. |
GUIDELINE 2 | Priority | Don't rely on colour alone |
2.1 Assume users are colour blind | 1 | Don’t ask users, for example, to “…click on the green image on the right” unless you convey the information in another way e.g. ALT text on image, or something else. |
2.2 Ensure good contrast | 2 | Make sure you get the colour contrast right on your Website. Do not have dark grey text on a light grey background. |
GUIDELINE 3 | Priority | Use markup and style sheets and do so properly |
3.1 Avoid using images if you could use text | 2 | Use text, not images. Using an image when you can achieve the same text effect with correct CSS styling is bad practice. |
3.2 Make sure you specify the DOCTYPE | 2 | Make sure you have a DOCTYPE at the start of every page. |
3.3 Avoid using <TABLE> except for tabulated data | 2 | Do not build sites using tables to control layout, use CSS instead. See http:/www.csszengarden.com for a good explanation of the validity of this approach. |
3.4 Specify font size with “em” | 2 | Use relative rather than absolute definitions for sizes. Use the “em” to set font sizes rather than “pt”. |
3.5 Use tags to convey document structure | 2 | Make sure you record document structures using heading styles e.g. H1, H2 rather than font styles alone. It’s also good practice for Seach Engine Optimisation as words that appear in a heading are given more relevance than words appearing elsewhere on the page. |
3.6 Tag lists correctly | 2 | Build your lists correctly. |
3.7 Don’t format with blockquote | 2 | Use the Q and BLOCKCODE tags correctly. Don’t use these to indent text if it’s not a quote (use CSS instead). |
GUIDELINE 4 | Priority | Clarify natural language usage |
4.1 Declare languages | 1 | Make sure your HTML documents have a LANG tag set. |
GUIDELINE 4 | Priority | Create tables that transform gracefully |
5.1 Identify row and column headings | 1 | Use TH tags to identify table headers. In the CSS world tables should only be used for tabular data which should always have column headings, so use the tags as they should be used. |
5.2 Indicate table structure correctly | 1 | Similarly to the above, use THEAD, TFOOT, TBODY and other tags in the correct way. |
5.3 Only use tables for data | 2 | Use TABLE tags for tabular data not page layout (use CSS instead). Make sure that if the table structure was removed (i.e. the table was linearised) that the page still makes sense. An analogy for this: try pasting a table from Word into Notepad. All the table formatting gets stripped out - can you still make sense of the tabular data? |
5.4 Use structure tags correctly | 2 | Do not use any structural markup (like TH tags) simply to change formatting (use CSS instead). |
GUIDELINE 6 | Priority | Ensure that pages featuring new technologies transform gracefully |
6.1 Maintain a logical flow of content | 1 | Your HTML page should still be able to be read if style sheets are turned off in, or do not exist in, whatever tool the user is using to read your page. We call this “graceful degradation” which means your page won’t look as pretty as the designer intended, but the page is still readable. Get the “Web Accessibility Toolbar” from http:/www.nils.org.au/ais/ and use it to turn off style sheets in IE. |
6.2 Keep alternatives updated with dynamic content | 1 | If your content includes dynamic elements then make sure the accessible alternatives (text) are updated as the dynamic content changes. |
6.3 Don’t assume everyone has the latest browser/plug-ins | 1 | This is pretty obviously but often neglected: make sure pages are usable even if plug-ins are missing or scripts disabled. Functionality may be reduced…but the pages should still be useable. |
6.4 Don’t assume everyone uses the same browser | 2 | Basically, do not design a form or page that can only be completed by someone with a mouse, make sure the same thing can be done with a keyboard. Some people might use a joystick (if they have limited hand movements) or such like. |
6.5 Provide assessable alternatives to dynamic content | 2 | Another clear one. Ensure that dynamic content is accessible or provide an alternative presentation or page i.e. if you cannot build and “accessible” site (and you should be able to) you might still need to have a text-only version of the page. |
GUIDELINE 7 | Priority | Ensure user control of time-sensitive content changes |
7.1 Avoid screen flicker | 1 | Don’t do things that cause the screen to flicker, so be careful with Flash or with scrolling text. |
7.2 Avoid blinking | 2 | Do NOT get carried away with the BLINK command, in fact forget it ever existed. |
7.3 Provide for movement to be frozen | 2 | If you include movement on the page (e.g. a flash movie) then allow the movement to be paused. |
7.4 Avoid pages that auto-refresh | 2 | Don’t let pages refresh automatically unless the user is given a way to disable this activity. |
7.5 Redirect from the server | 2 | One for the techies this. Do not do a redirect in the code of your HTML page, do it via your Web server. |
GUIDELINE 8 | Priority | Ensure direct accessibility of embedded user interfaces |
8.1 Provide accessible alternatives | 1 | Means don’t write any scripts or other code that prevent assistive technologies from accessing them. |
GUIDELINE 9 | Priority | Design for device-independence |
9.1 Use client-side image maps | 1 | If you can use a client-side image map e.g. a map of the country do so (try not to use server side image maps which are much more difficult for assistive technologies to interpret). |
9.2 Don’t assume a particular browser or device | 2 | Make sure that any bit of a page can be accessed by any kind of input device e.g. mouse, keyboard etc. |
9.3 Maintain device independence | 2 | Don’t write a script, that for example, can only be executed by someone using a mouse. |
GUIDELINE 10 | Priority | Use interim solutions |
10.1 Avoid pop-ups or un-notified screen refresh | 2 | Beware pop-ups! Don’t do it, forget the fact that pop-up blockers come with IE and Google toolbar, just don’t do it. |
10.2 Label form controls correctly | 2 | Make sure all elements of a form are labelled correctly. Why wouldn’t you anyway! |
GUIDELINE 11 | Priority | Use W3C technologies and guidelines |
11.1 Use CSS and other standards | 2 | As Nike would say “just do it”. Why would our industry not use the latest W3C standards. It’s a bit like lawyers not using the latest version of the Green Book! |
11.2 Avoid deprecated features | 2 | Another one that you would expect your developer to do anyway. Who wants to use a feature that will become obsolete in the future? |
GUIDELINE 12 | Priority | Provide context and orientation information |
12.1 Title any frames correctly | 1 | Try to avoid using frames (you usually can) but if you have to then label them correctly and provide clear navigation alternatives. |
12.2 Describe frames | 2 | If you have to use frames then describe them clearly so that people who can’t see the frames can still understand how the frames/data areas relate to one another. |
12.3 Avoid very long pages | 2 | Don’t allow blocks of data to become too long – add page controls. |
12.4 Label controls correctly | 2 | Always make sure that controls (e.g. buttons) are clearly labelled. |
GUIDELINE 13 | Priority | Provide clear navigation mechanisms |
13.1 Make links meaningful | 2 | Make sure the test you hyperlink clearly describes the target information: Avoid “click here for a list of clients” – rework the text hyperlink this as “View a list of clients” |
13.2 Include page meta data | 2 | Again, something your Search Engine Specialist should be telling you to do. |
13.3 Include a site map | 2 | Make sure your site includes a site map |
13.4 Be consistent | 2 | This is one that so many people still get wrong. Don’t allow navigation to be in different places on different pages – consistency is the key. |
GUIDELINE 14 | Priority | Ensure that documents are clear and simple |
14.1 Use plain language | 2 | This is one that law firms in particular should note. Make sure the content on your pages is written in simple language – to be understood for your clients, not for you. |
The key thing to remember is that most of these checkpoints are not hard, they just require some discipline.
For another view on this subject the RNIB have re-launched the “Design and Build” area of their Website, which has some great information on techniques for building your site the right way.
David Gilroy is a sales, marketing and customer service professional with over 17 years working for companies such as Reuters and CompuServe. He has an MBA and an engineering degree. He is a Director of Conscious Solutions Limited, www.conscious.co.uk, a company which provides Websites, legal content, marketing solutions and intranets to law firms.