Travelling the road towards a SENDA compliant GEES website

Abstract

This article provides an overview of guidance on making websites accessible in the wake of SENDA 2001. The paper also covers some of the common myths surrounding the debate about accessibility and how these can be overcome. We hope this article will be of interest to GEES academics/support staff who have website responsibilities.

Introduction

The LTSN-GEES small-scale project ‘An illustrative guide to demonstrate the concepts and processes in bringing web-based materials in line with SEND legislation’ (also in this edition of PLANET - Ed) was initiated following the UK government’s passing of the Special Educational Needs and Disability Act (SENDA) in May 2001 (The Stationery Office, 2001). SENDA amends the 1995 Disability Discrimination Act (DDA) and includes, with effect from 1 September 2002, the removal of the exemption of further and higher education institutions from Part IV of the DDA (HMSO, 1995). (For more information on SENDA, please see PLANET Special Edition 3 at: http://www.gees.ac.uk/planet/index.htm#PSE3 - Ed)

This small-scale project has found that a major outcome of this amendment has been a concentration on how the Act will impact on the development of internal web pages, such as those found in managed virtual environments and web pages for external consumption. But, to comply with SENDA, it is also necessary to apply the same rigour and good practice to all web pages. Further findings from the project are the lack of understanding with respect to web accessibility within the UK academic community and a reliance on diagnostic tools in search of ‘the answer’ to an institution’s web-accessibility policy.

W3C Priority Levels

The World Wide Web Consortium (W3C) is the organisation commonly relied upon for guidance on website accessibility. W3C is responsible for developing the inter-operable technologies (e.g. specifications, guidelines, software, and tools) that are used on the Web (W3C, 2002). One of its major goals is universal access. Towards that end, the Web Accessibility Initiative (WAI) was set up byW3C to promote accessibility by developing appropriate technologies, tools and guidelines (W3C WAI, 2002).

W3C have produced a list of Checkpoints for Web Content Accessibility Guidelines (WCAG) 1.0 (W3C WAI, 2003). The checkpoints are grouped under 3 priority levels:

• Priority 1 (Level A)

  A web content developer must satisfy a checkpoint at this level. Though this removes some barriers to accessing e-material, many students with disabilities will still be unable to use it.

• Priority 2 (Level AA)

  A web content developer should satisfy a checkpoint at this level. Satisfying this checkpoint will remove significant barriers to accessing Web documents.

• Priority 3 (Level AAA)

  A web content developer may address this checkpoint. Satisfying this checkpoint will improve access to Web documents.

It is worth noting that even strict adherence to the highest priority cannot guarantee accessibility for a specific individual.

What level of compliance should we be aiming for?

The European Commission and the UK government have already adopted WCAG Priority 1 (Level A) as a minimum standard for their websites. The UK academic sector is beginning to look to the Guidelines for both extranet and intranet web page accessibility. WCAG Priority 1 (Level A) should be seen only as the starting point for the development of an accessible academic website; Doyle and Robson (2002) and TechDis (2002) suggest that all sites should aim for the higher, Priority 2 (Level AA) as a minimum.

In the United States, Section 508 of the Rehabilitation Act has required all US federal agencies to make electronic information fully accessible to people with disabilities. This has put accessibility high on the agenda for software developers: companies such as Macromedia, Adobe and Microsoft are all prioritising accessibility.

Myths about web accessibility

Web accessibility is the focus of much debate both within and outside the UK academic community. Many authors argue against accessibility on the basis of various myths, without realising the many advantages of accessibility, and without knowing how easy it can be to improve the accessibility of a web page. Some of the more common myths are:

• an accessible web page consists of dull and boring text;

• an alternative, text-based version of the site is all you need to provide;

• accessible web authoring is expensive and time-consuming;

• web accessibility is too difficult for the average web designer;

• people with a disability don’t use the web;

• web accessibility only helps people with disabilities;

• assistive technology can solve all accessibility problems;

• users should view a site the way the designer intended;

• accessibility issues can be solved using software; o organisation X has the answer;

• nowadays everyone has Internet Explorer;

• if I use this logo my site is accessible.

Due to space restrictions, this paper can only explore two of these myths in greater detail (please contact the author for more details on the other myths listed above).

Demystifying some myths

1. Is a text-based version of a website the solution?

One of the most common approaches in attempting to make a website accessible is the creation of a text-only version of the site, albeit sometimes with less content and functionality when compared with the parent website. This approach has the danger that users with a disability may feel marginalised by being offered a reduced level of service.

There is little justification for a cut-down or text-only site being offered in this way. Authors can use multi-media without sacrificing accessibility. Video, sound, images and Java applets can all have alternative content provided to those who are unable or unwilling to experience these features. Colours, fonts, and margins can also be specified using style sheets. The style sheets can be used to control the layout and look of a web page. Users who prefer, or require, their own styles can view the page in a manner suited to them by overriding the style sheets provided by the website author.

2. My logo means that I’m accessible

Web developers can access a range of evaluation tools that can be used to check on the accessibility of a web page. This appears to have led to a trend towards badging a page with the product’s logo to imply that the page meets an accessibility criterion.

One of the most used web-accessibility diagnostic tools is ‘Bobby’ (Watchfire, 2002). This employs WAI WCAG to provide page and site evaluation support for developers. The latest version, Bobby Worldwide, supports analysis of web pages in compliance with the US Rehabilitation Act Section 508 three priority areas.

Bobby returns three information types for each of the three WCAG priority levels. These information types are:

• a list of automatically detected accessibility errors;

• developer checks, which are errors that require manual examination;

• general guidelines for the developer to check.

Using Bobby effectively is dependent on the developer’s ability to interpret the final report. Deciding what modifications are necessary to achieve the required level of compliance requires knowledge of accessibility issues and HTML.

The availability of diagnostic tools provides web developers with a good starting point to meet the required WAI priority level. Examples of best practice link to relevant checkpoints. However, developers must also undertake their own audit of the web page and interpret the advice given in order to satisfy themselves that compliance has been achieved.

The diagnostic tools are useful for issues such as locating missing text alternatives to graphics and checking for untidy HTML coding. But more is needed to ensure that a site is accessible to all users. Software tools cannot evaluate a site for layout consistency, ease of navigation, provision of contextual and orientation information and use of clear and easy-tounderstand language. The tools do not check what a site looks like without the graphics, without the colours, with different resolutions, with different font sizes or through a text-only browser.

The tools designed to help make a website accessible must be used with caution. They provide automatic checks for only a limited number of accessibility problems, which are based on that developer’s interpretation of WAI guidelines.

Without recognising the limitations of tools such as Bobby, web developers may acquire a false sense of security. They may believe they have met the accessibility guidelines when they receive a diagnostic-tool generated checklist, showing that all issues have been addressed. In reality, however, they may have only adhered to a set of rules, and, in doing so may have produced an inaccessible website.

Most of these tools have a self-certification facility, allowing developers to publicise the accessibility of their site. For instance, to gain the requisite approval and display the ‘BobbyApproved’ icon, a website must successfully address all of the WAI issues that Bobby identifies. Many organisations (including a large number of UK academic institutions) seem to believe that passing the Bobby test will satisfy their accessibility obligations, including the SENDA requirements. Whilst Bobby can be a useful tool, it is all too often misunderstood. Web developers must comprehend that the evaluation process is based on an interpretation of the WAI checkpoints developed by a particular software company. These evaluations must then be acted upon:

• in accordance with the developers’ own understanding of the checkpoints;

• with some appreciation of how their remedial actions are likely to impact on a user with a disability.

Conclusions and Recommendations

Web accessibility is a major concern within the UK academic sector and this is largely driven by the SENDA 2001 which has raised awareness of accessibility issues. However, there remains a lack of understanding about web accessibility and a worrying trend appears to be the use of a text only sub-site where the web designers have decided to create a cut down, text version of their site to meet accessibility criteria. This obviously goes against the goal of inclusiveness and it is hoped that UK academic institutions will not follow this precedent.

Another tendency is for web developers to make use of a self-approval system, such as Bobby, to indicate that a site is accessible. But when using these tools, care needs to be taken to ensure that the user checks are carried out scrupulously. At present it would seem that too much reliance is being placed on these automatic checks.

So, some recommendations for improving the accessibility of any website are that:

• Accessibility should be part of the website’s initial design strategy — not something added at a later date;

• Web-designer training is needed in the meaning and interpretation of the various WAI guidelines;

• Web-designers should recognise that tools such as Bobby offer a good starting point but have their limitations;

• Web-designers should also use manual checks to ensure adherence to WAI checkpoints;

A website which has been designed with accessibility in mind may have the right to display a number of logos which indicate that it meets particular accessibility standards. However, end-users may be more reassured with a single ”accessibility achieved” type of logo. Such an approach might help institutions which at present must decide which Priority level to implement. The creation of a UK web accessibility standard would be better able to provide guidance for UK academic institutions and a single standard should provide clarity for the end user. However, if accessibility is successfully embedded into an institution’s website policy, there should be no need for badges and logos as it will be taken for granted that the site is accessible.

There is a danger that web accessibility may be seen as a mechanistic or a Quality Assurance process relying on checklists and evaluation tools. A cultural shift needs to occur in academic institutions whereby web developers consider not only how to achieve/attain web accessibility but more importantly how the website will be used and who will use it.