>From the web page http://www.frontend.com/accessibility_paper.html Accessibility & Usability for e-Government The Frontend.com Accessibility White Paper: A Primer for Public Sector Officials. CONTENTS * Introduction * The Importance of Awareness and Action * Disability and Accessibility * Testing for Accessibility * Frontend e-Government Accessibility Analysis * Good Usability is Good Accessibility * Summary: What You Need to Do * References Introduction Government, like business, is going on-line. Ireland is moving rapidly towards an 'information society' in which e-Government at national, regional and local levels will play a central role. The Government's action plan on Implementing the Information Society in Ireland [1] predicts that: "In the Internet age, Government websites will become the gateways for people to conduct their business with Government and a central feature of public service delivery." Government web sites will need to be easy for all citizens to use, including those with a disability, so universal accessibility is a crucial issue in their design. This paper is intended as a primer for public sector officials who are responsible for or otherwise involved in the creation of web sites. It will tell you: * Why you should be concerned about accessibility * What targets and legislation apply to you * What accessibility is and which disabilities it concerns * Some common accessibility problems and their causes * What you need to do to develop an accessible web site As part of this discussion, we present the findings of an accessibility analysis of three current Irish Government web sites: * Revenue On-Line Services: http://www.revenue.ie/ * Donegal County Council: www.donegal.ie/dcc * Department of the Taoiseach: www.irlgov.ie/taoiseach We describe some of the problems that disabled people will have with these sites and how they can be avoided. The Importance of Accessibility Awareness & Action There is a growing awareness and concern with accessibility at all levels of society. This has previously related to the accessibility of buildings and traditional media. However, this is now being extended to include the accessibility of online information and services made available through web sites. In 1999 the Web Publication Group, an Inter-Departmental Group chaired by the Department of the Taoiseach, was set up to prepare guidelines and standards for public sector web sites. In its first report, the group stated as its guiding principle: "Websites should be designed and operated in accordance with the needs of users." [2] Users of public sector web sites are a diverse group, inevitably including many people with disabilities or impairments. Although it is difficult to find statistics concerning the number of disabled people in Ireland, it is likely that the situation is similar to the U.S. where 8% of the population has visual, learning, cognitive, auditory or physical dexterity disabilities severe enough to affect their ability to access the web. [3] This would equate to about 280,000 disabled users in Ireland. The Irish Government have recognised this by imposing targets specifically relating to the accessibility of online public services. These targets are of importance to all public sector bodies, since they will each be responsible for the design of their own web sites and will therefore be accountable for accessibility. European Union & Irish Government Targets Specific accessibility targets have been set at European and Irish Government levels. The European Union's eEurope initiative, launched in December 1999, states: "Public sector web sites and their content in Member States and in the European Institutions must be designed to be accessible to ensure that citizens with disabilities can access information and take full advantage of the potential for e-Government." [4] The specific actions related to accessibility include, by the end of 2001: "Adoption of the Web Accessibility Initiative (WAI) guidelines for public sector web sites." [4] and by the end of 2002: "Review relevant legislation and standards to ensure conformity with accessibility principles." [4] The Irish government intends to comply with the eEurope targets by making all public sector web sites accessible by the end of 2001. The National Disability Authority will be invited to monitor standards in this area. [5] Targets will not just apply to national government, however. In the sphere of local government, the Institute for Design and Disability (IDD) is carrying out a major campaign entitled "Citizen 2000" to obtain the agreement of all Local Authorities in Ireland North and South to adopt the Barcelona Declaration, which states: "The Municipal Governments will ensure the access of disabled persons to information generated by the Community." [6] To date, Drogheda, Dublin, Limerick, Wexford and Sligo have adopted the Declaration and are in the process of completing the formalities of registration. It is envisaged that this project will take two years to complete. Legal Action Against Web Sites Although there is as yet no direct legislation in Ireland concerning the accessibility of web sites, planned legislation dealing with discrimination against people with disabilities may be used as a basis for legal actions against web site providers. This has already happened in Australia and the U.S. In a landmark ruling by the Australian Human Rights and Equal Opportunity Commission, the organisers of the Sydney Olympics were found to have breached section 24 of the Australian Disability Discrimination Act (1992) by failing to make their web site (www.olympics.com) accessible to people with visual impairments. They were ordered to take immediate action to make the Olympics and Paralympics sites accessible. Although the commission is not a court, legally enforceable damages of AUS$20,000 have been awarded against the organisers. [7] In the US, the Americans with Disabilities Act (1992) requires organizations to provide the necessary aids and services to allow effective communication to people with disabilities. In the past this has meant that shops, restaurants and other businesses have had to provide wheelchair ramps and Braille signs. In November 1999 the National Federation of the Blind (NFB) lodged a lawsuit against America Online (AOL) claiming that AOL violated the Act by failing to provide accessible online services and software. In an out of court agreement, NFB have agreed to suspend the lawsuit for 12 months, by which time AOL must make the next version of its software accessible to the blind, ensure that future AOL products are also accessible and adopt a company wide accessibility policy. [8] These actions have shown that existing legislation may be extended to the online domain, raising the possibility of similar actions in Ireland using the Disabilities Bill which is expected to be published late 2001. This bill is designed to set out the rights of persons with a disability, together with the means of redress for those whose rights are denied. The Taoiseach says: "The preparation of a Disabilities Bill will proceed as quickly as possible. I would envisage that the Bill will cover areas such as access to public bodies, the use of telecommunications services, . and participation in the judicial system. The providers of basic State services will, from today on, have the concerns of people with disabilities as part of their core work." [9] Whether the Bill will specifically cover online services is not yet known. However, in the UK Section 21 of the Disability Discrimination Act (1995) does apply to web service providers and requires them to make 'reasonable adjustments' to their services so that disabled people can access them. [10] Eventually, European governments are likely to follow the U.S. where Section 508 of the Rehabilitation Act (1998) requires all Federal agencies to have accessible web sites and intranets by Spring 2001. Disability and Accessibility: An Overview "The key principle underlining accessibility is that web sites should be easy for everyone to use, including people with a disability." [2] Not all people with disabilities have problems using computers to access the web, but some disabilities can present severe obstacles. Those most associated with access difficulties are: * Visual impairment: Low vision, restricted vision or colour blindness * Motor skills: Inability to use a keyboard or mouse, inability to make fine movements * Hearing impairment * Cognitive abilities: Reading difficulties, dyslexia or memory loss * Low grade technology: Slow connections or old versions of software People with these impairments may have difficulty perceiving or processing some types of information. They may be unable to use common input devices such as a keyboard or mouse. They may have to rely on special assistive technologies to enable them to provide inputs and perceive outputs. For example, blind users may use a screen reader which is a program that reads the contents of the screen aloud in a synthetic voice. Users who have low acuity vision may use a screen magnifier program which enlarges a selected portion of the screen. People with motor impairments may require a special keyboard or a pointing device controlled by a joystick or by head movements. Typical Accessibility Problems Although having a disability and having to use assistive technology inevitably restricts what can be done and at what speed, it should nevertheless be possible for a disabled person to access the functionality of a web site. In some cases designers may have to arrange content or provide alternative access methods to take advantage of the disabled user's abilities and the technologies they use. Accessibility problems occur if designers fail to do this when it is possible. This paper is not intended to provide an exhaustive coverage of accessibility problems but to give you an idea of the types of problems disabled people face. In this section we concentrate on visual impairment which presents the biggest single barrier to effective use of the web. We asked a number of visually impaired computer users to describe the typical problems they encounter on web sites. Here are some of their answers in their own words with our explanations of why the problems occur: - Problem: "Unlabelled Links" When an image acts as a link and no text description is provided, a blind user's screen reader cannot describe the link in a meaningful way. This means the user cannot discern the purpose of the link, or where it will take them. To solve this problem, the HTML, the language which is used to create web pages, includes a construct called the "Alt" tag, which can be used to provide a text alternative for any non-text item. A similar problem arises wherever an image or any other non-text element is used without an associated alt text description. A screen reader will be able to read only the image file name which may typically be something like "photo.gif". This is meaningless to a blind user who then has no way of knowing how the image supports or illustrates the text. The user may therefore feel that they are missing out on important content, or not know whether they are missing out, eroding their trust in the site. - Problem: "Sorting out the text that relates to a link on a full page" A screen reader can read out a list of all the links on a page. This allows the user to quickly scan for useful links without having to read the entire page contents. If a link is meaningless when read out of context, it makes the task of navigating a web site very difficult. For example, a web page may include the sentence "Click here for a text-only version of the site" where only the words "Click here" are the hyperlink. The link will be read by a screen reader as "click here" and the user will have to locate the sentence in order to understand the meaning of the link. The solution is to provide link titles which make sense from a user's point of view without requiring context to interpret. - Problem: "Frames which are difficult to activate" Frames can cause problems with some screen readers. It may be difficult or impossible to reach some of the frames on a page. If frames are used, a non-frames version of the site should also be provided. - Problem: "Some web sites have text lines wider than the screen and my screen reader cannot cope with that" When the contents of a web page are wider than the browser window, sighted users can scroll horizontally to read the information, although this represents poor usability. If part of line of text is not visible in the browser window, some screen readers will not read it aloud. A similar problem occurs if the text area is specified using "absolute" rather than "relative" sizing. If you are a sighted user and you resize your browser window on some web sites, the contents of the page seem to expand to fill the window. This means that relative sizing has been used to specify the widths of text columns as a percentage of the browser window size, rather than defining them as a fixed or "absolute" width. In other words, the column widths have been specified "relative" to the browser window width. Font sizes can also be specified using relative sizing. People who are uncomfortable with small fonts can then increase the size, using standard browser controls. - Problem: "The suspicion that there is a lot of information on the screen but for some reason the screen reader will not read it" This is a general problem with web sites that do not indicate up front what a screen contains. A sighted person can quickly see what a screen contains by scanning it but a non-sighted person has to rely on being able to read each item one by one. From experience, they may suspect that the page contains a lot more than they have been able to find. The solution to this problem is to create simple designs where each page has a particular coherent purpose which can be explained in a title and a short introductory text. What Sites and Services do Disabled People Use? Disabled people use the same sites as non-disabled people. Research by the Disability Statistics Center at the University of California reveals that the most common reasons that people with disabilities cite for using the Internet are email and searching for information. These are also the two most common reasons for people without disabilities. Large numbers of disabled users also report accessing news, weather, sports scores, online education, jobs, shopping and paying bills. [11] We asked a number of visually impaired people in Ireland what activities they visit web sites for. Their answers included the following: * Downloading software * Research * Email * News & sports * Chat or discussion groups * Banking This is similar to the answers you would get from any group of web users. Testing for Accessibility There are a number of methods that web site designers can use to ensure their web sites are accessible. Firstly, comprehensive guidelines are available which, if followed, will ensure accessibility. However, following the guidelines and detecting violations is not always easy because some points require subjective judgement. It is made easier by automatic testing tools which check web pages against the accessibility guidelines and report violations. Although these tools are very useful, they are limited in the violations they can detect. Also, interpreting their output and solving the problems requires knowledge of HTML and accessibility issues. Therefore, expert input is essential. An accessibility expert is someone who is familiar with accessibility guidelines, the nature of disabilities, assistive technologies used by disabled people, and the technologies used to create web sites. Lastly, as with usability in general, testing involving real users using assistive technologies is indispensable. Accessibility Guidelines The Inter-Departmental Web Publication Group chaired by the Department of the Taoiseach was set up in 1999 to prepare guidelines and standards for public sector web sites. The Group was set up to fulfil the commitment given in paragraph 42 of the Government Action Plan: [1] "42. Service-wide guidelines and practices will be adopted regarding content format and presentation etc. for web sites, and an Interdepartmental Group will be established to deal with these issues." Their first report, "aimed at webmasters and those involved in or with influence over designing and setting up public sector web sites" [2], provides some basic guidelines on usability and accessibility. Public sector officials should therefore be familiar with these guidelines. However, to ensure accessibility, designers should follow the detailed "Web Content Accessibility Guidelines" issued by the Web Accessibility Initiative (WAI) [12]. The WAI is a working group sponsored by the World Wide Web Consortium (W3C), an independent, international body that creates Internet and programming language standards. All its recommendations are highly regarded and the WAI guidelines are currently accepted as best practice in the industry. They provide in-depth technical direction on HTML issues relating to accessibility but require a working knowledge of HTML to interpret them. The guidelines are divided into Priority 1, 2 and 3 checkpoints, with Priority 1 being the most important. It is generally considered that for a web site to be accessible it must pass at least the Priority 1 checkpoints. An example is checkpoint 1.1 which states: "Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content)". Although the WAI guidelines are comprehensive and mostly very detailed, many checkpoints require subjective interpretation. An example is Checkpoint 14.1 which is also Priority 1 and states: "Use the clearest and simplest language appropriate for a site's content". Automatic Testing Tools and the Bobby Test To assist developers in assessing web sites for accessibility, a number of automatic testing tools have been developed. The best known and most comprehensive of these is called Bobby [13]. Similar tools include The Wave [14] and Lift [15]. Bobby is a piece of software that analyses web pages for accessibility. It is a free service provided by CAST (Centre for Applied Special Technology), a non-profit organization which aims to expand opportunities for people with disabilities through computer technology. Bobby's analysis of accessibility is based on adherence to the WAI guidelines. To become "Bobby approved", a web site must pass all of the automatically testable Priority 1 WAI checkpoints. Bobby deals with WAI checkpoints in one of three ways: * Those that relate to a specific type of screen element and for which violations can be detected automatically. Bobby can highlight these. * Those that relate to a specific type of screen element but for which violations cannot be detected automatically. These require manual checking and Bobby can tell you where to check. * Those that do not relate to a specific type of screen element. Bobby will only list these for reference because it cannot test for them. WAI checkpoints for which violations can be detected automatically include Checkpoint 1.1 (Priority 1) "Provide text equivalent for every non-text element". All images and other non-text elements can be detected and automatically checked to see if they include alt text tags. If Bobby detects a violation it will flag it and provide some guidelines on how to repair the HTML code. However, Bobby cannot tell you whether the alt text is relevant or useful. WAI checkpoints for which violations cannot be detected automatically include 14.3 (Priority 3) "Use header elements to convey document structure and use them according to specification". It is not possible for Bobby to know whether a header element has been used to convey structure or whether it has been misused to create a formatting effect. If Bobby detects any header elements on a page it highlights the possibility that the checkpoint has been violated and prompts you to make a manual check at that point. However, it is not possible for Bobby to detect pieces of text which are structurally used as titles or headings but which have not been constructed as header elements. Checkpoints which do not relate to a specific type of screen element include 3.5 (Priority 2) "Create a style of presentation that is consistent across pages". Bobby cannot detect inconsistency or tell you anything at all about presentation style. Because even some Priority 1 checkpoints are not amenable to automatic compliance testing, it is not possible for Bobby or any other automatic testing tool to ensure that a web site is accessible according to the WAI definition. Because of its limitations, the Bobby test does not guarantee that a site is entirely accessible. If Bobby is the only test which is deployed during development, it will still be possible to produce a site which is inaccessible. Expert Evaluation Expert evaluation will identify problems that require informed human judgement and that cannot therefore be detected by an automated testing tool. An expert may use an automatic tool such as Bobby as a starting point but will then carry out all the suggested manual checks and assess the site against all the remaining guidelines. However, checking the HTML is only the start. An expert can assess a web site by taking a disabled user's perspective and trying to carry out real tasks using assistive technologies. For example, the expert may access the site using a text-only browser such as Lynx [16]. Whilst a text-only browser does not faithfully recreate the experience that a user with a disability will have, it provides some insight for several reasons: * All graphic clues to a site's structure are removed. A text-only browser is quite different to a text-only web site. For example, there is no such thing as bold or italic text. Links that appear as images without alt text are difficult to place in context. * You can only view a small portion of a web page at a time and must therefore rely on memory to retain and compare information. Blind people rely heavily on memory. Also, people with cognitive disabilities may struggle with this problem. * Navigating web sites built with frames is difficult. Poorly designed frames cause navigation problems for blind people. In addition, the expert may use keyboard-only navigation instead of using a mouse which demands hand to eye co-ordination that blind people or those with limited motor control do not have. They may even use an audio browser or screen reader. Expert evaluation by a usability professional is closer to a real user's point of view than an automated test because the expert looks at the interface a user encounters rather than the HTML that creates it. It can identify many problems which automatic testing tools cannot. For example, Bobby can tell you if an image has alt text but it cannot tell you if the text is meaningful. This is not to say that poor HTML does not cause accessibility problems, but a web site can be accessible in so far as it passes the Bobby test but may still be difficult for someone with a disability to understand and use. An added benefit of expert evaluation is that it can be carried out on a system design before the HTML is created. This means that problems can be identified and resolved much earlier in the development process, where the cost and time required to fix them is lowest. However, although the expert evaluation gets closer to the user experience, it does not replace testing a system with real users. Usability testing with real users will always provide the best information. User testing A usable web site must let the people who use it accomplish their goals and tasks effectively and efficiently while working in their own physical, social, and cultural environments. Involving users in the design and testing process is the best way to ensure that accessibility problems are recognised and overcome. A structured user test involves real users using the web site to perform real tasks. It gathers insights into problems through a combination of observation and user feedback. It identifies real problems with information design, structure and content, visual design and interactive features. User testing can be carried out either on an existing web site or on prototypes during the development process. Findings can be fed back into the process to provide a clear direction for designers and developers. If user input takes place early and often, the problem of investing significant time and money in solutions that fail to meet basic needs can be avoided. Frontend e-Government Accessibility Analysis We carried out an accessibility analysis of three prominent Irish Government web sites. This involved running the Bobby test and carrying out a task-based expert evaluation using a text-only browser and an audio browser. The sites we analysed were: * Revenue On-Line Services: http://www.revenue.ie/ * Donegal County Council: www.donegal.ie/dcc * Department of the Taoiseach: www.irlgov.ie/taoiseach The Revenue On-Line Services and the Department of the Taoiseach are featured in the e-Government resources section of the REACH agency which is charged with setting up an online 'one stop shop' for government services [17]. Donegal County Council's web site was chosen because the Taoiseach recently referred to the Council as being: ".amongst the foremost local authorities in utilising information systems in delivering services to their customers." [18] Our aims in carrying out this analysis were: * To provide real examples of accessibility problems which might be encountered by people with disabilities who might want to use online Irish government services. * To learn from the mistakes which were made on these sites. * To broadly compare the results and the insights provided by the Bobby test and an expert evaluation carried out by a team of usability professionals. This analysis is not a criticism of the efforts made by people in Government agencies who are responsible for the sites we reviewed. Frontend acknowledges that the Government has stated a commitment to accessibility and is presently taking the lead on tackling this important usability issue. The private sector can learn many valuable lessons from the achievements as well as the failings of the online Government services. Also, it should be noted that the sites discussed in our analysis may have changed since the time we reviewed them. However, even if this is so, we still find it useful to discuss these features, since our aim is to provide examples of good and bad practice. The analysis was done on the basis of a set of typical information finding tasks which users of these sites may want to perform. We restricted our analysis to those pages that a user would have to visit in order to perform the tasks in the most straightforward way. This analysis does not, therefore, constitute an exhaustive evaluation by any means. Furthermore, we are only presenting a few of our findings here as examples of the kind of accessibility problems that disabled users actually face. Summary of findings Here is a broad overview of what we learnt from our accessibility analysis of these three sites. According to Bobby, Donegal County Council and The Department of the Taoiseach web sites are inaccessible. The text-only version of the Revenue Commissioners passed the Bobby test, although the graphic homepage, which is the main point of entry for the text-only pages, failed. The most common problems we identified were: * Images missing alt text * Poor alt text * Poor use of frames * Poor navigation - links out of context, difficulty for users to get an overview of the site's contents The expert evaluation identified problems with all three sites, including those pages which passed the Bobby test. Analysis of Donegal County Council Web Site We set out to complete the following task: You live in Falcarragh and you want to join the library. There is no local library but you have heard that the mobile library comes to Falcarragh. Find out when and how often it calls. Bobby failed this web site for failing to meet WAI Priority 1 accessibility criteria and also pointed to a failure to "Identify the language of the text". Some speech synthesizers and Braille devices can cope with different languages but they must be told what language to work with. If "natural language" changes are not identified, they may be indecipherable when machine-spoken or brailled. Occasional words are not a major problem but larger items such as paragraphs can cause difficulties in this context. Bobby also suggested a manual check: "Do not use pop-up windows or change the active window unless the user is aware this is happening". This message is triggered by a "mailto" link for the site's webmaster. Clicking this link would pop up an email window on top of the browser window. Creating or switching windows without warning can easily confuse blind users if their screen reader suddenly shifts focus from the web site to the new window. In this case, the email window is not a serious problem, as it is likely that most users have their systems configured to cope with the mailto feature. The expert evaluation found further problems. For example, the home page does not provide an overview of the contents or structure of the site. It uses frames for layout and the frame titles, "navbar", "masthead" and "contentarea", do not adequately describe the purpose of each frame or the information they contain. If frames are used, their titles should help a blind user to gain an overview of the structure of the site. Note: These are only a few of the problems found with this site. We present these examples to illustrate the kind of accessibility problems that disabled users face and that can be found using the Bobby test and further expert analysis. Analysis of Department of the Taoiseach Web Site We tried to complete two tasks on this web site: Task 1: Read the latest report on Partnership 2000. Task 1: Find out the name and email address of the Minister for Justice Equality and Law Reform. Bobby failed this web site for failing to meet WAI Priority 1 accessibility criteria and also pointed to a priority three problem "Separate adjacent links with more than white space". The "Publications" page is a long list of text links. Blind users sometimes have difficulty differentiating text content from text links. Whereas a sighted person can identify links from visual clues, such as colour or underlines, a blind user may use their screen reader to call up a list of the links on page. If adjacent links are not separated by text or an image, even if they occur on consecutive lines, some screen readers will incorrectly read them as a single link. The expert evaluation found confusing and meaningless information on the homepage, which was caused by either providing poor alt text with images, or none at all. For example, no alt text is provided on two images so the screen reader reports only the image file names, "dot.gif" and "irllogo.gif". Where it exists, alt text does not always correspond to the text content associated with images. For example, a graphical "FAQ" button on the homepage has the text explanation "Frequently Asked Questions" beside it, but the alt text reads "Frequently Requested Information". These could be interpreted as being two different things. Note: These are only a few of the problems found with this site. We present these examples to illustrate the kind of accessibility problems that disabled users face and that can be found using the Bobby test and further expert analysis. Analysis of the Revenue Commissioners Web Site We carried out these two tasks on the Revenue Commissioners web site: Task 1: You are a PAYE taxpayer. You are also blind. Find out your rate of income tax and any allowances you are entitled to. Task 2: Following on from the above, you want to make further enquiries. Find the telephone number and email address of your local PAYE office. This web site features a text-only version to facilitate accessibility. The text-only pages passed the Bobby test but the graphic homepage, which is the entry point for all users, failed to meet WAI Priority 1 compliance. Bobby highlighted a WAI Priority 2 problem: "Do not use the same link phrase more than once when the links point to different URLs". Towards the top of the text-only homepage, a link called "services" takes the user to another list of links further down the same page. This list features another link, which is also called "services". Following this second link takes the user to another page, within the services section of the web site. When two links point to different places they should use different titles, to clarify navigation. The expert evaluation found problems on the graphic homepage. The link to access the text-only site reads "Click here for a text-only version of the site". The word 'here' is the hyperlink but is meaningless when read out of context and would hinder access to the text-only version for someone using a screen reader. Note: These are only a few of the problems found with this site. We present these examples to illustrate the kind of accessibility problems that disabled users face and that can be found using the Bobby test and further expert analysis. Good Usability is Good Accessibility Achieving universal accessibility is part way towards the goal of achieving universal usability. Accessibility problems are those that make it more difficult for a disabled person to use an application or service than for a non-disabled person. They discriminate between users. However, an "accessible" web site may still have serious usability problems that make it equally difficult for any person, disabled or non-disabled, to use the site for its intended purpose. Usability focuses on making software applications and services easy for all people to use, so good usability practices are also good accessibility practices. The remainder of this section provides a brief discussion of the activities necessary for achieving usability. Understand User Requirements The first step in understanding user requirements is to identify the target audiences and the nature of the common tasks they may wish to perform. Development is then focused on addressing the right audience and facilitating the tasks they need to complete. Proper audience and task analysis is an essential element in user-centred design and should ideally occur before system design or programming activities. It involves talking to current and potential users and, wherever possible, observing them using the service. Focus on Common Tasks An interface must take into account common tasks and focus on enabling users to complete them quickly and easily. Interface design that prioritises and highlights alternative routes to completing common tasks will enable different types of users to achieve their goals in a way that suits their needs. Support the User An effective interface supports users by providing a variety of prompts and a frame of reference which builds awareness of their current position and available options. This helps them through tasks and processes and facilitates understanding of the interface structure. Maintain Consistency Users will develop familiarity and efficiency in using an interface if they are able to learn over time how the interface works and the conventions upon which it is built. Consistency is therefore vital, not just graphically but also in the way the interface works. Provide Regular Feedback Clear confirmation that an action has either succeeded or failed helps build trust and confidence. Likewise, waiting time should be accompanied by progress indicators. Meet User Expectations Users must trust an interface before they are comfortable enough to work quickly with it. Users must believe that each action causes the expected result to develop trust. Having the ability to undo actions also builds confidence in the interface. Ensure Interfaces are Versatile Users appreciate a choice of techniques when navigating an interface. As often as possible users should be able to choose input methods, i.e., keyboard or mouse. Provide alternative routes to allow users of different abilities or with different needs to complete common tasks. Test! Carry out user testing as often as possible during development. Users provide feedback that can often be missed by even the most informed expert opinion. The results from empirical and observational user testing can be used to optimise the final interface design. Summary: What You Need to Do Accessibility is a usability issue. Make a commitment to investing in usability and accessibility. Your investment will produce a measurable return by delivering a better service to your customers and reducing development times and costs in the long run, while reaching a larger audience. The sooner you introduce good usability and accessibility practice, the greater the saving on repairs or "retro-fitting" a web site to make it accessible. Database-driven web sites in particular can grow at a tremendous rate, as it is easy to add content on a regular basis. If this is not accessible, the problems and costs of repair are compounded. Investing in usability and accessibility will reduce the likelihood of suffering potentially expensive legal actions which may also damage your profile. Frontend hopes this document has been helpful in providing a first step towards making your online services more usable in a general sense and especially so for people with disabilities. You can find more information relating to these topics at the Frontend Usability Infocentre, an online resource, which is available at www.frontend.com/usability_infocentre. You can also take the following actions to optimise usability and accessibility. If You Already Have a Web Site Use the Bobby test to get a quick impression of accessibility and find some of the important problem areas. However, do not assume that your site is accessible just because it passes this test. Organise an accessibility audit. The best way to do this is to have experts carry out a structured user test with real users or, if time and other resources are limited, a thorough expert evaluation. Use the feedback to create an accessibility development plan. Ensure that accessibility is a priority for web site maintenance in order to avoid undoing previous efforts. For example, if you change a photo of a staff member, make sure to replace the alt text as well. If You are Planning to Develop or Extend a Web Site Measurable accessibility targets should be specified as a requirement in web development briefs, including tender requests. You should have a basic knowledge, or at least be familiar with the WAI WC3 accessibility guidelines and the Report of the Inter-Departmental Web Publication Group. Ensure that your web site developers and web site maintenance personnel have a working knowledge of these guidelines. You should stipulate that your new site achieves at least priority 1 and ideally priority 2 compliance with the latest version of the guidelines. Ensure that your developers use Bobby, or some other WC3 endorsed HTML validator to produce HTML which achieves at least priority 1 compliance. Specify this criteria in your web development brief, including tender documents. The best practice is to pursue an inclusive development process. Involve users who are representative of your target audience from the onset of your project. Include people with disabilities as well as those without. Involve real users in the requirements gathering stage and carry out usability testing at key moments in development. Doing so will not only deliver a more usable web site, it will save time and money in the long run. It is more costly and time consuming to repair a web site in order to make it accessible than to develop an accessible web site from scratch. Frontend - Usability Engineering & Interface Design Dublin (HQ) 40 Westland Row Dublin 2 Ireland Tel: +353 1 2411600 Fax: +353 1 2411601 London 16 Mountford House 25 Britton Street London EC1M 5NY Tel: +44 207 6082971 Fax: +44 797 4151362 Email: mail@frontend.com ---------- End of Document