A Comparative Analysis of Guidelines for Access by Disabled People to Digital Information Systems: Some Proposals for Simplification

Inaugural Lecture given at City University, London

Date: 25/05/2005

Abstract: There are a wide variety of digital data accessibility and usability guidelines, some the product of research, others derived from foundational principles, which present designers with a plethora of requirements. This Paper takes six heterogenous sets of guidelines and proposes that their content can be distilled into three, high level principles which, if observed by designers, will meet most of the detailed requirements from which they were derived.

My favourite story about problems with accessing information tells of a huddle of Nobel Prize winning physicists who went to an international conference at York. They naturally wanted to see the Minster and so they picked up a map at reception and planned their campaign. Unfortunately their hotel was North of the city so they were forced to walk South using a North-oriented street map. Their first turning was 180 degrees incorrect and they ended up in the maze of a suburban housing estate. At the other extreme you can picture a very seriously disabled person, confined to a wheelchair but able to use a PC without any problems; so there isn't a simple correlation between being disabled and being unable to access digital information systems.

It might be useful to start, then, with saying a few words about disability and digital information systems. There are two major sources of disability definitions and they are

Epidemiological
Administrative

Source: humanITy

Epidemiological definitions focus on a medical condition (morbidity) with some observations about the ability of health and medical technologies to halt or reverse the syndrome. The whole paraphernalia is set out by the World Health Organisation (ref.1): Using this method, epidemiologists can count how much of something there is and what health and medicine have been able to do about it.

Administrative definitions are far more widespread and useful. Public administrations need to make rules about who is entitled to special benefits and they have to decide who are the legitimate objects of philanthropy. So, to take blindness and visual impairment as an example, the Government gives blind people a special income tax allowance and a concession on the broadcasting licence fee; so to do this it needs to decide who is actually blind. Equally, the Royal National Institute for the Blind (RNIB) has been given legal powers to provide special goods and services for blind people; so to do this there needs to be a definition so that it can define legitimate beneficiaries.

There is just one further complication; some countries use epidemiological classifications to solve their administrative definition problems but other countries use a loose, functional definition. Thus, to revert to the field of blindness, an epidemiologist would define blindness as follows:

A Simplified Definition of Blindness and Partial Sight

A person is blind if, after correction, vision in the better eye is 3/60 or less; or if the field of vision is 15 degrees or less.

A person is partially sighted if, after correction, vision in the better eye is 6/60 or less or if the field is substantially restricted.

Source: Carey simplification of ICIDH80 (ref.1)

By contrast, in the United Kingdom the definition of blindness is functional and somewhat circular, arising from the 1948 National Assistance Act (ref.2)

UK Functional Definition of Blindness and Partial Sight

A person is certified as blind if they are “so blind that they cannot do any work for which eyesight is essential”. (Less than 3/60 or a much contracted field of vision).

A person can be certified as partially sighted if they are “substantially and permanently handicapped by defective vision caused by congenital defect or illness or injury”. (6/60 or less or gross field defect).

Source: 1948 National Assistance Act (ref.2)

So the picture is not simple, not least because if you are thinking about access to information systems the epidemiological definition does not cover what happens inside 3 metres, so the functional definition is better.

You can see that if the same kind of framework is applied across the whole field of disability, you can arrive at some kind of number. Generally in the OECD, disability is said to affect about 10% of the population, most of it over the age of 60.

Looking now at the relationship between people and information systems, it is easy to see that there will always be problems in the interaction because neither the people nor the systems are perfect. Governments tend to adopt a very negative, anthropocentric approach which blames people for human/systems interaction failure; but I tend to go the other way, noting that many people who have problems with standard PC systems seem to find their way round the Sky EPG without any difficulties, even though it has data on hundreds of channels for seven days.

Nonetheless, it must be owned that disabled people have some very obvious problems with digital information systems. I can sum these up by showing you a matrix with clusters of disability along the horizontal axis and systems requirements along the vertical axis.

AIM 5.2

	General	Cognitive	Physical	Audio	Visual
Fitness	Cross platform and choice of user- interface Cross platform and user- interface auto adjustable Individual user- agents Constant saving Non- mechanical on/off Make “undo” non threatening So called “Sticky Keys” User interface compatible with hearing aids Earphone sockets Keyboard commands
Accessibility	Multimodal Install portable customer profiles Interface peripherals Return to default at any point Easy On-Off Freeze frame Symbol languages Voice-In			Variable: Volume, Pitch, Signing Richness and density of text- subtitling. Freeze frame Symbol languages	Variable: Font, Size, Contrast, Colour Speech out Audio sub-titling. Freeze frame Delete metadata
Apprehension	Determine: Lexicality, Status, Weight of Content; icon for humour/ irony Define/ separate /delete foreground/ background Select font/print size/ lexicography/ document length/précis Simple graphics Prospective/ retrospective précis Links to simplified further data Turn off proportional spacing and create unjustified right margin. Create humour icon.			Define/ separate foreground/ background sound	Précis for Speech output. Delete metadata ‘Alt’ tags Define/ separate/ delete foreground/ background
Transparency	XML Context sensitive search reporting	Remove background: Isolate, Mark, Drag key elements, Slow/stop frame delivery Create/ render simple source file		Remove background channel(s) Remove background.
Navigation	Show alternatives (special, alpha numeric and chronological) Maximum 9 elements in array. Key word searching Image mapping Menu trees Point Centred Orientation Flow chart Colour coded Voice-input with fuzzylogic See general Simple switching			Combine: Telephone Audio with Visual Screen.	Combine Telephone Audio with Visual Screen
Interaction	Differentiate between individual response, list and Background/ Notes	Simple instructions. Prefer tick box to write-in.	Prefer tick box to write-in. Differentiate commentary from options. Voice-in
Expression	Clearly mark welcome flag for comments	Intelligent spell checking/ parsing/ thesaurus Predictive Word- Processing Predictive voice-in		Text- messages	Voice-in / Voice-out

Source: humanITy (ref.3)

If, for example, you travel along the horizontal axis to Visual and down that column to Accessibility, you will see that the box contains a series of guidelines on information accessibility. The challenge is to fill in all the boxes and maintain them as technology evolves. (ref.3)

On the basis of this matrix, the needs of disabled people are so varied that it would not be surprising if they were to throw up a whole plethora of user requirements to be converted into standards and that is true; but let me start with this set of ranked guidelines from the National Cancer Institute (NCI) (ref.4):

Research-Based Web Design and Usability Guidelines

Set and state goals
Use an iterative design approach
Evaluate websites before and after making changes
Provide useful content
Display information in a directly usable format
Do not display unsolicited windows or graphics
Do not use colour alone to convey information
Design for common browsers
Create a positive first impression of your site
Ensure the homepage looks like a homepage

Source: National Cancer Institute, USA (ref.4)

I will return to these near the end of the lecture; but just look at them carefully for a moment. They are ranked in descending order of importance and only the seventh (shown in bold) "Do not use colour alone to convey information" has a disability implication; it relates to colour blindness. So before we ever get to catering for what might be the special needs of disabled people, we have a large number of general needs to take into account.

Here are another ten from Jacob Nielsen (ref.5), not ranked, none of which relate particularly to the special needs of disabled people:

Nielsen's Heuristics

Visibility of System Status
Match between system and real world
Follow real world conventions
User control and freedom
Support undo and re-do
Consistency and standards
Error prevention
Recognise not recall
Tailor frequent actions
Aesthetic minimalist design

Source: Jacob Nielsen (ref.5)

Now here is a mixed, ranked, table which arises from my personal experience rather than from quantitative or qualitative research (ref.6):

Carey's Top Ten

Define taxonomy
Use the (7 + or - 2) rule
Enable cursor establishment from the keyboard
Allow adjustability for print font, size etc for metadata as well as data
Only use tables, frames for the purpose for which they were designed
Allow exclusion of recurrent metadata
Don't describe what you can link
Balance aesthetics, purpose and end user requirements
Do not slavishly digitise paper content
Update or die.

Source: humanITy (ref.6)

In this table the factors which relate to disability are clustered together in bold (items 3-6) in the middle of the ranking. What this tells us is that my experience has been typical of all disabled people; sometimes the problem with an information source arises from general factors, sometimes from factors which relate to my disability. Indeed, some of the factors are critically inter-related. If you look at my top ranked guideline on taxonomy, for example, this is not so important if the third guideline on the ability to establish a cursor is observed. My serious problem arises when the inadequate taxonomy means that I cannot find something but I cannot overcome this by undertaking a key word search. So I am stuck. I will come back to this later.

Here is another hybrid table; it comes from the extensively researched, ranked, user requirement for a Government programme to supply a dedicated digital information system to those who have difficulty with or are alienated from current commercial digital information systems, particularly those on the Internet (ref.7)

MyGuide User Requirement

Basic Customisable Features
Radically Simple Interface
Cross Platform
Fit for Purpose
Variable Navigation
Ranking
Portable Profiles
Multi Modality
Reading Age
Voice In/Voice Out

Source: humanITy (ref.7)

Note that only three of the requirements, shown in bold - Basic customisable features; multi modality; and voice in/voice out - specifically relate to disability even though this was one of the key target areas for the project. Notice, too, the cross platform requirement third in the ranking. This requirement is unique to our six tables and I will return to it later.

Finally, I want to show you two tables which specifically refer to disability access to information systems. The first, from the Web Accessibility Initiative (ref.8), is a theoretical rather than a researched construct and it is not ranked:

WAI Quick Tips

Images & animations: Use the alt attribute to describe the function of each visual.
Image maps. Use the client-side map and text for hotspots.
Multimedia. Provide captioning and transcripts of audio, and descriptions of video.
Hypertext links. Use text that makes sense when read out of context. For example, avoid "click here."
Page organization. Use headings, lists, and consistent structure. Use CSS for layout and style where possible.
Graphs & charts. Summarize or use the longest attribute.
Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
Frames. Use the noframes element and meaningful titles.
Tables. Make line-by-line reading sensible. Summarize.
Check your work. Validate. Use tools, checklist, and guidelines at http://www.w3.org/TR/

Source: WAI (Web Accessibility Initiative) (ref.8)

To me this looks like a group of standards writers talking to themselves and, indeed, that is somewhat demonstrated by our final table which shows the results of research by Prof. Helen Petrie and colleagues at the Centre for HCI Design at City University into what really stops disabled people finding things and buying tickets; in other words, this is a table which looks at barriers to task completion (ref.9):

DRC Table 6.

Check Points accounting for most reported problems

Text equivalent;
Foreground/background;
Usable with scripts, applets etc;
Movement on pages;
Spawning windows;
Split blocks
Identify target of link'
Clear, simple language

Source: DRC (Disability Rights Commission) (ref.9)

Again, this is a mixed, unranked table but in this case the top three points, in bold, relate directly to disability.

When we come to analyse the tables in terms of features which might be likely to help different clusters of disabled people, we can see that the special provisions are relatively sparse.

The largest single cluster of disabled people are those with learning and cognitive disabilities. Here are relevant features from our six tables listed alphabetically:

Guidelines for Learning and Cognitive Disabilities

Carey - 7+ or -2 Rule
DRC - Clear, Simple Language
MyGuide – Voice In/Voice Out
NCI - Iterative Design Approach
Nielsen - Match Between System and Real World
Nielsen - Recognise Not Recall
WAI - ... Consistent Structure

Source: humanITy

Of course it could be argued that all these points apply to everyone and I will come back to this in a moment.

When it comes to the next two largest clusters of disability, physical disability and deafness and hearing impairment, there are few special guidelines. It could be argued that my own insistence on the (7+ or -2) rule would help those who use simple switching systems to access data. Voice In is also obviously valuable for people who cannot use a keyboard, numeric keypad or mouse.

In the case of deaf and hearing impaired people, the unwritten assumption in setting disability access standards for digital information systems is that the paradigmatic situation is a PC accessing text and static graphics. There are standards for subtitling television broadcasts and movies and these will be incorporated into general standards. The use of full length captions is assured because these will be used in key word searches for video clips. On this basis, and on the basis of legislation and regulations, deaf and hearing impaired people are being well served where this is needed; and there is little doubt that this service will transfer across to captioning audio on the Internet. This requirement is met in the MyGuide table under the heading of "Multi Modal".

Of the clusters of disability, the evidence from the DRC Survey shows that blind and visually impaired people have the biggest problem with the Internet (ref.9).

DRC Table 1: Task success rate by impairment group
Impairment Group	Tasks succeeded	Tasks failed
Blind	53%	47%
Partially sighted	76%	24%
Dyslexic	83%	17%
Physically impaired	85%	15%
Hearing impaired	85%	15%
All impairments	76%	24%

Source: Disability Rights Commission (DRC) (Ref.9)

Perhaps then it is not surprising that there are special provisions recommended in five out of six of our standards tables for blind and visually impair people; here are the points, again in alphabetical order:

Accessibility Guidelines for Blind and Visually Impaired People

Carey - Enable Establishment of Cursor
Carey - Adjustability Print, Font, Size
Carey - Allow Exclusion of Recurrent Metadata
DRC - Text Equivalent
DRC - Foreground/Background
DRC - Usable with Scripts, Aplets etc
MyGuide - Multi Modal
MyGuide – Voice Out
NCI - Do Not Use Colour Alone To Convey Information
WAI - Multimedia.

Source: humanITy

In summary, then, the actual requirements to meet the specific needs of disabled people in the area of digital information design are not very extensive:

Disability Access Key Points

Learning/Cognitive – Clarity, Simplicity, Voice Out
Physical - Enable selection through simple switches, Voice In
Deaf - Captions
Blind - Describe graphics, allow simplified access/customisation, Voice Out

Source: humanITy

I just want to make a brief point about this last line: "allow simplified access". The way to think about designing for blind people is to design for telephone access or access my motor vehicle users to your information system. If you are accessing a web site through a screen reader which reads a web page in synthetic speech, every time you change pages you have to listen to a massive amount of repeated information which usually appears at the top of the page but can also appear at the bottom with new data being the very meagre meat in a chunky sandwich.

In summary, then, disability requirements seem to boil down to

Simplified Disability Requirements

Enable simplicity and customisation
Create multi modally and enable multi modal interaction

Source: humanITy

Now I want to turn back to the general. Here is a summary list of the general standards contained in our six tables, boiled down to an absolute minimum so that anything that is a sub class of something else is eliminated. These factors are not ranked and I have used my own summary terminology to simplify the list:

General Design Rules

Consistency (NCI, Nielsen, WAI)
Fit For Purpose, optional simplicity/customisation (Carey, MyGuide, NCI, Nielsen)
Set/State Goals (NCI)
User Control (Nielsen)
User Evaluate (DRC, NCI)

Source: humanITy

We have now got ourselves down to two special principles for disability access and five basic general principles from our plethora of tables. Now let me integrate the two last tables into one, noting that optional simplicity and customisation appears in both so we end up with six points.

Combined Special and General Needs Guidelines

Consistency (NCI, Nielsen, WAI)
Fit For Purpose, optional simplicity/customisation (Carey, MyGuide, NCI, Nielsen)
Multi Modal (Carey, DRC, MyGuide, NCI, WAI)
Set/State Goals (NCI)
User Control (Nielsen)
User Evaluate (DRC, NCI)

Source: humanITy

I have transferred specific statements about captioning and description into multi modal and have absorbed the point about using switching systems and screen readers into the guideline on allowing simplicity.

Before turning to my conclusions, I want to remind you of the MyGuide requirement that information should be available on a cross platform basis. One problem for disabled people is the information producer’s specification of the user interface experience so that pages designed for the web are fine for a PC but don’t work on a mobile phone; or data designed for television doesn’t transfer easily to the web. I would therefore specify in any set of disability access guidelines that within the digital information system the data and tools allow for automated migration between different user interfaces. This is important because different clusters of disabled people variously have problems with qwerty keyboards, tiny numeric keypads on mobile phones, large screens, small screens, the mouse etc. So, here again in summary are my three basic accessibility guidelines for access by disabled people to digital information systems:

Basic Accessibility Guidelines

Enable simplicity and customisation
Create multi modally and enable multi modal interaction
Enable channel and user interface choice

Source: humanITy

I want to use my remaining time to say a few words about these guidelines.

As far as I am concerned the key concept in providing anything to anyone is that it should be fit for purpose. In digital information terms this generally means defining your audience and what you want it to do. This is why the DRC research (ref. 9) was particularly important because it was based on task completion rather than on theoretical concepts. If you are designing a web site to sell concert tickets and nobody can buy them, it doesn't matter how pretty it is. If you design an electronic programme guide and people cannot find the programmes they want, then it doesn't matter how simple and elegant the design is.

So the starting point has nothing to do with manuals of standards; the starting point is to think of the audience. Too often design decisions are dominated by aesthetics rather than end use; and too often the design is inadequately inter sectoral. Having said that, the Internet sector of digital design geeks who have fallen into art class would do well to learn some basic lessons from broadcasting.

Secondly, you need to check whether your own definition of audience matches legislation and regulation. If you are establishing a web site dedicated to the wholesale supply of hammers there are very different requirements from those which apply to a public broadcaster. So in addition to your market requirement for your information to be universally accessible, you may have a legislative requirement.

Thirdly, you need to test your system against market use which is covered under our User Evaluation point. Most organisations, if they test at all, use their own technophiles which is a poor reflection of their market. Having got this far, state your goals; people want to know when they enter an information environment whether they are to be informed or entertained, charged or given free service.

The most important element in fitness for purpose is devolving power to the user. You provide a clear, consistent house style but you should then allow users to take control of their information environment to the maximum extent possible. This is enshrined in our principle of allowing simplicity and customisation. Note, I am not legislating for simplicity rather than complexity; but there are people, like those with learning difficulties, who need simplicity, and those, like blind people, who want to set their own level of simplicity or complexity depending on their user interface experience. If fitness for purpose is taken seriously it is clear that putting users into the straight jacket of the designer's aesthetic is useless. If the designer of a retail site happens to like 10-point red print on a green background using proportionate spacing and a justified right hand margin and she binds the data so that it cannot be alternatively rendered then she is shutting out those who are, respectively, colour blind, those who cannot read small print and those who are much happier with an unjustified right hand margin; down go sales. If the same techniques are used to make an artistic statement which the artist does not want to be altered that is quite another matter.

This brings me to one area of design where there are unavoidable costs and that is meeting the requirement for multi modality. Captioning audio for deaf people does cost money but in broadcasting it's required; audio description of broadcasting for blind people is expensive but it is also a legal requirement. The description of graphics on the Internet may or may not be a legal requirement. It is part of the basic WAI Guidelines which have been accepted by the UK Government and which form part of its regulatory framework for operating the Disability Discrimination Act (DDA, 1995) (ref.10) but we still await a good test case.

In thinking about description, however, there are three simple points:

Describing Graphics

Most graphics have captions
Captions are useful in telephone access
Many graphics have authored descriptions

Source: humanITy

There is, then, some cost involved in audio description but the combination of legislative requirements and the potential of telephone and motor vehicle access mean that there is a necessity and a virtue in looking carefully at description as part of your multi modality package.

The last element of any package should be the considered use of text and graphics as explicit alternatives. The idea that blind people want text only sites is bogus as is the idea that people with learning difficulties only want pictures; what both clusters of people need is the sovereignty to mix and match.

Here, then, is a brief table of the procedures I have just described:

Information System Design Procedure

Market Analysis
Legislative Analysis
Integrate Multi Modality
User Evaluation
State Goals
Allow Maximum User Control

Source: humanITy

What I hope I have achieved is to take a massive volume of complex evidence and boiled it down to three simple requirements to enable disabled people to access digital information systems. We know that the current plethora of well intentioned advice gives information designers indigestion, particularly as most of them work to highly demanding deadlines. There is no doubt that if these three guidelines are complied with, supported by genuine user testing, some disabled people will fall through the net but at the moment the current complexity of requirements mean that very few disabled people are caught in the net. It is my hope that with a simplified set of requirements compliance will rise.

Full References

World Health Organisation: International Classification of Impairments, Disabilities and Handicaps (ICIDH-80), WHO, Geneva, 1980 http://www.who.int/enn/
United Kingdom Parliament: National Assistance Act 1948, HMSO, London, 1948 in: Tate, Rosemary et al: The Prevalence of Visual Impairment in the UK: A Review of the Literature, RNIB, London, in press.
Carey, Kevin & Gracia-Luque, Rosario: Accessible Information Matrix (AIM) Version 5.2 humanITy
National Cancer Institute (USA): Research-based Web Design and Usability Guidelines, Washington DC 2003 http://www.usability.gov/guidelines/
Nielsen, Jacob: Nielsen’s Heuristics: Heuristic Guidelines for Expert Critique of a Website (Appendix) http://irm.cit.nih.gov/itmra/weptest/app_a3.htmm
Carey, Kevin: Carey’s Top Ten in: Carey, Kevin: My Dream of an Accessible Web Culture for Disabled People, Leicester, 2004 (on request)
Carey, Kevin: My Guide User Requirements in: Carey, Kevin: MyGuide Paper: Estimated Feasibility of User Requirements, humanITy, 2005 for DfES/UFI (on request)
World Wide Web Consortium: Quick Tips to make Accessible Web Sites from: Web Accessibility Initiative (WAI): Web Content Accessibility Guidelines WCAG (Version 1.0, 2001, http://www.w3.org/WAI
Disability Rights Commission (DRC): The Web: Access and Inclusion for Disabled People: A Formal Investigation conducted by the Disability Rights Commission, TSO, London, 2004 http://www.drc-gb.org/publicationsandreports/report.asp
United Kingdom Parliament: Disability Discrimination Act 1995, HMSO, London, 1995 http://www.hmso.gov.uk/acts/acts1995/1995050.htm

Return to Accessibility Criteria

A Comparative Analysis of Guidelines for Access by Disabled People to Digital Information Systems: Some Proposals for Simplification

Related Files

Article

Full References