Is Your Website Accessible?
by David Gilroy
The Disability Discrimination Act 1995
covers the accessibility of websites. The
final parts of this Act are coming into force in October 2004 and although the
sections relating to websites are already in force, there has been a renewed
interest in the Act recently. The relevant section, s.21(4) SI 1999/1191 Reg 4,
says:
"For people with visual/hearing impairments, the range of auxiliary aids or services which it might be reasonable to provide to ensure that services are accessible might include [here it lists a range of services one of which is] accessible websites."
Since the Act does not define the term or make any specific recommendations, we have to turn to the relevant trade bodies in the Internet area for a detailed treatment of the topic, in particular the Wordwide Web Consortium (W3C), www.w3.org.
The W3C says that when developing a website, you should consider that some users may:
- not be able to see or hear or move, or may not be able to process some types of information easily or at all.
- have difficulty reading or comprehending text.
- not have or be able to use a keyboard or mouse.
- have a text-only screen, a small screen, or a slow Internet connection.
- not speak or understand fluently the language in which the document is written.
- be in a situation where their eyes, ears, or hands are busy or interfered with (e.g. driving to work or working in a loud environment).
- have an early version of a browser, a different browser entirely, a voice browser, or a different operating system.
In 1999 the W3C defined the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) These are still the current standards (there is a "working draft" of a new version but no date when this draft is expected to be agreed and published).
The W3C defined a series of checkpoints that web developers should adhere to when building a website. There are three levels of checkpoints:
- 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 this checkpoint is a basic requirement for some groups to be able to use Web documents and every web designer should be meeting this basic level.
- 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 this 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 this checkpoint will improve access to Web documents.
Each of the three levels places an increasing burden on the web developer to do things the "right way". The ability to meet these three levels is termed "conformance":
- Conformance Level "A": all Priority 1 checkpoints are satisfied;
- Conformance Level "AA": all Priority 1 and 2 checkpoints are satisfied;
- Conformance Level "AAA": all Priority 1, 2, and 3 checkpoints are satisfied.
There is as yet no tool that can perform a completely automatic assessment on the checkpoints in the guidelines, so fully automatic testing may remain difficult or impossible. For instance, some checkpoints rely on an interpretation of what "important" information is, or whether the text equivalent for a non-text element is accurate. The Royal National Institute for the Blind (RNIB) offer consultancy services to help determine if a site is compliant and if not what to do about it.
Full details as to what is included in each level can be found on the W3C website. As an example, let us suppose that you have a list of services that you provide as a law firm, and the list is in green text on the right hand side of the page. On the left hand side of the page you say "Please select an item from those listed on the right in green." Someone who is colour blind, or a user who is not using a graphical browser may not understand those instructions and the site would not therefore be fully "accessible".
These are only "recommendations" but let us say that you are a law firm who specialises in discrimination law. Can you imagine not having an accessible website?
Case Law
There is no UK case law on this matter yet but in Australia in June 1999 a case was brought by Bruce Maguire against the Sydney Organising Committee for the Olympic Games (SOCOG). He claimed that he was discriminated against as their website was inaccessible to him. It took until August 2000 for the Australian Human Rights & Equal Opportunity Commission (HREOC) to announce their decision. They found in favour of the complainant and ordered SOCOG to make changes to the site before the start of the games on 15 September 2000. SOCOG failed to meet this deadline and were then fined AU$20,000. There is an excellent summary of the full decision relating to Sydney Olympics Accessibility Complaint here.In April 2004 the Disability Rights Commission (DRC) in the UK, published the findings of a survey of 1,000 randomly selected websites. The sites chosen were those from government, large and small business and education. Using a commercially available software tool, City University tested the home pages of these sites for technical compliance with the Guideline Checkpoints. Additionally, 100 of these sites were then tested in detail by disabled users carrying out specific tasks for each type of site.
The report is pretty damming in its findings with respect to the accessibility of these websites and it found that 81%of sites were not even compliant with the Priority 1 checkpoint, .2% achieved compliance with Priority 2 checkpoints and none at all achieved compliance with Priority 3 checkpoints.
"Accessibility" versus "Design"
The most recent versions of the main software tools used by professional web developers are, in the main, able to produce accessible code. These include Macromedia Deamweaver, Macromedia Flash, Microsoft Frontpage 2003 and Adobe GoLive. (See later for these links). However, this is a question of deliberate choice on behalf of the developer and many of the websites produced with these programs are not accessible. This is a matter which should be discussed in detail with the developers before final decisions are taken.
An example of the most basic test is checkpoint 3.4 which is a Priority 2
checkpoint. This says "Use relative rather than absolute units in markup
language attribute values and style sheet property values." This means that in
the language that is used to create a web page the font size is set to "Small"
rather than to "10pt". This then allows the user of your website to change the
text size using the browser.
In my experience more than 75% of all sites currently on the web will fail this most basic of tests. The reason for this high number is that many web designers have historically built websites from a "design" perspective, not from an "accessibility" perspective. So, a designer will not want a viewer to change the size of the text as it will "spoil" the design. It is a cultural shift to get them to realise that accessibility is not independent of design and that the most important challenge is to ensure that all users who want to use your site, should be able to do so. For someone with a visual impairment, being able to change the size of the text might be the difference between them staying on your site and checking out your firm, or going on to the next site that Google showed them in their search results!
Checking Conformance
There are a number of aspects to testing the conformance of your site. The first is to check that the HTML code (the language that is used to build websites) has been developed to one of the agreed standards. (See W3C Markup Recommendations). The most commonly adopted standard is what is called XHTML. The W3C provides an online Validation tool that can be used by anyone to ensure that their website confirms to this.
Then comes the accessibility issue. There are a number of commercially
available tools to help evaluate how your site conforms against the three sets of
priority checkpoints discussed earlier. The best known of these is known as
"Bobby" which can be found at
bobby.watchfire.com/bobby.
These tools compare each line of the underlying HTML code against each of the checkpoints. A report is then produced that tells you which areas of your website do not conform to the checkpoints.
A number of these tools provide an online service where you can type in your website address and it will check the conformance of your home page.
Usability Bonus
An important finding from the April 2004 DRC report was something they called a "Usability Bonus". What they found was that on a site that was deemed to be a "low accessibility" site a particular task took 46% longer than on a similar site that was deemed to be "high accessibility". What this means is as follows. If you design your site to be "accessible" from the beginning, then ALL users benefit by being able to achieve faster task times i.e. do things quicker on your website.Summary
The current legislation is not specific about what you must do to ensure compliance to the Disability Discrimination Act but the main trade organisation, the W3C has developed a series of checkpoints to help web developers ensure that they are building the most accessible websites they can.If you have a website, I suggest you do not panic. Talk to the people who built it for you. Get it checked using one of the tools, then put a plan in place to make whatever changes are necessary.
For example, if you cannot change the text size using the browser, fix that now. If your tables are not coded correctly, change that when you redevelop your website next year. The law will look for reasonableness when, and it will happen, someone goes to court.
If you have just spent £10,000 on redeveloping your site and you have missed one checkpoint that is a marginal improvement, I would suggest that your defence could be quite strong. However, even if you've only just spent £1,000 on a new website, not being able to change the text size is indefensible.
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 Managing Director of Conscious Solutions Limited, www.conscious.co.uk, a company which develops web solutions for law firms. They provide content as well as tools and techniques to ensure that a law firm's web strategy helps develop profitable client relationships.
email dgilroy@conscious.co.uk.
Useful Links
Information on Accessibility Policies of Major Development Tools Other Useful Links
Back to Contents.