| Online Banking - Making It Accessible |
|
Many banks and other financial organisations are confused and concerned about the latest requirements of the Disability Discrimination Act (DDA), due to come into force on 1st October 2004. The duties of the Disability Discrimination Act (1995) originally came into effect in December 1996 and brought in measures to prevent discrimination against disabled people. Part III of the Act was introduced on October 1999 and states that where a business provides goods, facilities and services to the general public it has a legal duty to take reasonable steps to make these services available to disabled people. This Act was accompanied by a Code of Practice created by the Disability Rights Commission (DRC). The Act itself makes no mention of websites and there have been legal arguments over whether a website is a 'product' which is not covered by the Act or a 'service' which is. Similar debates have taken place round the world and there was a much trumpeted case (Maguire v The Sydney Organising Committee for the Olympic Games) in Australia where it was found that the Committee had been in breach of the Australian Disability Discrimination Act 1992 as a result of its failure to provide (among other things) an accessible website to which Mr Maguire who was blind could have access. The conclusion in Australia was that meeting the World Wide Web Consortium's (W3C) Website Accessibility Initiative (WAI) priority 1 checkpoints would be regarded as complying with their disability discrimination legislation. In the UK, the DRC announced its first formal investigation into website accessibility in March 2003 (report yet to be published) and clearly regards websites as within its remit. Neither the DRC nor its Codes of Practice are technically 'statements of law' and interpretation of the Act remains the prerogative of the courts. However, in practice, having followed their advice is usually regarded as evidence that people have acted reasonably.
The DDA defines a disabled person as someone with a physical or mental impairment that has a substantial and long-term adverse effect on his or her ability to carry out normal day-to-day activities. Not all disabilities, as defined under the Act, affect the way people access the Internet. In order to ensure that your website is accessible to your customers, or potential customers, it is important that you understand their abilities (or disabilities) and their assistive technology. This way you will be in a better position to accurately identify their requirements and ensure your website design can support them. For example:
Where a person has been deaf from birth, sign language is likely to be the first language. Sign language is very different from the English language, having its own syntax, lexicon and grammar. As a result, users of sign language may experience difficulties in understanding some text. Therefore these users will require a website that is written in Plain English.
By understanding your users, their capabilities and needs and following a User Centred Design approach you will be able to develop websites which are both usable and accessible. Many of the features which create barriers for people with disabilities can also create barriers or unnecessary difficulties for a wider user group, for example allowing customers to navigate your website using a keyboard only.
These include, but are not limited to:
2. Develop in-house accessibility guidelinesAlthough the guidelines listed above are a good starting point, they are often difficult to interpret, and some are technical in nature. Developing in-house guidelines is an excellent way to show that your organisation is committed to accessibility, both morally and legally. These guidelines can also ensure a consistent approach. To develop your in-house guidelines we recommend that you put together a team consisting of:
Develop checklists to ensure that your website complies with your accessibility guidelines at the design phase (e.g. interface design), coding phase and testing phase. The designers, developers and testers can use the appropriate checklist to conduct assessments as part of their day to day tasks. Alternatively, you can recruit interested individuals in-house to become accessibility champions.
This article first appeared in Financial World. February 2004 |
