e Learning - Specifying, designing and evaluating accessibility
Specifying, designing and evaluating accessibility
Design decisions
In this activity, we examine in more detail the design decisions that affect accessibility for different groups of disabled students. The activity will help you to create accessible resources, or can be used as a basis to inform your discussions with those who create such resources on your behalf.
We introduce the process of including accessibility considerations in the specification of online learning resources, including 10 principles for accessibility that can be included in a specification. This is followed by an overview of the use and limitations of accessibility guidelines. The discussion leads on to the options for evaluating accessibility and looks briefly at automated evaluation tools and their limitations.
First, please read through all the material for this activity, including the design guidelines and resources. Then do the activity task. In the activity task you will return to a scenario from ‘Accessibility, pedagogy and reasonable adjustments’ to consider how to specify accessibility. You will then use two automated accessibility checkers to check the accessibility of a web page and compare your findings with the findings of others in your tutor group.
In this activity we discuss the accessibility of web-based resources and course software. If a disabled student is to engage independently with online learning, she/he will need to be able to manage files and folders, use email, participate in forums, use login screens, assessment submission and feedback systems and all the other tools that are involved.
This resource covers only the use of personal computers, but it is important to note the distinction between these and public service devices. A ticket machine, for example, should be usable by a disabled person without the need for them to use assistive technology. In other words, accessibility should be built into public service devices. This means that people who use assistive technology with a computer will have different requirements for other interactive devices. As you consider non-PC-based technologies in this course, you should bear accessibility in mind. For example, you may be studying delivery of online learning using devices such as Personal Digital Assistants (PDAs). As the boundaries between computers and mobile devices are becoming blurred, assistive technology such as speech output for phones and PDAs is becoming available. Some examples are listed in the Resources at the end of the section.
Even if you are not the person who actually implements the design or writes the code for a course resource such as a website, it is useful to understand the requirements of different users and the implications of these for the designer or programmer. If you are able to construct your specification with a clear understanding of what is reasonable, you will have a more satisfactory ‘product’. It is also cheaper to get accessibility requirements included at the specification stage than it is to fix them when a disabled student registers for a course and the designer or programmer has moved on. If there is no more funding for further development, an inaccessible resource will remain a barrier to disabled students.
Specifying accessibility
You should have a good idea, from the earlier activities, ‘Introducing accessibility and disability’ and ‘Introducing accessibility and assistive technology’, of the way in which disabled students interact with computers.
Students may have different disabilities but some will experience the same accessibility issues while others will have very specific requirements. You may find that some of the requirements at first glance appear to be contradictory. One example is the need for visually driven layout for students with dyslexia, which appears to conflict with the need for text driven layout for visually impaired students. These needs are not mutually exclusive and the flexibility of web technology allows for both to be achieved in the same design.
Design for online accessibility should cater for a wide range of needs and abilities because it is not possible to anticipate everything that might be needed by a particular person. This is because people may have multiple disabilities, their abilities may change over time, people may be temporarily disabled due to an accident (e.g. broken limb) or while waiting for treatment (e.g. cataracts), or people may be temporarily unable to use particular functions (e.g. their eyes or hands may be busy, they may be in a noisy environment). Therefore, a design should be flexible and enable alternative methods of interaction. Relevant accessibility guidelines should inform the design process from an early stage. A specification that clearly sets out identified accessibility requirements will make it easier to assess whether design decisions are meeting those requirements.
Another important consideration at the specification stage is which development environment or language to use. The selection of a particular development environment may have accessibility implications, as some web development and programming tools have better support for accessibility than others. For example, a resource developed in HTML would be relatively easy to make accessible, whereas one developed in Java or Flash would be more difficult because the process is more complex. Similarly, the programming or authoring tools used to develop a resource may or may not have advice or support for the developer in making the resource accessible.
Technical and usable accessibility
An online resource needs to be usable for disabled users as well as accessible. Lawton Henry (2002) makes the distinction between ‘technical accessibility’ and ‘usable accessibility’. We will illustrate this distinction with two examples.
-
In a web-based example, a blind user listening to a screen reader may technically be able to access the data presented in a table, i.e. the screen reader may be able to read the content of each cell in the table. But the user also needs to be able to navigate between, and read, the cells in a meaningful and useful way. This may mean the user needs to access contextual information about the cells, perhaps by relating the data cells to their associated column or row headers.
-
In an interactive software example, a user who cannot operate a mouse needs to be able to operate all the interface buttons using the keyboard only. The software may be technically accessible if the user can utilise the tab key to move from button to button and press enter to operate the button. However, this would not be very usable if there were 10 buttons and the user needed to operate the buttons in any order, at any time, e.g. the third button followed by the ninth button. To accommodate usable accessibility the software could provide keyboard shortcuts to allow the user to operate the buttons in any order.
Key accessibility principles
Below are listed 10 principles for accessibility. These principles underpin many of the sets of accessibility guidelines available, which are referred to in ‘Design guidelines and their limitations’.
1. Keyboard operation: the ability to operate applications fully via the keyboard.
This means supporting the standard keyboard shortcuts available for the operating system, such as Alt+F4 to close a window of a Windows application, and F1 to open the Help file. It may also be useful to provide special shortcuts for the application, such as the space bar to toggle the ‘play’ and ‘pause’ buttons of a media player.
2. Compatibility with assistive technology, such as screen readers and text readers, screen magnifiers, voice input, switch input.
This may mean implementing the application for a widely used environment, such as Windows, Mac or UNIX, and adopting the accessibility standards of that Operating System (OS).
For screen magnifiers, this means providing text as pure text, rather than as images, so that the text is not distorted when it is magnified. It also means controlling the quality of pictures so that they do not distort when magnified.
3. Screen reader access: allowing interface objects and other content to be read by a screen reader, and to be read in a meaningful way.
This means providing appropriate text labels on all buttons, menus and menu items, icons, sliders, and all other interface objects. In order for these objects to be read in a meaningful way they need to be placed in a logical order, and the order needs to be consistent across different screens.
4. Descriptions of visual material may be required, depending on the application or the purpose of the content.
In an educational context a multimedia package should provide text descriptions of important visual information. For example, data shown in a graph or a photograph of a sculpture may need to be described. The need for a description depends very much on the purpose of the visual information, i.e. pictures used for decoration may not need to be described, but pictures that convey meaning may need to be described. See the OU ‘Guidelines for describing visual teaching material’.
5. Customisation: the ability to inherit operating system settings for colours/fonts, or the ability to customise display.
Inheritance of users’ settings: the ability of software to inherit operating system settings. Dyslexic and partially sighted people may make changes to the operating system display settings; e.g. making all text one colour and all backgrounds another colour. In practice, this means designers and developers should not override operating system settings with software settings. An alternative approach can be to provide users with a choice of fonts and colours to be used as the default settings. However, a drawback of the latter approach is that it is difficult to provide a range that accommodates the needs of all partially sighted or dyslexic users. It is, therefore, preferable to inherit the user's existing settings.
6. Control over audio output: the ability to adjust volume and tone and to link hearing aids to amplifiers, speakers or induction loop systems.
In practice this applies more to interactive devices located in public areas, such as libraries or shopping centres, where the relevant controls and connections need to be provided. For PC-based software this requirement will be met by the operating system and the user's own equipment.
7. Alternative to speech input: people who cannot speak may require an alternative to speech input facilities such as audioconferencing.
In practice this would probably mean the provision of text-based facilities in addition to the speech input.
8. Alternative to text output: deaf people who cannot read or write text because sign language is their primary language may require an alternative to text output or text entry.
In practice this might mean the provision of pictorial information as output or in a menu, or even the provision of a signing avatar (software that creates an animated sign language interpreter).
9. Alternative to colour: colour-blind people may require information that is conveyed through colour to be conveyed in another way.
In practice this may mean giving coloured objects text labels or differentiating their appearance in other ways. For example, if important information is presented in red, it could also be labelled as ‘important’ or highlighted in another way.
10. Clear, consistent design: This means using common navigation tools, such as menus, meaningful icons and so on, and applying them consistently throughout the site. This helps those using assistive technology and students with dyslexia.
Design guidelines and their limitations
Having considered accessibility requirements and principles in ‘Specifying accessibility’, we now take a closer look at the guidelines that are available to support the development of accessible resources. Guidelines are available from many different sources and cover a variety of environments, from software and educational technology to websites and consumer electronics. As a starting point, ‘Accessibility design guidelines’ on the Resources page at the end of this section lists some useful sources. We suggest you take the time to browse through it and visit some of the links.
Guidelines, however, should be used with care, and it is important that designers are aware of the limitations that have been identified in the literature. There is a body of literature describing the limitations of design guidelines: for example, Bastien and Scapin (1992); de Souza, Long and Bevan (1990); Mosier and Smith (1986); Tetzlaff and Schwartz (1991); Thovtrup and Nielsen (1991); and Colwell (2001). These authors have studied how design guidelines are used by user interface designers and found that designers have difficulty in selecting, interpreting, and applying guidelines. Some of these studies suggest ways of improving how guidelines are presented to developers, but few guideline producers are aware of this literature, let alone implement the recommendations.
Colwell's (2001) study of web accessibility guidelines found that student web developers needed more information about disability in general and information on how disabled people use the web, in particular, in order to effectively apply the advice provided by the guidelines. Paddison and Englefield (2004) further discuss the issues associated with the use of heuristics (another term used for guidelines) in evaluating the accessibility of websites.
Organisations or groups who want to convey users’ requirements for a particular product or service, such as an accessible website, often produce guidelines, as this appears to be a reasonable method for conveying requirements. However, the guidelines that are produced are often difficult to use because they are either too complex or too simplistic, or do not contain sufficient information about the needs of disabled people. This often results in the product or service not conforming to the guidelines, either partially or in full.
Despite the problems associated with the development and use of accessibility guidelines, they can still be a useful tool to give developers a basic understanding of the requirements of disabled users. See ‘Accessibility design guidelines’ on the Resources page at the end of this section for our list of accessibility guidelines for websites, software, and hardware.
