Until my company’s successful tender to design a government Web site, I knew very little about the Disability Discrimination Act (DDA) of 1995 and its’ potential impact on the Web . If pressed, I could probably have told you that the DDA stated Web sites had to be made ‘accessible’ to disabled persons by some time soon and that this could be achieved by adding those little yellow text boxes (properly known as ‘Alt tags’) alongside any images on your site. Looking back, I cringe at my ignorance and can only console myself with the fact that, one year on, very few people in the industry still seem to know much about the issues involved – technical or legal. With the evangelism of a convert, I’ve spent the best part of 2002 trying to change this and decided to start in the area I knew best – the legal marketplace.
Having mastered the technical aspects of ensuring Web accessibility, I planned to e-mail a free ‘health-check’ offer to all existing law firm Web sites, testing their state of compliance with the agreed standards – the Web Content Accessibility Guidelines (or WCAG 1.0). Of course, the offer wasn’t entirely altruistic! Whilst the initial audit would be free and without obligation, I hoped that firms whose sites didn’t meet the grade would want to employ our services to ensure conformance. Being the only agency to take such an initiative, combined with our government work, I thought the project would have integrity and be profitable. Also, what better place to start? Law firms would be familiar with the coming legislative requirements and want to avoid running foul of them.
The actual testing was to be performed by a variety of commercially available programs which can ‘remotely’ sweep files within an entire domain – reporting on ‘certain’ and ‘possible’ errors. It might be helpful at this point to explore some of the technical issues involved in ensuring a site’s accessibility.
The Conformance Checkpoints
The WCAG 1.0 guidelines provide three levels of conformance that Web sites can achieve; ‘A’, ‘AA’ and ‘AAA’. Of these, ‘A’ is the most basic level of compliance – without which one or more groups will be unable to access information on the site. This is the level which all government Web sites have committed themselves to achieve as quickly as possible. To make the process as scientific as possible, the guidelines detail an exhaustive series of ‘checkpoints’, graded into ‘priorities’ of 1 to 3. For a site to be certified as level ‘A’ compliant, all priority one checkpoints must be met. The majority of these checkpoints are aimed at ensuring that site content can be comprehended by the various technologies which have been developed to assist disabled persons to ‘read’ information via the Internet; speaking browsers, screen readers, voice browsers and other adaptive systems.
The following description of these essential checkpoints might be useful if you are looking to self-certify your own site:
- General checkpoints
o Provide a text equivalent for every non-text element, by using “alt” or “longdesc” tags in the HTML code. This includes: images, graphical representations of text (including symbols), image map regions, animations (eg, animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
o Organise documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
o Ensure that all information conveyed with colour is also available without colour.
o Clearly identify changes in the natural language of a document’s text and any text equivalents (eg, via captions).
o Ensure that equivalents for dynamic content are updated when the dynamic content changes.
o Avoid causing the screen to flicker.
o Use the clearest and simplest language appropriate for a site’s content.
- Checkpoints relating to the use of tables:
The following points apply only to ‘data tables’, ie tables which contain genuine data such as timetables or listings which must be read in a linear fashion (eg strictly down columns or across rows). They do not apply to tables which are used purely to layout the page.
o Use HTML to identify the tables’ row and column headers.
o If a data table has two or more logical levels of row or column headers, use HTML to associate data cells and header cells.
- Checkpoints relating to the use of frames:
o Ensure each frame is titled – to facilitate frame identification and navigation.
- Checkpoints relating to the use of applets and scripts:
o Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
- Checkpoints relating to the use of images and image maps:
o Provide redundant text links for each active region of a server-side image map.
o Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
- Checkpoints relating to the use of multimedia:
o Provide an auditory description of the important information of the visual track of a multimedia presentation.
o For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.
- and finally.
o If it is not possible to observe all of these points, provide a link to an alternative page that is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible page.
These checkpoints only ensure the basic level ‘A’ compliance rating. Priorities two and three checkpoints are far more stringent, allowing even greater accessibility to site content and addressing more complex Web features.
The Legal Position
So much then for the technicalities – what of the current legal position? Prior to launching the offer, I had assumed that obligations under the DDA need not be met until October 2004 and drafted my e-mail accordingly. It was only half way through the e-mail shot that a specialist Internet lawyer contacted me to put the alternative view; ‘Under the DDA, those providing services over the Web to the UK public, paid or unpaid, may be obliged now to make reasonable adjustments for the disabled. Free legal information on a law firm’s site could be interpreted as a service and so fall into this category’. (
Offering the Survey
The e-mail -out process was arduous. For my ‘client database’, I had used the ‘Solicitors Online’ listings on the Law Society Web site – looking for firms with an existing Web site (that was to be the first shock for me, as it ran to fewer than one in five). I accessed firms’ sites and looked for the most appropriate recipient for my e-mail. Wherever possible, this would be individuals listing Computer/Internet law as their specialism or, failing this, Senior Partners.
I estimate that I contacted approximately 700 or so firms in this way. Accepting that a certain percentage of mails would go ‘astray’ – either to individuals who had left practices or changed their e-mail addresses – the vast majority simply ignored the e-mail altogether. Six or seven respondents upbraided me for breaching data protection principles in sending unsolicited e-mail. Another handful of firms wanted to debate the timetabling of the DDA’s legislative requirements. These I referred on to
These sites differed enormously in size, design and function – ranging from a single page, High Street firms’ ‘site’ to a busy, asp-based legal portal. The common characteristic was their non-compliance with even Level ‘A’ of the WCAG 1.0.
Degrees of Non-Compliance
Inevitably, the degree of non-compliance varied massively. One site (belonging to a very large and well known firm) came agonisingly close – missing only descriptive tags on certain images. However, this was the exception; the majority were some way from basic conformance and fell down in several areas. By far the most common problem was navigation ‘buttons’ which were graphical in nature and had no, or misleading, ‘alt’ tag text. In these cases, visually impaired users (or fully sighted users who had simply disabled graphics within their browser settings) would be completely unable to navigate the site. Another standard error was in styling site pages with ‘fixed’ or ‘absolute’ font sizes. This is an instruction, held within the sites’ style sheet, to maintain the precise size of text used by the designer – thereby always ensuring a consistency of display. Unfortunately, this also prevents short-sighted users from increasing on-screen text size (one of a number of ‘accessibility’ features within recent versions of the mainstream browsers) or tunnel-visioned users from decreasing the display. The situation is simply remedied by amending the style sheets’ pitch settings to use ‘relative’ units, such as ’ems’ or percentages. This need only be done once, on the single style sheet (.CSS) file, to reformat the entire site.
Disappointingly, no firms commissioned these problems to be addressed. Of the 70 or so audit reports requested, approximately half gave no response at all to our findings. Given the free service they had received, I found this rather rude but had made a policy at the outset of not sending ‘chaser’ e-mail s to firms who showed no interest in the work (too ‘salesy’ and counter-productive). Others did acknowledge our contribution but gave no indication as to their future intentions. One or two firms said that they would be feeding our report over to their original developers to address. Some quibbled over when changes had to be implemented (over to Adam again!). Eventually, one firm asked for an estimate to have their site corrected. This turned about to be a relatively small site (16 pages in total), containing common errors which would take roughly one day’s ‘donkey work’ to fix. Cost: £400.
Three months later, I await their reply.
