digital media access group

...excellent accessibility research and consultancy

home > resources > case studies index > craven case study

Electronic Access for All: awareness in creating accessible web sites for the university library

By Jenny Craven, Centre for Research in Library and Infomration Management (CERLIM), Manchester Metropolitan University. Published 10th January 2002, first published by Disability and Information Systems in Higher Education (DISinHE) 28th July 2000, and amended 18th October 2000.

1. Electronic Access for All - Introduction

Access to information available in the university library no longer requires physically visiting the library if this is not appropriate to the user. Increasingly access is made available via the World Wide Web as university libraries develop their presence on the Internet. Support offered by university libraries generally includes details of the services available, opening hours, IT facilities and often floor plans of the building. Access to the catalogue is also offered including browsing of stock, which is available to any visitor to the site, plus the ability for registered members of the library to view their records and renew or reserve items from the library. Increasingly libraries are providing web-based gateways to Internet resources.

Access to libraries via the web site enables students and staff to perform searches and retrieve information from their home or their desktop, and this may also benefit any member of the public who wishes to view items held in the library. The ability to access information from a remote site, such as the home has implications for all. It can mean that users are able to establish whether the item they require is in stock; it may tell them if the item required is in a format suitable to their needs, such as audio format or large print; and also what type of access technology is available for them to use in the library. Such information could have an impact when deciding which institution to apply to; potential distance learning students, for example, may first wish to establish the resources and services which would be available to them as off-campus students. Similarly someone with a disability may wish to establish that the support and resources needed for their particular requirements is available and accessible to them before making a decision. It is therefore in the interest of the institution not only to promote its services but also to make them fully accessible.

Access to information in an electronic environment can have several meanings. Access to the appropriate technology or the provision of access technology enables disabled users to ‘read’ documents in a way that is appropriate to them. Access also relates to the actual content of a document for unless the content of a document is designed in an accessible way, the hardware used or the access technology applied will not be able to access the information. This relates not only to the design of the interface but also to the coding applied, HTML being an example. Web pages need to be designed with accessibility in mind, as there are many ways in which users may wish to access information. The Web Accessibility Initiative¹ illustrates the need to consider the many different contexts people operate in when using the Web with the following examples:

They may not be able to see, hear, move or process some types of information.
They may have difficulty reading or comprehending text.
They may not be able to use a keyboard or mouse.
They may have a text-only screen, a small screen, or a slow Internet connection.
They may not be able to speak or understand fluently the language in which the document is written.
They may be in a situation where their eyes or hands are busy.
They may have an early version of a browser, a different browser, a voice browser or a different operating system.

This study aimed to address the problem of accessibility in a growing electronic information environment. The outcomes of the study aim to:

Assess the accessibility of university library web sites and to inform web designers and creators of the results.
Establish how aware university library web page designers are of issues concerning accessibility of resources. For example whether they are aware of the advice and guidelines available and if so, whether they adopt such recommendations.
Set out recommendations for further action for raising awareness of the importance of providing electronic information that is accessible to all.

Findings should be of relevance not just to creators of the web sites that have been assessed but be applicable on a wider scale and to influence university-wide policy.

The report is divided into two parts:

Part One covers background information to the study, including desk research into the accessibility of university library web sites and the email survey to university library web designers. Analysis and recommendations are included in Part One.

Part Two is the Good Practice Guide. The Guide includes some of the findings from Part One in testing for accessibility. It also provides pointers to projects and initiatives, guidelines and advice and further reading. The aim of this is to help create an awareness of accessibility issues and also to enable web designers and developers to implement accessibility features into mainstream web design.

2. Part One: The Supporting Study.

The Study Phases

The Electronic Access for All supporting study consisted of four phases:

Phase One of the study identified methods available for checking accessibility of web sites. For example, web-based accessibility checkers such as Bobby and Lynx View, guidelines and recommendations such as the Web Accessibility Initiative and the REVIEL report. This phase continued throughout the study as an on-going review process of the identified methods.

Phase Two of the study identified the sample of university library web sites to be tested including, contact names, and tested these against a sample of the identified methods for checking. Analysis for this phase was drawn from the results of software accessibility checkers such as Bobby. Past experience and comments derived from the group of visually impaired volunteers used to test web sites for the REVIEL project also provided a basis for the analysis.

Phase Three of the study comprised an email survey of a selection of the tested university library sites. This aimed to identify whether web designers in the university library were aware of the accessibility issues; whether institutional guidelines were used in the design of the pages and whether accessibility checking methods were used to check pages for accessibility. The survey went on to ascertain how useful the methods chosen were - or were likely to be - when developing a library web site. Finally the survey identified the level of user input used for developing the library web site.

The final Phase Four of the study comprised writing of the final report and the development of a Good Practice Guide based on the findings.

3. Phase One: Methods for checking the accessibility of web sites

The first phase of the study draws on findings from the British Library and JISC funded REVIEL Project ² undertaken by CERLIM - the Centre for Research in Library and Information Management³ , to identify and review different methods available for checking the accessibility of web sites. These methods would be of particular use for web designers or advisers on the creation of web pages. A considerable amount of research has already been undertaken looking into general web design issues ⁴ which cover issues such as what types of information to include and levels of information. For example, whether it is best to use a narrow and deep approach (a few links on a page with many levels) or wide and shallow approach (fewer levels but with more links to a page). These considerations play an important role in the design and development of all web pages and certainly influence analysis for this study.

From the more general observations regarding web design, awareness has emerged of the need to make web pages accessible and that certain design aspects can render a page inaccessible to some people. This awareness has led to some important research and development work, for example Waters’ text on universal web design ⁵ , and the Web Accessibility Initiative (WAI) ⁶, which looks at accessibility issues as well as considering the fundamental design of the web. Organisations actively supporting the WAI include Royal National Institute for the Blind (RNIB), the World Blind Union (WBU), the European Commission, Microsoft, Sun, Netscape, Adobe, IBM and a host of research, development and support centres.

Many other organisations offering advice to designers have used the recommendations of the WAI. The REVIEL project for example has drawn on these in its final report, which identifies 20 Golden rules for Web page design ⁷ . As well as written guidelines, web designers are also offered the choice of a variety of online methods to help ensure that their web pages are accessible and a selection of these is detailed below.

3.1 Accessibility Checking Tools

3.1.1 Bobby

The Bobby Web Accessibility Checker was developed by the Center for Applied Technology (CAST) ⁸ in the USA. Bobby is used to check web pages against an accessibility checklist drawn up by the Bobby program team. Bobby can be used in two ways: a web based version which will check web pages by inserting the URL (Uniform Resource Locator) or a downloadable version which can be used to check web pages which are still under construction.M

The Bobby software analyses pages and produces a textual report, which identifies whether there are any accessibility errors. These are given priority ratings that are in accordance with the Web Accessibility Initiative guidelines. A priority 1 rating for example indicates problems that seriously affect the page’s usability and are depicted graphically as a policeman’s hat with a wheelchair. If the page has no priority 1 errors then it may be eligible for the Bobby Approval rating which is equal to Conformance Level A for the Web Content Guidelines (see 7.2.1). A policeman’s hat with a question mark on it indicates that there may be a priority 1 error that can only be checked manually, not by Bobby itself.

There are two more priority levels Bobby uses to identify problems. Priority 2 indicates problems that should be fixed if possible and Priority 3 indicates problems, which should, if possible, be taken into consideration. Both levels usually recommend manual checking on certain items. Web sites that pass all items under priority 2 are equal to Conformance Level AA for the Web Content Guidelines and under priority 3 are equal to Conformance Level AAA.

Other issues that Bobby takes into consideration are browser compatibility and download time, both of which can impact on the accessibility of the site.

Bobby cannot guarantee total accessibility; it sometimes picks up errors that in reality are not too problematic such as missing alternative text for a bullet point or an underscore. It may also overlook errors such as inadequate alternative text, for example a picture of the library which simply says “photo", or poorly contrasting colours such as a blue background with aqua text. As a starting point Bobby is an extremely useful tool, but for best results Bobby should always be used in conjunction with other checking methods.

3.1.2 Lynx View

Lynx View⁹ will display the page as text only, as it would appear to a text browser and indicating how a screen reader may interpret the page. Viewing a page through Lynx View will identify any images for which Alt text has not been applied and will also show whether the page layout is in a clear and logical order, whether links are separated clearly and how tidily the HTML has been applied.

3.1.3 BBC Education Text to Speech Internet Enhancer (Betsie)

The BBC Education Text to Speech Internet Enhancer (Betsie)¹⁰ is intended to alleviate some of the problems experienced by people using text to speech systems for web browsing. Betsie will convert web pages by making various changes in the HTML. For example, it will remove images and any unnecessary formatting so that when the page is presented it will be in a text only format with any navigation links presented at the bottom of the page. Betsie converts the page in real time, so that any updates to that page will automatically be taken into account. This is very useful as it reduces the necessity to create text only versions and thus designers will only have to update one site. Betsie is also a useful tool in the design stages for checking how accessible a page is. Similar to Lynx View, it will indicate how clearly the information on a web page is presented and highlight areas that require further development.

3.2 Validation Services

Most web designers will be familiar with validation services to check for the consistent and proper use of HTML according to standard recommendations, such as those offered by the University of Melbourne ¹¹ or the W3C Validation Checker (at UK Mirror Service) ¹² . However, Validation Services can also be used for checking accessibility of a page as services generally include some degree of accessibility as part of the checking process. For example, Level 4 of the validation process will check HTML has been applied correctly and will also identify a number of accessibility issues such as missing ALT tags.

HTML TIDY¹³ helps authors tidy up their HTML and will identify areas which could make pages more accessible to people with disabilities. Some services such as HTML TIDY and the Web Design Group (WDG) Validation Checker¹⁴ provide helpful pointers or tags to highlight where the error has occurred rather than leaving this for the user to decipher.

4. Phase Two: Analysis of tested web sites

The provision of accessible electronic information relates to anyone who wishes to read the printed word. This includes people who have difficulty accessing on-screen information, such as people with sensory, cognitive or mobility problems. As well as helping people with disabilities to gain access to electronic information it is generally recommended that good design for accessibility is good design for everyone.

Phase Two of the study tested a sample of university library web sites to see how accessible they were. The tests aimed to ascertain whether web designers were becoming more aware of the importance of making a site accessible, particularly to students with disabilities. Methods for testing included those identified in the first phase of this study. Past experience was also drawn from work undertaken for the REVIEL (Resources for Visually Impaired users of the Electronic Library) Project, although the tests have been broadened to include accessibility in general.

The sample for Phase Two was taken from the SCONUL List of Member Institutions and Representatives ¹⁵ . This was the same method of sampling used for the REVIEL project, although a slightly smaller sample was used (103 sites) than the previous 134 tested for REVIEL (due to changes in the list and because some sites would not load properly).

The university library home page of each of the 103 sites was tested using Bobby version 3.1 Web Accessibility Checker and the Lynx View program (both described in Phase One). Experience also gained from the tests undertaken for the REVIEL Project, as well as feedback from a group of visually impaired volunteers who tested a sample of sites for REVIEL, enabled further analysis to be undertaken during the Bobby and Lynx View testing. Feedback included the importance of fully describing abbreviations and acronyms or the frustration of having to listen to alternative text (for an image) followed by repeats of the text itself. The latter highlighting the need to use a ‘NULL’ tag for images which are described in text immediately afterward, or for bullet points which are used as graphics.

Analysis took account of other issues such as the use of contrasting colours or the appropriate use of font size, and provision of a contact name, but mainly focuses on problems identified by Bobby, as these are consistent with recommendations of the WAI and can easily be corrected. Examples included missing alternative text for images and lack of adequate description or explanation for abbreviations and acronyms. Each of the 103 sites were tested and analysed under the following headings:

Use of ALT attribute
Abbreviations and Acronyms
Moving script or images
Provision of contact name
Contrasting colours and use of fonts
Provision and position of text only versions.

Finally, sites were tested using Lynx View to ascertain how the site would appear as text only. This would also help answer a question which the Bobby program raises concerning the use of tables and whether they have been set out and/or labelled adequately in order to make sense when read out by a screen reader or text-only browser.

4.1 Analysis of Bobby tests

Of the 103 sites tested, 38 received Bobby Approval for accessibility and a number of these sites provided extremely good examples of well designed pages. In general, however, Bobby tended to miss out on a number of potential errors. For example Bobby overlooked the use of inadequate alternative text such as ‘ALT=cour.gif’ to describe a link to ‘courses’, or pages which took a great deal of time to download or simply pages that in reality were very difficult to read because, for example, of poor layout. This highlights the problem of relying on just one program for checking the accessibility of a web page and emphasises the need to adopt several methods. Analysis for this phase encompassed both approved sites and non-approved sites because, as already demonstrated, a Bobby Approved icon does not necessarily guarantee full accessibility.

4.1.1 Use of ALT attribute

94 instances relating to inappropriate use of the ALT attribute appeared in the sites tested. 45 sites had missing ALT text where images were present and 37 had used inadequate ALT text (which included missing ALT text for bullet points or the use of inappropriate or inadequate ALT text for an image). A further 12 sites had not used ALT text for image hot spots - usually displayed as images in a navigation bar.

Sites often provided alternative text for some the images displayed but omitted others - missing alternative text for the university logo being one example which occurred on several sites. However, there were some sites that clearly had not considered using the ALT tag at all on any of the images used.

Inadequate use of the ALT tag included describing an image in very basic detail such as “ALT=photo" for an image of the library building, or using “ALT=logo" to describe the university logo, but not explaining which university it referred to. Another example was the use of wording such as “ALT=newredl.gif" for an image which read “New".

Instances of missing alternative text for graphics such as for bullet points or lines indicated that designers were probably not aware that this is an issue. The page will still be accessible in terms of the information provided, but the screen reader or text browser would pick up that an image is present on the page. The user would not be able to tell that the image is simply a bullet point or a line. In these instances the use of the NULL tag would be most appropriate, as the user does not necessarily need to know that there is a bullet point.

4.1.2 Abbreviations and Acronyms

Abbreviations or acronyms that were not explained or written fully in the first instance appeared in 41 of the sites tested. Bobby does not penalise sites for this, but it is worth bearing in mind that when working in an environment which makes heavy use of abbreviation and acronyms it is easy to forget that what makes perfect sense to someone used to this environment does not necessarily have any meaning to someone else. It is therefore desirable to at least have the acronym or abbreviation written out in full in the first instance - thus also making the site more accessible to sighted users too!

4.1.3 Moving script or images

Bobby recommends that this type of display is avoided and the majority of sties tested did not adopt it.

4.1.4 Provision of contact name

Although Bobby does not include the provision of a contact name for a site on their check list, the W3C recommends that a contact name be given for the web site owner so that users can comment on the design of the page and bring any accessibility issues to their attention. Of the sites tested only 14 failed to provide a contact name and a further 16 provided very basic details such as a name but no address or email. Ideally a site should give the visitor a choice of contact methods such as postal, telephone and email.

4.1.5 Contrasting colours, use of fonts

Bobby mentions contrasting colours in its manual checklist but cannot test sites itself. Of the 103 sites tested, 22 had used particularly poorly contrasting colours, for example lilac text on a white background or aqua text on a blue background. The W3C recommends that only contrasting colours are used for text and background and the RNIB stresses the importance of contrast over the actual colour. Font sizes should also be used according to recommendations, for example using a sans serif font of no less than 10pt is a general guide. Although Bobby and Lynx View did not check font sizes or types, ten of the sites tested had font sizes and types which did not meet with recommendations.

4.1.6 Provision and position of text only versions.

When awareness relating to the accessibility of web pages was first raised, designers began to provide a text only alternative to their sites and Bobby recommends that where a site cannot be made fully accessible a text only version must be provided. This has never really taken off to any great extent, perhaps due in part to the effort involved in constantly updating two versions of a site. It may also be because it has become increasingly easy to design one site which is accessible to all, although as these tests have shown there is still room for improvement.

Only six of the sites tested appeared to provide a text only version and in almost all cases, the link to the text version was positioned at the bottom of the page rather than the top. Positioning the link here forces the user to navigate all the way down the page before being told that a more accessible version had been created for them. One site only enabled users to access the text version via the university home page, so that if they went directly to the library site the text version was not offered.

4.2 Analysis of Lynx View tests

Another way of testing the accessibility of a site is by checking it using a text browser. The Lynx View program gives a good idea of how a site would appear as text only or if read by a screen reader. Using Lynx View is a useful way to cross check against some of Bobby’s recommended manual checks, such as to see if tables “transform gracefully".

Each of the 103 sites were tested using the Lynx View program and although some sites displayed a few, easily correctable errors, only 12 of the sites were considered confusing to read and would need some re-designing to enable them to be accessible.

5. Phase Three Survey: Email survey and analysis of findings

In order to establish levels of awareness regarding accessible web design the next phase of the study went on to conduct an email survey of a selection of the tested university library sites using the contact name given on the library web page. The library web designers were asked a set of questions to identify the following:

Whether university library web designers are aware of the accessibility issue.
Whether the library uses institutional guidelines or templates in the design of their web pages.
Whether or not they use methods such as those described above to check their site for accessibility.
How useful they feel these methods are - or are likely to be - when developing a library web site.
What level of user input (if any) is used when developing the library web site.

A 30% response rate identified a workable sample from which the following analysis has been derived.

5.1 Survey Findings

An overview of the respondents’ location within their institution revealed that 22 were based in the library, 5 outside the library and 3 unidentified. A breakdown of job titles revealed that 8 job titles included responsibilities for the faculty library, library support, information services and information advisor. 4 Assistant Librarian job titles were identified. 6 job titles included IT and electronic information responsibilities all within the library and information service. 1 job title of computer technician was not within the library itself.

5 job titles specifically identified themselves as having web responsibilities such as Web Designer or Web Manager. Of these, 2 were based in the library and 3 elsewhere within the institution.

3 job titles did not fit into any specific category, for example Databases Manager, and the job title of 3 respondents could not be identified.

5.1.1 Web design responsibilities

The first question asks whether designers of library web pages are library staff with web publishing responsibilities that are solely within the library, or whether they have web responsibilities within the institution as a whole. The question also attempts to identify whether the initial design of the web pages is undertaken in house or externally.

37% of respondents replied that their web responsibilities did not lie solely within the library. Of these about half had university wide responsibilities and the other half responsibilities relating to specific departments, including the library.

63% of the respondents indicated that their web responsibilities were solely for the library site, indicating that they are members of the library staff rather than university staff with general web responsibilities that include the library. 23% (of the 63%) stated that their responsibilities lay purely in the updating of information, although a small number of these stated that whereas they had not been involved in the initial design, any re-designs or development work would be their responsibility, either solely or as part of a library working group. 77% (of the 63%) indicated that their responsibilities went further than just updating of information to include design and development of the pages.

5.1.2 Use of Institutional guidelines

Question two looks at the actual design of the web pages and whether developments undertaken are consistent with developments in the design of university wide web pages. The sample were asked whether institutional guidelines or templates were used in the creation and/or updating of the library web pages.

60% stated that they used institutional guidelines or templates, 40% did not. Reasons for not using the institute’s template varied from 13% who stated that it was not suitable for the library’s needs, 7% who stated that the library had developed their own template, either because the institutional one was not suitable or that one was not available and 13% who stated that they used the institutional template to develop their own version. A further 13% stated that institutional guidelines or templates were about to be developed.

5.1.3 Training levels

To establish training levels the sample was asked what training they had received in the following web authoring related areas: HTML authoring, general web design, accessible web design, or any other relevant training. 80% of respondents indicated that they had received some kind of training, 20% indicated that they had received no formal training.

HTML authoring scored highest in this category, with 70% of respondents, 30% of the total identified this category as the only type of training received. 37% of respondents identified general web design, and web publishing training courses were identified by 34% of the respondents. Only 20% of all respondents indicated they had received some training relating to accessible web design.

The sample was then asked to identify the type of training received. Netskills courses were the most frequently cited training packages: 34% named various Netskills training packages, both in-house and externally. 17% simply stated that they had received in house training of some sort and one had attended an unnamed external training course.

Other types of training courses included Dreamweaver, Front Page and a UKOLN course on web management. 7% of respondents said that they had been self-taught, either as part of a basic in-house package or by trial and error as no training or support had been offered.

5.1.4 Accessibility awareness

Having established training levels, the survey sought to identify levels of awareness in creating accessible web pages. The sample were asked to identify which accessibility checkers they had been made aware of from a list of Validation, W3C Guidelines, Bobby or ‘Other’. Cross analysis has been used to compare levels of training with levels of awareness.

87% of respondents indicated that they were aware of Validation services, 73% were aware of the W3C and 60% of Bobby. Under the ‘other’ category, checking devices mentioned were WebHelp and the RNIB design guidelines and hints for designing accessible web sites.

The 20% who had previously stated that no formal training had been given indicated that they knew about methods for checking accessibility such as Validation services and Bobby and that they were aware of the W3C.

Of the respondents who had identified HTML authoring as the only training received, awareness was also shown of accessibility checkers. Respondents identified Validation Services, W3C and Bobby. Of the 20% of respondents who had received training in accessible web design, 33% had not been made aware of Bobby (but were aware of Validation and W3C); the others identified Validation, W3C and Bobby.

5.1.5 Accessibility checking

The sample was asked to identify which methods (if any) had been used for checking the accessibility of their web pages and also which methods were the most useful. They were given the choice of HTML Validation, W3C Web Content Guidelines, Bobby or ‘Other’ methods, which they were asked to identify.

67% of respondents had used at least one of the methods identified in the previous question. HTML Validation was the most frequently used, followed by Bobby and W3C. Despite Validation being the most frequently used of the checkers, Bobby was identified as by far the most popular for ease of use followed by W3C and lastly HTML. Comments about Bobby were all positive and included “replied in English", “simple to use" and a “practical tool". General comments about Validation included “a bit too clever" and “wasn’t too impressed" and the W3C was referred to as “tedious". So, although people seem to be more aware of the use of Validation Services to check for accessibility, those that have tried other methods seem to have found Bobby to be the best for ease of use.

5.1.6 User input

The sample was finally asked to identify the level of user input adopted in the development of the web pages to ascertain whether user input is incorporated into the design and development of web pages.

Only 13% of responses to this question were negative. For example, “none" or “not much" or “feedback requested but not necessarily taken". In one case it was assumed that because no feedback regarding accessibility had been received that users were happy with the service. This may well be true but it is hoped that the web pages were also checked to ensure this really was the case.

23% respondents mentioned the use of feedback forms available via the web pages and 13% mentioned the use of focus groups. Others simply stated that “feedback is invited" or “comments are welcomed".

5.2 Summary of Analysis

The survey has revealed that a significant number of staff with responsibilities for the library web site are actually based in the library itself. The ‘library’ was identified under variants such as library, learning resources centre, library and learning resource centre or learning support centre. Job titles, whether based in the library or elsewhere within the institution also varied, ranging from the more traditional library based job titles such as Librarian, Faculty Librarian and Assistant Librarian to computing and IT related job titles such as IT and Electronic Information Officer, IT advisor, Electronic Information Manager. A few job titles described more web specific areas such as Web Designer and Web Manager.

The survey identified that a significant percentage of library staff have been given responsibility for the design, creation and updating of the library web site. Design responsibilities have either been assigned to them at the initial setting up stage of the site, or they have acquired these responsibilities after the initial design stage, but were expected to continue to re-design and develop the site as well as updating information. A smaller percentage of designers do not appear to be library staff, but have general web responsibilities either for the university or for specific departments.

The use of institution-wide templates or guidelines was split between 60% who used them and 40% who did not, with the most frequent reason for not adopting the institution’s templates being that they were unsuitable for the library. Why this is the case may require further analysis of the templates and the library sites, but it seems that a level of consistency across the university would be desirable and therefore designers of the library pages and designers of the institutional templates ought to be encouraged to collaborate in developing a style which is acceptable to all. It should be noted that 13% indicated the university was in the process of re-designing the existing guides.

Training of some kind had been received by 80% of the respondents, the most frequent category being HTML authoring which was identified by 70% of the respondents. 30% of respondents did not identity any other category. Apart from the 30%, a mixture of general web authoring and web publishing courses were cited, in all cases Netskills was named the most frequently as the type of course provided - both as an external course and in-house. Of all the respondents only 20% identified training specifically on accessibility issues.

Respondents showed reasonable levels of awareness of accessibility checking devices. 87% indicated that they were aware of HTML Validation services, 73% of W3c and 60% of Bobby. Other devices mentioned were WebHelp and the RNIB design guidelines. The 20% of respondents who had previously indicated that no formal training had been received did appear to have some knowledge of accessibility issues, citing Validation and Bobby as the most popular with a few also being aware of W3C.

67% of respondents had used at least one of the identified checking devices to check their pages for accessibility. The most frequently used of these was HTML Validation, followed by Bobby and lastly W3C. Regarding ease of use, Bobby was identified as by far the most popular and respondents included comments such as ‘replied in English’ and ‘simple to use’.

The final part of the survey asked about user involvement in designing and updating the web pages. A limited number of respondents replied in a negative way to this question indicating that very little or no user input was adopted and in one case stating that although feedback was requested it was not necessarily taken into account. Most respondents demonstrated a positive attitude towards the involvement of users in the planning and development of web pages and feedback was generally collected via a comments link on the web site, or through from library focus groups. However, the former method may be too passive to produce systematic feedback.

6 Conclusions and Recommendations

Phase One of the study revealed that help and advice on creating useful and accessible web sites is available for designers. The sources identified in this study are just a few examples of the type of information available. In order to avoid confusion and inconsistencies it is important to ensure that guidelines, recommendations and checking devices are in agreement with one another. The work of organisations and initiatives such as the W3C/WAI help to ensure such consistencies are maintained and this is the main criteria used in identifying methods available for checking accessibility of web sites for this supporting study.

Phase Two, testing of library web pages, identified that little seems to have changed since the REVIEL tests were undertaken in 1998. This is perhaps not surprising, as once a site has been created there may be little motivation to change it very much apart from general updates.

The Phase Three survey revealed that although there does appear to be a general level of awareness of accessibility issues relating to the design and development of web pages within the university library, this needs considerable development in order to ensure all library web pages are fully accessible to all.

Although a significant number of library staff have responsibility for the library web pages this clearly is not always the case. Responsibility for the library web pages can rest with staff who have institution wide web responsibilities or for staff who manage a number of department pages which happen to include the library. This being the case, awareness raising activities should be targeted to staff (both management level and front line) of the institution as whole rather than being specific to the library; training and staff development materials therefore need to reflect this.

Respondents indicated that responsibilities could change, for example some were not involved in the initial design of the library web pages but in future would be expected to consider any re-design and development. This demonstrates a need for awareness raising activities in the area of accessible web design that ideally should be included in guidelines and instruction manuals relating to web authoring and web design.

Training provided in this area has been identified mainly as general courses on web authoring with little specific training on accessibility issues. This emphasises the need to include accessibility issues as standard in all web training packages. The availability of training may also be influenced by the constraints of time and staffing levels; in these cases it may be more appropriate for staff to participate in online training courses such as the workpackages offered by EASI or the Writers Guild (see 7.2.9.1 and 7.2.9.3). These courses allow a degree of flexibility as to when or how the user participates, thus enabling staff to take part at a time that suits them.

Most respondents demonstrated an awareness of checking devices; in particular the use of Validation services to check the HTML applied to the pages. Respondents indicated that they had not necessarily found Validation services particularly helpful, as they were sometimes confusing to decipher. A similar reaction was given to the W3C guidelines. A large number indicated that Bobby was easier to understand and implement than the Validation services or W3C guidelines.

Validation services therefore need to become much more user friendly to enable web authors, particularly those who are new to web authoring, to implement recommendations. A solution could be to incorporate Bobby style features and reporting to the Validation services so that designers could automatically check pages for accessibility while validating their HTML. This would hopefully encourage them to include accessibility features to their pages, particularly if clear instructions have been given such as those suggested by Bobby. Incorporation of the W3C List of Checkpoints¹⁶ in validation services could also raise general accessibility awareness levels but without necessarily having to go into too much depth.

7. Part Two: The Good Practice Guide

Phase Four

Drawing on the recommendations from the Electronic Access for All study, this Good Practice Guide aims to raise awareness of accessibility issues and to provide a list of useful resources for web site creators, designers and developers of university library web pages. The Guide is aimed primarily at library and information professionals who have taken on responsibilities for the design and/or upkeep of the library web site. However, it is also intended that the findings and recommendations in the Good Practice Guide be transferred across all departments in higher education, to inform developers of institution wide policies on issues of web design and to enable access of electronic information to all.

The layout of the Good Practice Guide has been divided into sections to cover the issues surrounding accessibility and to provide pointers towards resources and tools for advice and further information. Sections provided are as follows:

Projects and Initiatives.
Guidelines and Advice.
Testing Accessibility.
Further Reading.

7.1 Projects and Initiatives

7.1.1 Web Accessibility Initiative

One of the most important developments in raising awareness of web accessibility issues has been the work undertaken by the World Wide Web Consortium (W3C)¹⁷ . The W3C is the body responsible for co-ordinating developments on the Web, and in particular for encouraging the use of standards by developers. In 1997 the W3C launched the Web Accessibility Initiative (WAI)¹⁸ . The WAI commitment is to lead the Web to its full potential including promoting a high degree of usability for people with disabilities. The WAI, in co-ordination with other organisations such as the RNIB, the World Blind Union and the European Commission, is also pursuing accessibility of the Web through five primary areas of work: technology, guidelines, tools, education & outreach, and research & development.

7.1.2 RNIB Digital Access Campaign

The RNIB Digital Access Campaign¹⁹ was set up to raise awareness of accessibility issues, to provide advice and guidelines on better web design and to provide a forum for joint work in campaigning for better web accessibility through its email distribution list. The Campaign offers advice and guidelines via its web site and offers a (charged) web audit which will provide a full report on the accessibility of a site plus recommendations for improvement. To date a number of high profile organisations have turned to the RNIB for an audit of their web site: examples include 10 Downing Street and Marks and Spencer. The Campaign invites people to alert them to poorly designed web pages so that they can make contact to offer some initial pointers to guidelines and advice on accessibility. A video produced by the Campaign called Web sites that work is available free of charge from the RNIB. It covers the main areas of accessible web design and demonstrates how good design can help people with a variety of disabilities.

7.1.3 DISinHE

Currently based at the University of Dundee, the JISC funded Disability and Information Systems in Higher Education (DISinHE)²⁰ service works with higher education institutions and other relevant bodies to create a culture where technical support to students and staff with disabilities becomes part of the standard provision of support available. DISinHE also provides advice on policy and strategy issues to institutions in the higher education sector and JISC. The service is likely to move from Dundee to another higher education institution in late 2000.

DISinHE has funded a number of supporting studies aimed at helping to ensure that the technological requirements of disabled staff and students in HE are met, several of which are on the subject of accessibility. For example, Providing accessible IT support for disabled students and The Web for people with visual impairment ²¹ . The studies are designed to produce examples of good practice together with guidelines and recommendations for strategies, or tools that encourage better practice within institutions. Details of the studies are available on the DISinHE web site and the outcomes will also be published on the web site and distributed to HE institutions.

7.1.4 Resources for Visually Impaired users of the Electronic Library (REVIEL).

Resources for Visually Impaired Users of the Electronic Library (REVIEL) project ²², undertaken at CERLIM (the Centre for Research in Library and Information Management) at Manchester Metropolitan University has laid the groundwork for a National Accessible Library Service (NALS), which would draw libraries from all sectors into the provision of accessible, hybrid (traditional and electronic) services. Based on co-operation between all sectors, and drawing together national expertise with local delivery, a NALS would be a major building block for inclusive services. An important stage of the project focussed on the examination of a wide range of electronic information services available from the viewpoint of access by blind and visually impaired people. Web pages in particular were looked at, and a variety of tools were used to analyse their accessibility as well as a group of visually impaired volunteers. Findings from this stage of the project formed the basis for this supporting study.

7.2 Guidelines and Advice

7.2.1 Web Content Accessibility Guidelines.

Produced by the WAI, the Web content accessibility guidelines²³ is an extensive document containing recommendations for making web pages accessible. The guidelines explain how to make web content accessible to people with disabilities, including how to make multimedia content more accessible. The WAI Content Accessibility Guidelines have been updated during the WAI’s three-year programme (the first phase of its work to be completed by the year 2000²⁴ ). To complement the Content Accessibility Guidelines, the WAI has produced a List of Checkpoints for Web Content Accessibility Guidelines document, which is available via the W3C web site²⁵ , plus a Quick Tips ²⁶ list which can be ordered on a vinyl business sized card, again from the WAI web site. The Quick tips aim to provide at a glance references to making web pages accessible and is perhaps more digestible than the 27 page guidelines.

7.2.2 DISinHE Information Bulletins

Information Bulletins on accessibility are available from the DISinHE web site and cover Implementing an Accessible Web and Web Content Accessibility²⁷ . Bulletins provide additional links to other useful resources and web sites on this subject. DISinHE has been involved in the production of a handbook on guidelines for accessible courseware, commissioned by the Teaching and Learning Technology Project.

7.2.3 National Library for the Blind Accessibility Guidelines

The National Library for the Blind (NLB)’s web site²⁸ has been produced with the needs of blind and visually impaired users in mind and therefore accessibility of the site is of paramount importance. The NLB Accessibility Guidelines²⁹ are based on the design features used in creating the web site and provide a bullet point list covering accessibility issues such as text, images, tables, frames, hyperlinks, structure and navigation. The guidelines provide a general overview of accessibility issues and how they can be addressed; they also direct users to further information by recommending the work of the Web Accessibility Initiative.

7.2.4 Royal National Institute for the Blind Hints for Designing Accessible Websites

The RNIB’s Hints for designing accessible website³⁰s provides advice on designing accessible web pages but stress that “attractive dynamic designs, which are fully accessible can be achieved" - in other words an accessible page does not have to be a boring one. The leaflet covers some of the main points such as background and text; images; links; frames; and also some of the more advanced features such as JavaScript and plug-ins. The RNIB also refer to the W3C/WAI for further advice on this subject.

7.2.5 The Web Design Group

The Web Design Group³¹ was formed to promote the use of valid and creative HTML documents and to promote the creation of “non-browser specific, non-resolution specific, creative and informative sites" that are fully accessible to all users. The web site includes information on the reasons for writing accessible web pages and accessibility tips, and addresses common accessibility myths. It also provides a validation service to check HTML for accessibility errors.

7.2.6 Guidelines produced by Software Providers

A number of software providing organisations produce guidelines on accessibility for their software and also on web accessibility. For example Microsoft have produced web-based guidelines for accessibility ³² . The Web Guidelines include information about the need for accessible web design, with relevant articles on the subject. The Guidelines also demonstrate how the use of different browsers can alter the way a page looks and potentially render it inaccessible. Other recommendations on the site include the provision of alternate pages and information about the Web Access Symbol devised by the National Center for Accessible Media (NCAM).

IBM Web Accessibility Guidelines³³ are available on the IBM Special Needs web site. The site includes Web Guidelines for accessibility, aimed at web site editors and General Guidelines that are aimed at web developers. The Web Guidelines include information on all the usual accessibility issues such as images, tables, hypertext links, browsers and checking devices. The Special Needs Web site also includes a useful article on experiences in implementing the guidelines in IBM (see further reading below).

7.2.7 Accessible Web Authoring Resources and Education Center

The Accessible Web Authoring Resources and Education Center (AWARE) provides an Accessible Web Author’s Toolkit ³⁴ on its web site. The site includes links to evaluation tools such as Bobby; tools which can assist authors in correcting or ‘cleaning up’ web pages, including HTML Tidy, and WHAT (WWW HTML Accessibility Tool); web authoring programs such as HotMetal Pro and the WAI Authoring Tool Working Group; and links to accessible browsers such as Lynx and pwWebspeak.

7.2.8 Trace Research & Development Center

The Trace web site offers Design Guidelines and Strategies for meeting the requirements of the (US) Telecommunications Act³⁵ . Although the focus of the legislation is US based, topics covered are of universal interest. For example functions are covered which will address issues such as access to moving text; availability of auditory information; availability of visual information for low vision users. Each topic covered includes a hypertext link to further information.

7.2.9 REVIEL Guidelines

The REVIEL Project developed Guidelines for Accessible Web Pages, based on recommendations from a variety of sources including the RNIB and the WAI. The Guidelines have been developed into a set of 20 Golden Rules for Web page design and are documented in the final report of the project: The Integrated accessible library: a model of service development for the 21st century³⁶ . It is suggested that the dissemination of such guidelines would be an important role for a national library service co-ordinating agency, but it is important that they are updated regularly.

7.2.10 Accessible Web Design Courses

Courses on web design and authoring are widely available, either as an externally attended course or one that can be attended virtually online or downloaded as a workpackage. A number of courses currently available include accessibility issues into their web design programs, Netskills being one example. Most of the courses available carry a course fee but tend to offer more than just a list of instructions or links. The advantage of attending a course online is that students can often ‘attend classes’ at a time convenient to them. For example EASI (see below) alerts students when the next class is commencing and they can then choose when to ‘attend’ via the web site. An email discussion list is attached to this course for students to exchange views, so as a rule it is best for students to try and keep up with the lesson plan, although this is not absolutely necessary.

7.2.10.1 EASI Online Workshop

EASI (Equal Access to Software and Information) offers an online workshop on Barrier free web design ³⁷ . The workshop lasts for four weeks and is comprised of eight lessons that can be undertaken at the students’ convenience and encourages interaction and information sharing with other students via an email discussion list. The workshop covers all the main issues relating to accessible web design such as general design principles for accessibility, dealing with graphics, audio and video, using style sheets and mark up features, and validation for HTML and accessibility features.

7.2.10.2 Netskills

Netskills’ extensive range of workpackages includes access issues in the Exploring web design issues workpackage ³⁸ . The workpackage covers areas such as good practice in designing accessible web pages, use of logical formatting tags, the ALT attribute and methods for checking sites for accessibility such as Bobby.

7.2.10.3 Writers Guild

The Writers Guild offers an online course on Designing for Universal Accessibility with HTML 4.0 ³⁹ which runs for 6 weeks. The aim of this course is to show you how to use HTML 4.0 to make your pages accessible to everyone. Courses run around 6 times per year and the only pre-requisite for attending is an intermediate level HTML skill.

7.3 Testing Accessibility

7.3.1 Accessibility Checking Tools

7.3.1.1 Bobby

The Bobby Web Accessibility Checker was developed by the Center for Applied Technology (CAST) ⁴⁰ in the USA. Bobby is used to check web pages against an accessibility checklist drawn up by the Bobby program team. Bobby can be used in two ways: a web based version which will check web pages by inserting the URL (Uniform Resource Locator) or a downloadable version which can be used to check web pages which are still under construction.

The Bobby software analyses pages and produces a textual report, which identifies whether there are any accessibility errors. These are given priority ratings that are in accordance with the Web Accessibility Initiative guidelines. A priority 1 rating for example indicates problems that seriously affect the page’s usability and are depicted graphically as a policeman’s hat with a wheelchair. If the page has no priority 1 errors then it may be eligible for the Bobby Approval rating which is equal to Conformance Level A for the Web Content Guidelines. A policeman’s hat with a question mark on it indicates that there may be a priority 1 error that can only be checked manually, not by Bobby itself.

Bobby cannot guarantee total accessibility; it sometimes picks up errors that in reality are not too problematic such as missing alternative text for a bullet point graphic. It also misses errors which cannot be picked up by the software, for example inadequate alternative text such as “photo" for a picture of the library; or poorly contrasting colours such as a blue background with aqua text. As a starting point Bobby is an extremely useful tool, but for best results Bobby should always be used in conjunction with other checking methods and if possible by the users themselves.

7.3.1.2 Lynx View

Lynx View⁴¹ will display the page as text only, as it would appear to a text browser and indicating how a screen reader may interpret the page. Viewing a page through Lynx View will identify any images for which alternative text has not been applied and will also show whether the page layout is in a clear and logical order, whether links are separated clearly and how tidily the HTML has been applied.

7.3.1.3 BBC Education Text to Speech Internet Enhancer (Betsie)

The BBC Education Text to Speech Internet Enhancer (Betsie)⁴² is intended to alleviate some of the problems experienced by people using text to speech systems for web browsing. Betsie will convert web pages by making various changes in the HTML. For example it will remove images and any unnecessary formatting, so that when the page is presented it will be in a text only format with any navigation links presented at the bottom of the page. Betsie converts the page in real time, so that any updates to that page will automatically be taken into account. This is very useful as it reduces the necessity to create text only versions and thus designers will only have to update one site. Betsie is also a useful tool in the design stages for checking how accessible a page is. Similar to Lynx View, it will indicate how clearly the information on a web page is presented and highlight areas that require further development.

7.3.2 Validation Services

Validation Services can also be used for checking accessibility of a page as services generally include some degree of accessibility as part of the checking process. Level 4 of the validation process for example, will check HTML has been applied correctly and will also identify a number of accessibility issues such as missing ALT tags.

HTML TIDY⁴⁵ helps authors tidy up their HTML and will identify areas which could make pages more accessible to people with disabilities. Some services such as HTML TIDY and the Web Design Group (WDG) Validation Checker⁴⁶ provide helpful pointers or tags to highlight where the error has occurred rather than leaving this for the user to decipher.

7.4 Further reading

7.4.1 Virtually inaccessible⁴⁷ .

A clear and concise summary of accessibility issues surrounding the web has been produced by the UK Office of Online Networking (UKOLN), focussing on the need for public libraries to be aware of accessibility issues and summarising the main points, such as use of images, maps, tables, frames etc. Consideration is given to standards in accessible design such as those of the W3C and ways in which web pages can be checked for accessibility using tool such as Bobby. The article concludes with possible ways to proceed, describing development work such as that undertaken in the United States to implement web accessibility standards.

7.4.2 Deafblind web access⁴⁸

The author, James Gallagher who is deaf/blind, describes the issues that affect him as a deaf/blind user of the web. The article provides an insight into the problems experienced and helps sighted users to understand some of the frustrations caused by inaccessible web design.

7.4.3 Universal access by design ⁴⁹

Some practical advice is offered in this article for making web pages accessible, working on the theory that “universal access to information is a right, not a favour". Although it concentrates mainly on the problems faced by blind users trying to access web pages using a screen reader, the article emphasises the fact that making web pages accessible for this group of people improves access for all. The article covers technical solutions for accessing web pages such as access technology; then moves on to consider some general design principals such as the use of images, columns and forms; finally covers more advanced design features such as JavaScript and PDF files.

7.4.4 Accessible web site design: how not to make a meal of it ⁵⁰

A summary of how to make web sites more accessible, including a section on what has not been covered in much of the current published advice. Based on the authors’ consultation with the users themselves, this provides more of an insight to what the users think which ties in with earlier comments made relating to using a variety of accessibility checkers - including humans.

7.4.5 Experiences implementing web accessibility guidelines in IBM⁵¹

The implementations of the Web Accessibility Guidelines in IBM are described in this article. As well as covering the steps taken to implement the guidelines the article includes some useful information relating to general disability issues, such as summaries of different types of disabilities. For example, it describes how different types of visual impairment can present a number of problems such as with colour, depth and fonts. The Guidelines also cover hearing, mobility and cognitive impairments.

7.4.6 The integrated accessible library ⁵²

The Resources for Visually Impaired Users of the Electronic Library (REVIEL) Project has investigated the current state of accessible services and explored what would be needed to achieve national excellence in this field. The final report of the project: The Integrated Accessible Library: A model of service development for the 21st century makes the case for a national initiative to make all library and information services accessible to people who are blind or have a visual impairment. The report includes a chapter devoted to ‘Making Electronic Formats Accessible’ as well as another chapter on the ‘Accessibility of current electronic information services in the UK’ which looks specifically at the JISC online services and also at a selection of UK Higher Education libraries’ web sites.

8. Bibliography and References

Bibliography

Brazier, H. and Jennings, S. How not to make a meal of it. Library Technology, 4 (1), February 1999 pp10-11.

Brophy, P. and Craven, J. The integrated accessible library: a model of service development for the 21st century. Manchester: CERLIM, 1999.

D’Angelo, J. and Little, S.K. Successful web pages: what are they and do they exist? Information Technology and Libraries, 17 (2), 1998 pp71-81.

Gallagher, J. Deafblind web access. Free Pint, Issue 14 May 1998.

Graves, J.K. Design considerations for the Library of Congress learning page: providing learners context and access to collections. Library Trends, 45(4), 1997, pp676-686.

Jenkins, P. Experiences implementing web accessibility guidelines in IBM, April 1997.

Kerr, M. Universal access by design. Vine 106, 1 September 1997.

Ormes, S. and Peacock, I. Virtually inaccessible. LT World, 3 February 1999.

Waters, C. Universal web design. Indianna: New Riders Publishing, 1997.

References

Disclaimer

Every effort has been taken to ensure the accuracy of the information on this web site . However, DMAG wishes to emphasise that although the contents are regularly reviewed for accuracy, it is the responsibility of the user/reader to check the accuracy of relevant facts before entering any financial or other commitment based upon them. If you do happen to come across any inaccuracies, DMAG would appreciate your help in informing us.