Accessibility & Usability for e-Government |
|
Note: Since our last review in 2005 Revenue.ie has been completely revised with considerable improvement to both usability and accessibility. We are in the process of updating this white paper, should you want to be informed when it is released, please email This e-mail address is being protected from spambots. You need JavaScript enabled to view it A Primer for Public Sector Officials. November 2000 (updated June 2005) Contents
1 IntroductionUpdate: This document was originally researched and written in November 2000. At that time it was obvious that accessibility was about to become a major issue, especially for public sector webmasters and service providers. Following it's original publication our 'Accessibility & Usability for eGovernment' white paper became the most popular Frontend publication and remains one of our most requested content items to this day. As part of our continued work in the area of accessibility we reviewed the document to see if the content was still relevant 5 years on. We have added in some comments and updates, however, on the whole, the original research remains remarkably accurate. While many sites are now much improved the same accessibility issues are still occurring with depressing regularity. Of the three sites reviewed in 2000 only one shows any significant improvement in accessibility. The lack of progress is clearly related to the requirement of motivating factors, particularly with respect to legislation. The market advantage of universal design can also provide an incentive to organisations, both public and private; however, many organisations do not embrace this opportunity. However, accessibility is a social issue that must be addressed by governing bodies throughout the world. It is their responsibility to drive awareness in the community at large and ensure that all citizens are treated equally. 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:
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:
As part of this discussion, we present the findings of an accessibility analysis of three current Irish Government web sites:
We describe some of the problems that disabled people will have with these sites and how they can be avoided. 1.1 About the AuthorsFrontend (www.frontend.com) is a consultancy providing user-centred software solutions for e-businesses, online applications and information sources, and emerging technologies such as WAP. We are usability experts and view accessibility as an important component of general usability. Usability focuses on making applications and services easy for people to use. Accessibility focuses on making them equally easy for everyone to use, including people with a disability. 2 The Importance of Accessibility Awareness and ActionThere 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:
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. 2.1 European Union & Irish Government TargetsSpecific accessibility targets have been set at European and Irish Government levels. The European Union's eEurope initiative, launched in December 1999, states:
The specific actions related to accessibility include, by the end of 2001:
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:
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. 2.2 Legal Actions Against Web SitesAlthough 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:
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. 2.2.1 Update on The Disability Discrimination Act (1995) Part III of the Disability Discrimination Act (DDA) came into force on the 1st October 2004. It specifically mentions access to information services although it does not specifically mention the delivery channel. It also applies to both the public and private sectors with references to banking, insurance and hotels among others. More details can be found at http://www.webaim.org/coordination/law/uk/ 2.2.2 Update on The Disabilities Bill 2001 and The Disability Bill 2004 In Ireland the Disabilities Bill 2001, mentioned above was withdrawn after extensive criticism from a wide range of advocacy groups. The Bill was extensively reworked and was passed by Dail Eireann at the end of May 2005. It is currently being debated in Seanad Eireann and is expected to become law in the near future. 3 Disability and Accessibility: An Overview
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:
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. 3.1 Typical Accessibility ProblemsAlthough 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. Update 2005: Use of frames is increasingly rare public websites as designers become more relaxed about scrolling pages. The use of the CSS OVERFLOW property has also allowed designers to scroll parts of the page without using a separate html page. 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. 3.2 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:
This is similar to the answers you would get from any group of web users. 4 Testing for AccessibilityThere 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. 4.1 Accessibility GuidelinesThe 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 Groupwas set up to fulfil the commitment given in paragraph 42 of the Government Action Plan: [1]
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". 4.1.1 Update on the WAI Web Content Accessibility Guidelines (WCAG) The W3C is currently developing WCAG Version 2.0. These are available in draft form at http://www.w3.org/TR/WCAG20. The new guidelines are intended to cover a wider range of technologies and to encompass the considerable proportion of web content that is not purely HTML. 4.1.2 The National Disability Authority (NDA) AccessIT guidelines In 2002 the NDA launched the AccessIT guidelines.
The guidelines are intended to make accessibility information available to a non-technical non-specialist audience. 4.2 Automatic Testing Tools and the Bobby TestTo 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:
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 that 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. 4.2.1 Update. Watchfire WebXACT The Bobby has been upgraded and modified several times since this report was originally written. Much of the Bobby functionality is included in a new product from the Watchfire company, WebXACT [20]. Although it retains the limitations of all automatic testing tools the output is considerably more comprehensive and also much easier to interpret. 4.3 Expert EvaluationExpert 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:
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. 4.3.1 Update on evaluation tools 2005 Opera 7+ provides several useful options for accessibility reviewers. The software offers several views of web pages including text only, mobile/small-screen and special accessible style sheets.[21] The Web Accessibility Toolbar from Accessible Information Solutions (AIS) [22] provides a range of user checks for accessibility evaluators. The toolbar is only available as a plugin for Microsoft Internet Explorer 6.0.The checks are manual but the presentation of the results and the simple operation speeds up expert evaluations considerably. 4.4 User testingA 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. 5 Frontend e-Government Accessibility AnalysisWe 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:
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:
Our aims in carrying out this analysis were:
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. 5.1 Summary of findingsHere 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:
The expert evaluation identified problems with all three sites, including those pages which passed the Bobby test. 5.2 Analysis of Donegal County Council Web SiteWe 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. 5.2.1 Update 2005 The Donegal County Council Site remains largely unchanged since the first review in 2000. The site retains frames without titles, pop-up windows and does not include ALT attributes on images. 5.3 Analysis of Department of the Taoiseach Web SiteWe tried to complete two tasks on this web site: Task 1: Read the latest report on Partnership 2000. Task 2: 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. 5.3.1 Update 2005 The Department of the Taoiseach site has been rebuilt since the review in 2000. The general level of accessibility is now much improved although it still fails a few checkpoints on some pages. Most of the outstanding issues seem to be once off content submission problems indicating poor editorial controls. 5.4 Analysis of the Revenue Commissioners Web SiteWe 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. 5.4.1 Update 2005 The Revenue Commissioners site was updated in 2004 however the new design retains many of the accessibility issues from the previous site. This also continues to use frames, tables for layout and makes limited use of external styles. All of which contribute a poor experience for users of assistive technology. 6 Good Usability is Good AccessibilityAchieving 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. 6.1 Understand User RequirementsThe 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. 6.2 Focus on Common TasksAn 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. 6.3 Support the UserAn 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. 6.4 Maintain ConsistencyUsers 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. 6.5 Provide Regular FeedbackClear confirmation that an action has either succeeded or failed helps build trust and confidence. Likewise, waiting time should be accompanied by progress indicators. 6.6 Meet User ExpectationsUsers 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. 6.7 Ensure Interfaces are VersatileUsers 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. 6.8 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. 7 Summary: What You Need to DoAccessibility 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. 7.1 If You Already Have a Web SiteUse 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. 7.2 If You are Planning to Develop or Extend a Web SiteMeasurable 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. 7.2.1 Update on Web Site Development 2005 When this report was originally written in 2000 HTML 4.0 was the de-facto standard for all web development. Although the standard for XHTML 1.0 and CSS 2.0 had been released a lack of browser support meant that using these new technologies was almost impossible for most commercial projects. Five years on Validated XHTML and extensive use of externally held style sheets is normal best practice and browser support is almost universal. In most cases developing web sites to using agreed web standards will avoid many of the accessibility issues that occurred five years ago. The only downside is that XHTML and CSS require a higher level of experience and training from web developers. 8 References
|
Search Articles
View Articles by Category
Ask Henry
Got a burning question on technology, usability and all things user centred? Ask Henry, our user friendly guru!
