Making Accessibility Guidelines Usable

Alexis Donnelly1 and Mark Magennis2

1 Department of Computer Science, Trinity College Dublin,Alexis.Donnelly@cs.tcd.ie

2 National Council for the Blind of Irelandmark.magennis@ncbi.ie

Accessibility guidelines are aimed at all those with a role and responsibility in the procurement and development of IT products and services. However, many important members of this diverse audience find these guidelines difficult to use. The result is products with in-built accessibility barriers. This paper de-scribes the structure and presentation of a new set of Irish national IT accessib-ility guidelines. Drawing lessons from past failures, it describes how this struc-ture was developed. The development involved extensive consultation with pro-spective users of the guidelines, in an inclusive user-centred process. Prelimin-ary feedback at this early stage indicates that the new structure is effective, even in the absence of legislation. The account underlines the importance of usability in creating useful resources of this type.

1.0 Introduction and Background

The need for IT-based products and services to be made accessible for people with disabilities is firmly stated in European Union and Irish Government policy. In 1999, the European Commission’s eEurope action plan directed all member states to make their public websites accessible to citizens with disabilities, recommending adoption of the Web Content Accessibility Guidelines (WCAG) 1.0 from the Web Accessibil-ity Initiative (WAI) by the end of 2001 [1]. In Ireland, the third annual report of the Information Society Commission drew attention to the lack of accessibility in many public sector IT services and the importance of developer awareness together with in-ternational standards in the area [2]. It called on all Government agencies to meet the eEurope accessibility targets for websites, specify this as a requirement in tenders, and comply with universal design principles for all projects involving information and communications technology. A national agreement – the Programme for Prosperity and Fairness – between government and other social partners, called for the National Disability Authority (NDA) to develop a national set of IT-related accessibility guidelines to be used by government departments in implementing their commitments [3]. The guidelines would provide a focus for future development and would be refer-enced by future legislation. This paper concerns the development of these guidelines.

Simply providing guidelines does not guarantee that they will be followed. In the Irish case, a previous attempt to impose accessibility standards in a set of publication guidelines for public sector websites [4] had resulted in a poor compliance rate. There

are a number of reasons why guidelines are not followed. These include perceived conflicts with other guidelines and standards; difficulty in understanding or interpret-ing the guidelines; lack of knowledge about how compliance can be achieved; or simply lack of motivation. In short, guidelines are often not in a form that is most us-able for the audience. Indeed, the most recognised set of accessibility guidelines, the WCAG 1.0, has been criticised for being difficult for much of its potential audience to understand [5], [6]. Consequently, the requirements document for the next version of the WCAG includes the provision for understanding by a wider, less technical audi-ence [7].

Mindful of the reasons for past failures and backed by new policy developments, the NDA took the step of commissioning a commercial user-centred design con-sultancy, Frontend Usability Engineering Ltd., to develop a usable set of Irish national IT accessibility guidelines. The resulting design of the guidelines is intended to tackle many of the problems that prevent guidelines being adopted. This has been achieved, chiefly, by following an inclusive user-centred development process. This paper de-scribes that process and the resulting content and structure.

2.0 The Development Process

An inclusive user-centred development process was followed by the principle guideline authors, supported by an advisory group of accessibility experts1. This com-prised the following stages:

An initial scoping and resource identification phase Interviews with IT end users having various impairments An audience analysis and interviews with prospective users of the

guidelines The development of an appropriate structure for the guidelines Audience review and user testing of the structure The development of content Reviews of the content by external domain experts

2.1 Scoping and Resource Identification

The first task was to decide which technologies the Irish IT guidelines should cover, draw up a plan of consultation and undertake a literature search to collect and study existing guidelines and sources of information. A scoping workshop identified some important stakeholders in the development process for public sector IT products, es-tablished audience and end user groups and drew up a preliminary plan for further work. The target list of technologies comprised the following:

Websites and online applications

1 See http://accessit.nda.ie/about_these_guidelines.html for details of authors and members of the advisory group.

Public access terminals and information displays Card-based access technologies Personal computer hardware Personal computer operating systems and software Broadcasting and multimedia services Digital interactive television Telecommunications devices and telephone-based services Mobile devices Emerging applications

2.2 End User Interviews

Interviews with end users having various impairments were used to identify the prac-tical barriers encountered by these groups using current and future IT products and services. This was the first involvement of end user groups and they continued to be involved throughout the development process. The main aim of gathering this inform-ation was to humanise the guidelines by including real-life descriptions and annec-dotes, explaining some of the practical problems that impaired end users have and why these occur. It was felt that accessibility guidelines often come across as dry lists of rules to be followed, with very little about why they should be followed. For ex-ample, to hear an older person say “I have a bad leg which I have to hold straight out in front of me in my wheelchair, so I find it hard to get close to the screen and I can’t see the tiny pictures and text”, immediately puts a designer into that person’s position, giving them insight and understanding about what they are trying to achieve. This make it clear how following the guidelines will help support the goal of social inclu-sion, which promotes “buy-in” and results in better design.

Fifteen end users, having various impairments, were interviewed using an informal semi-structured questionnaire to enquire about their experiences with the different types of technologies. These interviews revealed some important but often overlooked issues. For example, an information kiosk or bank cash machine, however accessibly designed, is impossible for a wheelchair user to use if there are steps in front of it!

2.3 Audience Analysis and Interviews

The end users of the technologies are not themselves the audience of the guidelines. The guidelines are intended for use by designers, developers and procurers. It was es-sential to know the audience, their background and their needs, because difficulty in understanding guidelines is a major problem which the design of these guidelines was intended to overcome. In practice, accessibility guidelines are often written solely for a technical audience. However, other important, but less technically oriented, actors in the IT procurement and development process, then find it difficult to grasp the essen-tials.

The audience analysis began with a review of the typical development process for relevant public sector IT products and services, aiming to identify the major roles and actors involved. This proceeds as follows.

The procurer, who is typically a middle-ranking civil servant with some (or little) technical background, draws up a Request for Tender (RFT) document. Tenders are then compiled by managers in development organisations who wish to bid for the contract, usually with the involvement of in-house technical staff. These tenders are reviewed and scored by the procurer, and a contract awarded to the tenderer which achieves the highest score. Following contract signature, the successful tenderer, in consultation with the procurer, then designs and develops the product or service. Dur-ing development and prior to delivery, the product or service undergoes a process of quality assurance or testing internally by the developer. The procurer may then apply their own quality assurance or procedure to ensure contract fulfilment.

This process review identified three major audience groups:

Developers Procurers Testers and evaluators

Within these groups are subgroups such as project managers, analysts, program-mers and tender writers.

The audience analysis continued via interviews with representatives of each of these groups, in order to identify their likely backgrounds, expectations, specific needs and the contexts in which they would use accessibility guidelines.

Seven public sector procurers (mostly middle ranking civil servants with some technical knowledge) were interviewed. They indicated a positive attitude to includ-ing accessibility requirements into an RFT. Their principal requirements would be as-sistance in drafting the RFT and then in assessing compliance with the agreed con-tract. The guidelines would have to be closely aligned with relevant policy and legis-lation.

Four tender writers and five IT project managers (typically senior project or ac-count managers in a development company) were interviewed. They also indicated a positive attitude to the provision of usable guidelines since this would provide a “more level playing pitch” against which their bid could be assessed. Their main con-cerns were to quickly gain an accurate overview of accessibility problems and the im-plications of compliance to avoid them. Clear, plain English explanations would be extremely useful and the complete set of guidelines should be available in a print formatted version.

Seven developers (typically programmers or engineers) were interviewed, These also indicated a positive attitude to guidelines. However, they stressed that guidelines should be practical. Detailed technical guidance should be available with illustrative examples including the reasoning behind them. Particular solutions should not neces-sarily be imposed, since these would rarely fit their specific development context, but the functional requirements demanded of a solution should be clear.

These interviews revealed that the main delivery channels of relevance for the pub-lic sector in the foreseeable future were websites, information kiosks, telecommunica-tions and desktop application software. Other technologies, such as digital interactive television or mobile devices were thought to be of little relevance.

One of the main findings was that people wanted information that was tailored to their role and the task that they were doing. For example, procurers and project man-

agers didn’t want to be bogged down in detailed technical information aimed at pro-grammers, but wanted practical answers to questions like “How do I specify accessib-ility requirements in an RFT?” or “How do I assess a proposed design that has not yet been built as a working prototype?”. It emerged that the role of the procurement man-ager in the public body and the project manager in the developer organisation are of-ten very similar and there is a need to communicate based on a common understand-ing. Both therefore require the same information. In general, people wanted interpret-ation and direction, rather than just rules. As for testing and quality assurance, al-though it was felt to be very important, there was rarely anyone assigned to it as a specific role and it was generally done in an ongoing fashion, throughout the process, rather than as a discrete stage. This had important implications for the kind of inform-ation that was given.

The results of these interviews were used to inform and guide the later design and development of the guidelines. Like the end users, audience representatives continued to be involved throughout the development process.

2.4 Development and Testing of the Structure

Based on the findings of the audience analysis and the project aims agreed at the scoping phase, an initial structure for the guidelines was developed. After a number of internal iterations, a draft website was created. This implemented the initial structure but only included a small amount of representative content, the remaining content be-ing substituted by placeholder descriptions of the intended information. This was suf-ficient to evaluate in a stakeholder workshop and a set of user tests.

The draft structure was presented at a one day workshop of some twenty individu-als, consisting of prospective users, end users, domain experts and other public sector stakeholders. This workshop was used to gauge initial reaction to the approach taken, obtain feedback on some early presentation ideas and explore possibilities for publi-city and dissemination. The resulting discussions helped to refine many aspects of the design further.

Task based user tests were carried out with a representative sample group, com-prising one public sector procurer, four IT project managers, one tender writer and four IT developers. There was a variable level of accessibility awareness within the group, mostly limited, but with two of the developers being regular users of the WCAG. Each user was given a number of typical scenarios in which they might need to use the guidelines. For example, developers were asked “You have been told that your company’s Internet kiosk is inaccessible to people who are blind. Find out what extra development work will be involved in fixing this and meeting the NDA guidelines”. These scenarios formed a context in which the users accessed the guidelines in a naturalistic way. All sessions were observed and follow up interviews were used to gauge reactions and opinions.

The findings of the user tests resulted in major changes to the structure of the guidelines as well as improvements to the intended content.

2.5 Development and Review of the Content

Once the structure had been fixed, work began on writing the bulk of the content. This relied heavily on the sources which had been identified in the initial scoping phase, but pulled in much information gleaned along the way from end users, developers and other stakeholders. Content was drafted by a number of authors, then edited by a single author, to achieve the goals of simplicity and consistency.

Lastly, the final draft content was reviewed by a panel of invited external domain experts, to ensure technical accuracy. Each expert concentrated on a single technology area, reviewing each guideline and all the supporting information. On the basis of these reviews, the content was updated prior to publication.

3.0 Description of the Content

Having agreed a set of four technology channels to produce accessibility guidelines for, and having defined the background and needs of the different audience types, it was possible to decide what information was required and determine an appropriate style and format. It was clear from the literature study, audience analysis and user tests that the following types of information were required:

Introductory information about accessibility, from the end user’s point of view

An outline of relevant legislation and policy, with references Information about how to go about designing for accessibility Guidance on how to use the guidelines, broken down by role and focussed

on specific tasks An easy-to-use printable checklist for each set of guidelines A simple, detailed definition and explanation of each guideline, to ensure

correct interpretation and understanding A rationale for each guideline, to provide motivation Guidance on how to achieve compliance, with examples where appropri-

ate Guidance on how to test for compliance, at any stage of development

The initial intention was not to create new guidelines, but to refer to existing au-thoritative guidelines and standards, adding explanation and help where appropriate as aids to understanding for the different audience types. This approach was intended to avoid exacerbating the known problem of conflicting guidelines and to avoid doing unnecessary work by creating guidelines where perfectly good ones existed already.

However, with the exception of the Web, in which a single de facto standard set of guidelines, the WCAG, existed and were referenced by both EU and Irish Govern-ment policy, it was not possible to identify single, authoritative sources which stood out above all the rest. That is not to say authoritative and useful guidelines do not ex-ist for these other technologies. Indeed, many organisations such as Trace (http://trace.wisc.edu), IBM (http://www-3.ibm.com/able), Stakes (http://www.stakes.fi) and

Tiresias (http://www.tiresias.org) have produced excellent guidelines and resources. There are also many relevant standards produced by organisations such as ISO, ANSI, ETSI and CEN. However, none of these are as comprehensive and widely adopted as the WCAG, so it was difficult to choose any particular instances as the ones that should be adopted within Ireland.

Another factor was the need for consistency and similarity across the different technology channels. The audience analysis had revealed that IT products and ser-vices often include technologies of more than one type. For example, many informa-tion kiosks use HTML for their user interfaces, so their design should follow the guidelines for both public access terminals and Websites. Similarly, a public tele-phone is a combination of a telecommunications device and a public access terminal. For this reason, it was felt that adopting four totally different sets of guidelines, each written from a different perspective and presented in a different way, would confuse the audience and seriously reduce usability. Instead, it was decided that, with the ex-ception of the WCAG, completely new guidelines should be written, using a common, consistent style and format. Indeed, in the case of the WCAG it was decided that, even though they should be adopted with their meaning unchanged, they would be re-cast to fit the new style and format as closely as possible.

4.0 Description of the Structure

The first important structural decision was to create a website. The NDA had previ-ously published guidelines in book form and it was not the intention to produce an on-line version. However, the nature of the IT development process makes it essential that IT accessibility guidelines are made available online. Initial ideas about an appro-priate structure were influenced by Vanderheiden’s work on priority setting for uni-versal design [8]. Vanderheiden proposed a set of basic components of universal us-ability:

Perceivability of presented information Operability Navigability of information and controls Understability of content

Vanderheiden also outlined the following four dimensions that can be taken into account when prioritising the application of universal design principles:

Severity of impact: The number of people who will be negatively im-pacted by non-compliance and how severely.

Independence vs. co-dependence: The extent to which users can be expec-ted to have help available to them. For example, functions required for ba-sic use would be prioritised highly on this dimension, whereas schedulable maintenance functions would be much lower.

Impact on efficiency or urgency of use: For example, functions that are ir-reversible or need to be carried out quickly would be given a higher prior-ity on this dimension.

Ease of implementation: Referred to as a “pseudo dimension” since it can often work against universal usability.

Although Vanderheiden described these dimensions as ways to prioritise design principles, they can equally well be used as ways of organising the kind of informa-tion that was to go into the guidelines. Indeed, some of these dimensions had emerged in the audience analysis. For example, some interviewees had stated that they would prefer information to be organised in usage-based sections – operating controls, per-ceiving output, understanding content, etc. – similar to Vanderheiden’s basic compon-ents. At least one developer held the view that the guidelines themselves should be or-ganised according to ease of implementation (which Vanderheiden warned against).

When considering which organisational structures to use, it was noted that other accessibility guidelines use many different structures for different types and levels of information. Indeed, a given body of information can often be accessed through mul-tiple structures. For example, the WCAG 1.0 consists of 66 technique-oriented check-points, such as “Provide redundant text links for each active region of a server-side image map” [9]. These are organised using two orthogonal classifications. On the home page, the checkpoints are organised under 14 guidelines – goal oriented cat-egories, such as “Provide equivalent alternatives to auditory and visual content”. In the checklist, the checkpoints are organised under 3 priority levels, relating to severity of impact. A given guideline may include checkpoints of any priority level. Both or-ganisations serve different purposes. For example, the checklist is the preferred access point for many developers, since the priority breakdown is closer to their own priorit-ies than the guideline categorisation.

An analysis of six existing sets of accessibility guidelines, including the WCAG 1.0, revealed the following organisational structures for the guidelines and supporting information:

Severity of impact Technology types and subtypes Information types (rules, techniques, examples, resources, etc.) End user activities (perceiving, operating, etc.) End user impairment types Accessibility principles (e.g. device independence) Audience roles and subroles Relevant statutory requirements impacted Industry sectors Project phases Organisational maturity

Seven of these are used in the final structure of the Irish IT Accessibility guidelines. It was clear that users’ primary considerations were the technology they were dealing with and the purpose for which they needed information (determined by their role). Therefore, in the first draft, the information was broken down at the top

level by both technology and audience role. The home page provided a link into each technology section (Web, Telecoms, etc.) and a link into each role (Procurer, De-veloper, etc.). The intention of this was to cater equally for both role-focussed and technology-focused users. Each role or technology section provided links to the dif-ferent items of information (introduction, checklist, etc.). The user could also choose to narrow the focus further by selecting a role (if they were in a technology section) or a technology (if they were in a role section). A data base-driven design was used to generate virtual pages based on the choices made. For example, a person choosing Procurer on the home page, then Web and Introduction on the Procurer page, would be given an introduction to Web accessibility tailored to the procurer role and back-ground, with navigation links to further information which would be similarly tailored. If the user had selected a role but no technology, they would get a general in-troduction to accessibility tailored to that role, but not tailored to any specific techno-logy.

User tests revealed that this level of choice and precise targeting of information was not successful. Although the role- and task-based information was generally wel-comed, users found it difficult to build a mental model of the site organisation due to the overly-complex design, and therefore had difficulty navigating. In addition to this, the following important issues emerged:

Users often mistook the checklists for the guidelines which meant that they missed much of the supporting information

Some of the link titles were misunderstood, resulting in some of the most helpful information being missed

Users didn’t understand some of the prioritisation, or felt that it was un-realistic in a commercial context

There was confusion between guidelines and policy, with users being un-sure of which guidelines they were supposed to meet and which were “op-tional extras”

These, and many other minor issues, were tackled in the final version, the home page of which is shown in figure 1 below. The page briefly describes the content of the site, then provides links to each technology section (but no role-based links). Fol-lowing this are links to general information on accessibility (what it is and how to achieve it); guidance on how to follow an inclusive, user-centred design process so that a new product or service will be as accessible as possible; and relevant legislation and policy.

Fig. 1. Home page of Irish IT accessibility guidelines

On each technology page, a short introductory paragraph defining what is covered is followed by a link to the guidelines themselves. This provides a sufficiently quick route to the guidelines for experienced users. Figure 2 illustrates this design for the case of telecommunications. Also provided are links to a general introduction to ac-cessibility of that technology (organised by end-user impairment) and a summary test-ing checklist (one of the most common requests received in the audience analysis).

Fig. 2. Introductory page of telecoms accessibility guidelines – top half

The next section of the technology page provides information on how to use the guidelines (see Figure 3). This is presented in a way that caters for a broad range of users, from those who are just learning about accessibility to those in specific roles who have specific tasks to carry out. New users with a less technical background are offered a general introduction to accessibility of I.T. products, written in a non tech-nology-specific manner. Users who have some knowledge of accessibility but not for this technology are guided to the ‘About’ section for that technology.

Fig. 3. Role-specific information for the telecoms accessibility guidelines

Following this are links to the role- and task-specific information which was suc-cessful in the user tests but which had to be moved in order to simplify the site design. Although the tabular structure and its content is identical for each technology channel, the information it links to is specifically tailored for each technology.

The guidelines themselves are presented as a list, broken down by priority, as seen in the successful WCAG checklist. Unlike the WCAG, however, this list does not contain the full text of each guideline (a ‘guideline’ in the Irish guidelines equates to a ‘checkpoint’ in WCAG), but a shortened title. This makes the list much easier to scan and easier to use when printed out in the form of a checklist.

Each guideline has a link to the full text plus the various elements of supporting in-formation. These elements and their purposes are listed in table 1.

Table 1. Common structure for the presentation of each guideline

Element Content Intended User(s)Statement User-centred requirement or goal that the

product or service should meet, stated as a concise directive (“Do this”).

All users

Explanation Defines and expands on words or phrases in the statement.

All users

Rationale Explains why this requirement is import-ant. Describes the consequences of not meeting it. Backs this up with examples and anecdotes where useful.

New users

Techniques Instructs the designer on what features to include or avoid. Gives advice on tech-niques, technologies or design solutions in a non-prescriptive fashion, leaving room for alternative (and possibly better) ways of fulfilling the objective. Includes ex-ternal links to refer the designer to any au-thoritative or widely accepted rules or guidelines that give more precise direct-ives.

Designers

Test methods Guidance on how to test whether the guideline has been met. Provides methods that can be used at various stages – initial design, prototype, finished product.

Testers

4.0 Further Development and Future Work

The structure described here is designed to accommodate future developments. New technologies could be accommodated using the common structures and evolution of existing technologies is made easier by the clear functional breakdown of information elements.

The initial structure has been tested with a small group of prospective users. Pre-liminary feedback indicates that the structure is effective in communicating the essen-tial information quickly, though the presentation requires improvement. However, even at this early stage, the guidelines are being specified in RFTs for the re-design of websites belonging to government departments.

Future plans include expanding and improving the content of the guidelines by pro-vision of:

More links to external resources Additional resources, such as CAD objects defining user anthropometrics New guidelines for emerging technologies, such as interactive TV FAQs

Rewritten and/or reprioritised guidelines in response to feedback from users, and others (the web section will need to be updated when WCAG 2 becomes a recommendation).

Provision of resources to encourage the growth of a community of users around the guidelines would share expertise and techniques, provide feedback on how the guidelines might be improved and expanded and raise awareness of accessibility as a vital part of the development process. Additional features that might be added in-clude:

A search mechanism Enhanced feedback mechanism linking into discussions and FAQs Online support for guidelines users

Although the structure described here has been based on extensive consultation and some testing, undoubtedly some flaws and inaccuracies remain. These will be re-vealed (and hopefully corrected) in use. It is therefore vital, that a community of users is developed and nourished around the guidelines. Therefore the availability of expert help is important. Eventually, it is hoped that new national legislation will reference these guidelines giving added urgency to extending access – see [10] for an eloquent anecdote on the effect of well-enforced legislation.

This paper has described a structure developed for usable accessibility guidelines that arose from extensive consultation with prospective users of the guidelines. Pre-liminary feedback indicates that the structure is effective in communicating the appro-priate information to the appropriate users. Even at this early stage, the guidelines are being used in the re-design of several government websites.

It is anticipated that the extensive consultation process described here will have created a more usable set of guidelines. Furthermore, the consultation process has served to promote “buy-in” by stakeholders in an environment with relatively weak legal compunction. The consultation process has also served to publicise the guidelines themselves. The requirements identified in the work reported here have much in common with those set out for the next version of WCAG, in particular to be more understandable to less technical users.

References

1. Council of the European Union, Commission of the European Communities: eEurope 2002: An Information Society for All, Action Plan. June 2000. http://europa.eu.int/information_so-ciety/eeurope/action_plan/pdf/actionplan_en.pdf

2. Information Society Commission: Information Society Ireland: Third Report. December 2000. http://www.isc.ie/thirdreport.html

3. Irish Government, Department of an Taoiseach: Programme for Prosperity and Fairness. February 2000. http://www.taoiseach.gov.ie/upload/publications/310.pdf

4. Irish Government, Department of an Taoiseach: Web Publication: Recommended Guidelines for Public Sector Organisations. November 1999. http://www.irlgov.ie/taoiseach/publica-tion/webpg/guidelines.htm

5. Colwell, C., Petrie, H.: Evaluation of Guidelines for Designing Accessible Web Content. IFIP TC.13 INTERACT'99 Workshop: Making Designers Aware of Existing Guidelines for Accessibility. (31 August 1999). http://www.info.fundp.ac.be/IFIP13-3/INT99workshop-ac-cessibility.htm#9

6. Colwell, C., Petrie, H.: Evaluation of Guidelines for Designing Accessible Web Content. In: Buhler, C., Knops, H. (eds.): Assistive Technology on the Threshold of the New Millen-nium. (AAATE 99). Amsterdam: IOS Press, 1999.

7. Vanderheiden, G., Chisholm, W.: Requirements for WCAG 2.0. W3C Working Draft dated 26 April 2002. http://www.w3.org/TR/wcag2-req/

8. Vanderheiden, G.: Fundamental Principles and Priority Setting for Universal Usability. http://trace.wisc.edu/docs/fundamental_princ_and_priority_acmcuu2000/

9. Chisholm, W., Vanderheiden, G., Jacobs, I.: Web Content Accessibility Guidelines 1.0. W3C Recommendation 5-May-1999, see http://www.w3.org/TR/WCAG10/

10. Vanderheiden, G.: Addition to the Record: House Judiciary Committee Oversight Hearing on “The Applicability of the Americans with Disabilities Act (ADA) to Private Internet Sites”. 9 February, 2000. http://trace.wisc.edu/docs/ada_internet_hearing/#economic_motiv-ation