8.3 Accessibility Requirement Pattern

8.3 Accessibility Requirement Pattern

Basic Details

Related patterns:	Refer-to-requirements, user authentication
Anticipated frequency:	Zero to eight requirements
Pattern classifications:	Functional: No; Pervasive: Maybe

Applicability

Use the accessibility requirement pattern to specify the extent to which the system (or part of it) must be accessible by people with a certain kind of disability or other specific need-that is, how convenient it must be for them to use. This requirement pattern takes such a broad view of "specific needs" that some apply to everyone, and it thus covers those aspects of usability (general user-friendliness) that are amenable to being defined in requirements.

Discussion

Accessibility is generally taken to mean providing access for people who have disabilities of various kinds and degrees of severity (ranging, for example, from color blindness through low vision to blindness). That's certainly the motivation for accessibility legislation and standards. The people affected are often regarded by businesses and by builders of systems as a small minority who can be safely ignored. But people who can benefit from accessibility features in systems constitute fully 60 percent of adults of working age (according to studies cited at the end of the "Example(s)" section later in this pattern). And taking steps to help those who have difficulties or impairments can make such a difference to them that they deserve consideration out of proportion to their numbers. Providing accessibility for those who need it also improves usability for everyone. So this requirement pattern talks in terms of "specific needs" and takes an open and inclusive view of who has them. They go beyond people with disabilities to embrace people who aren't computer literate; people who lack linguistic skills (such as people with cognitive difficulties or speakers of English as a second language); people who could suffer eye, hand, or brain strain when using the system; people who have never used the system before; or people who are experienced "power users" of the system. In short, accessibility embraces everybody in one way or another. This is a novel way of looking at some of these situations.

When discussing disabilities, terminology is a very sensitive issue. It is easy to sound demeaning or patronizing even without realizing it. Terms for a particular disability, or for the subject in general, often acquire negative associations and new terms are then introduced. This book even introduces the term "specific need" to avoid the more common "special need," which is itself beginning to be regarded as condescending. When writing about this subject, take care to treat every group of people with respect.

The poor accessibility of the vast majority of systems is a powerful sign that there isn't a strong enough business case for doing better. Another factor is low awareness of the need for systems to be accessible-which means the case for accessibility isn't being made as well as it might, a situation that better requirements specifications can help remedy. There are several sound arguments for a business to make a system more accessible: (1) a law says you must; (2) it will attract more customers; (3) fewer people will raise customer service issues; (4) it will make employees more productive. Not all apply to every system. Getting management support can be a hard sell, and even then resources for accessibility might be the first to be cut when development is under pressure. Merely helping people isn't a motivation for a hard-nosed business-though I suspect it's likely to motivate developers more than any of these business reasons will, which is important because it will give them more interest in doing a good job.

There is no usability requirement pattern in this book: it is deemed not to deserve one. That's partly because our broad treatment of accessibility covers many aspects of usability, and partly because attempts at guaranteeing usability via requirements fail miserably. A couple of sensible steps are covered in the "Usability" subsection of the "Extra Requirements" section of this pattern, along with more on the drawbacks of usability requirements.

All accessibility-related requirements apply both to the software we develop and to the technology we use-most importantly, to third-party products that deliver parts of our user interface. If you specify requirements for any infrastructure that the system needs, include a requirement (as per the refer-to-requirements requirement pattern in Chapter 5, "Fundamental Requirement Patterns") that states that all our accessibility requirements apply to it, too. We can also ask that more fundamental technology (especially the operating system and Web browsers) offer accessibility features that help satisfy our accessibility goals (or, at least, don't render them unachievable).

Accessibility-related requirements can be specified at three levels:

• Level 1: A law or standard that must be adhered to Use the comply-with-standard requirement pattern for this. It is your responsibility to find out which laws apply to your system. Bear in mind that laws and regulations are liable to change.

  If you're under no obligation to satisfy a law or standard, you can ignore level 1 without ill effect. Don't write a requirement of this kind just for the sake of it.

• Level 2: A type of specific need the system must satisfy, and the extent to which the need must be satisfied This is what an accessibility requirement is for, as described in the content explanation at the end of this section and covered in the "Template(s)" and "Example(s)" sections later in this pattern. Requirements at this level have the major benefit of making readers aware of the people we're aiming to assist; requirements at levels 1 and 3 can be abstract, and their benefits can be harder for some readers to discern.

• Level 3: Detailed features we want the system to have in order to satisfy the specific needs These are expressed in terms that developers can easily digest and that testers can test. They are covered in the "Extra Requirements" section of this pattern.

The second level is a more detailed picture of the implications of the first level, as the third level is of the second. You can therefore write as informal material (rather than requirements) any level that's spelled out in more detail. It saves everyone's time and avoids contention between the levels. For example, testers don't have to worry how to test against a type of specific need if all its implications are covered in specific requirements. Nevertheless, if a system must comply with a particular law, that, too, is a concrete requirement and should be presented as such-though you can indicate that it doesn't need to be tested in detail because its implications have their own requirements.

If a law has detailed stipulations, represent them at Level 3. You could therefore omit Level 2, but I suggest this equates to satisfying the letter of the law and ignoring its spirit. To me, Level 2 is important because it's the one concerned with the people we're trying to assist and thus motivates developers more than requirements whose purpose is less obvious.

Here are a few representative Level 1 requirements:

Open table as spreadsheet

Summary	Definition
Section 508 of Rehabilitation Act	The system shall be accessible to people with disabilities in accordance with Section 508 of the U.S. Rehabilitation Act, as amended, 1998-commonly referred to simply as "Section 508." (Section 508 applies to all systems and Web sites developed, purchased, or run by any U.S. Federal government agency, though there are certain exceptions.) Source: http://www.section508.gov
Americans with Disabilities Act	The system shall be accessible to people with disabilities in accordance with the Americans with Disabilities Act, 1990. Source: http://www.usdoj.gov/crt/ada/statute.html
U.K. Disability Discrimination Act	The system shall be accessible to people with disabilities in accordance with the U.K. Disability Discrimination Act, 1995. Source: http://www.opsi.gov.uk/acts/acts1995/1995050.htm
Web content accessibility guidelines	All Web pages displayed by the system (including all static pages of documentation) shall comply with the Web Content Accessibility Guidelines, version 1.0, produced by the World Wide Web Consortium. Source: http://www.w3.org/TR/WAI-WEBCONTENT

Observe that each of these examples cites the year that the applicable law was enacted, or a version of a standard, to make it clear the system won't automatically be aware of subsequent amendments (if there were to be any).

Whenever we break down a requirement into lower level requirements that represent its implications, we want a systematic way to do it-to give us confidence that we haven't missed something. So how can we go about finding the kinds of specific needs we want to deal with? For this purpose-and stepping away from our gentle concern for people for a moment while still looking at a system from the user's point of view-we can treat a human being as a typical system with three main kinds of components: input, processing, and output:

1.	Input, via the senses-of which we only need to worry about the two appealed to by typical commercial systems.
	1.1.	Vision, relating to information a system normally displays.
		1.1.1.	Color blind.
		1.1.2.	Difficulty or impairment.
		1.1.3.	Complete blindness.
		1.1.4.	Flashing screen could cause a seizure.
		1.1.5.	Liable to eye strain (that is, everyone who uses their eyes).
	1.2.	Hearing, relating to the playing of audio by a system.
		1.2.1.	Difficulty or impairment.
		1.2.2.	Complete deafness.
		1.2.3.	The user being in a loud environment in which sounds produced by their machine are hard to hear even with unimpaired hearing.
		1.2.4.	Sound not produced by the user's machine.
2.	Processing, performed by the user's brain-referred to as cognitive abilities. It means how easily a person interprets and understands the information that a computer system presents to them and how long it takes them to decide what their response will be. It doesn't equate to intelligence.
	2.1.	Difficulty comprehending information presented by a computer (for example, people with dyslexia).
	2.2.	Slow to make decisions.
	2.3.	Limited knowledge of the language in which the system is presented. This might include speakers of English as a second language (if English is the language of the system) and children.
	2.4.	Not computer literate.
	2.5.	Unfamiliar with the system.
	2.6.	Power user-someone who knows the system very well and doesn't want to be slowed down by being told things they already know (including prompts for individual fields).
3.	Output, which means how you tell a computer what you want it to do. Systems normally rely on a user signaling their intentions by using one or more devices operated by the hands, typically a keyboard and mouse in combination.
	3.1.	Limited manual dexterity, or pain while moving the hands.
	3.2.	Being able to use one hand only.
	3.3.	Unable to use hands at all.
	3.4.	Liable to repetitive strain injury, such as carpal tunnel syndrome-which is a risk for everyone who uses their hands.
	3.5.	Being unable to communicate vocally (with speech).

Open table as spreadsheet

We're interested in disabilities here only to the extent that they create distinctions that affect the steps that a system must take to assist. As a result, these categories are inexact and a little arbitrary. For example, a user might be slow to respond because of dexterity difficulties rather than because they're slow to make decisions. But if one response is for the system to give users as much time as they need, the reason is immaterial.

Some people with specific needs can only use computers with the aid of specialized devices and/or software products-called assistive technology-of which there's a wide and growing range, designed to help in diverse ways. We don't need to discuss them here, though analysts and developers concerned with accessibility will benefit from an understanding of the most significant types. (Information about types of assistive technology, products, and manufacturers can be found at http://www.microsoft.com/enable/at.) One of the most important aspects of making a system accessible is allowing assistive technology to work effectively. Anyone who uses assistive technology relies upon a chain of support that utilizes special features of the operating system, Web browser, and more. It would be a shame if that chain broke because the last link was an HTML page, from your system, that was written in a careless manner.

The first step in making a system accessible is awareness. Analysts, in particular, need to understand the issues in order to write good accessibility requirements. A company then needs to create accessibility-related guidelines and/or standards that suit its way of developing systems. Much of this requirement pattern is written as if achieving accessibility is an overhead, but if it becomes second nature, that overhead is significantly reduced. When software and other elements of the user interface are built with accessibility in mind from the outset, less extra work is needed.

Content

An accessibility requirement should contain the following.

1. Type of specific need Each requirement must cover a range of needs of a particular kind, because it's impractical to write a requirement for each individual possibility. The best course is to write a separate requirement for each range that places its own distinct demands on the system. For example, the needs of a person with color blindness differ from those of someone with low vision, and the needs of a blind person are very different again. Having one requirement spanning all visual disabilities isn't helpful to developers or testers. Go into as much detail as it takes to make the range of specific needs clear.

2. Which part(s) of the system must be accessible If you mean the whole system, say so. It is possible (but not desirable) to make some parts of the system accessible and in others take no steps towards accessibility, or to assign different priorities to the accessibility of different parts (for example, to prioritize the public parts used by customers above internal functions used by employees).

   In an ideal world, all parts of a system would be fully accessible from the start. But in practice, a company with a limited budget could be forced to make compromises. The trend towards tougher accessibility laws would leave such a company with fewer options for compromise.

3. The extent of support How convenient should use of the system be for a person with this need? To what lengths are we prepared to go to make the system easier for them to use?

4. Estimated percentage of users affected (If applicable and known.) This can bring home to readers of the requirement that accessibility isn't just for a tiny number of people. Having this information also enables us to determine how many will benefit from improvements in this area and helps us concentrate on features of greatest benefit to the most people.

5. The clause in a law or standard to which this requirement pertains (If relevant.) It's better to say "pertains" rather than "satisfies" because a requirement at this level is too broad to be so categorical and warrants the writing of detailed requirements for the individual implications.

Separating accessibility into several Level 2 requirements allows those areas with the greatest impact to be prioritized higher if we don't have the resources to make the whole system fully accessible from the start. It might seem harsh to postpone accessibility for one class of users (say, employees), but if we have a thousand times as many customers as employees using the system and the organization can't afford to implement all accessibility requirements right away, it maximizes the benefit. On the other hand, if a law says our system must be accessible to employees, but the law doesn't apply to customers, we'd probably do the reverse. But again, legislative changes might impose higher accessibility demands throughout the system.

Template(s)

Open table as spreadsheet

Summary	Definition
Accessible by people with specific «Specific need name» needs	The «System part» shall be accessible by people with specific «Specific need description» needs [to the extent that «Extent of support»]. [An estimated «Percentage affected»% of users are likely to benefit.] [This pertains to «Clause in law».]

This summary format is a little long-winded, but that's to make it clear that the purpose of such requirements is to benefit real people; a more concise "«Specific need name» accessibility" sounds too impersonal to me.

Example(s)

Open table as spreadsheet

Summary	Definition
Accessible by people with specific vision needs	The system shall be accessible by people with specific vision needs, to the extent that a user shall be able to: Display the whole user interface in a large font without truncating displayed text or other values. Use a screen magnifier (to magnify a selected part of the screen). Use a screen reader (to read aloud information displayed). An estimated 27% of working age adults have a vision difficulty or impairment (16% mild and 11% severe). This pertains to §1194.31 (a) and (b) in Section 508.
Accessible by color blind people	The system shall be accessible by people who are color blind, to the extent that they shall be able to discern all text and other information displayed by the system as easily as a person without color blindness. Any meaning conveyed through the use of color shall also be conveyed by other means discernable by a color blind person. An estimated 9% of men and 0.5% of women are color blind.
Prolonged use without eye strain	The system's user interface shall avoid visual constructs that are apt to cause eye strain after several hours of continuous use. Such constructs include flashing visual objects, low contrast between adjacent objects (such as text and its background), and bright colors.
Accessible by people who are hard of hearing	The system shall be accessible by people with special hearing needs, people in a loud environment that precludes their hearing sounds made by the computer, or people whose computer has no sound capability or has sound switched off. An estimated 21% of working-age adults have a hearing difficulty or impairment (19% mild and 3% severe). This pertains to §1194.31 (c) and (d) in Section 508.
Accessible by people with specific cognitive needs	The system shall be accessible by people with specific cognitive needs, including people with limited ability to read and write English, to the extent that the system shall Phrase all instructions clearly. Use terminology consistently. Avoid obscure words where there are more commonly-used alternatives. Provide context-sensitive help for all input-capable user interface components (such as buttons and entry fields). An estimated 20% of working age adults have a cognitive difficulty or impairment.
Accessible by people with specific dexterity needs	The system shall be accessible by people with specific manual dexterity needs, to the extent that it is fully usable by a user who lacks fine motor control, is unable to perform multiple physical actions simultaneously, or has limited reach or physical strength. An estimated 26% of working age adults have a manual dexterity difficulty or impairment (19% mild and 7% severe). This pertains to §1194.31 (f) in Section 508.
Prolonged use without hand strain	Any operation that a user is likely to perform many times in succession over a prolonged period shall not involve awkward movement of the hands or fingers and shall not expect the user to perform many actions (such as key presses) in a short time. Having to press two or more keyboard keys simultaneously is deemed to constitute an awkward movement.
Accessible without voice	A user shall be able to perform all functions of the system without using their voice. This pertains to §1194.31 (e) in Section 508.
Accessible by novice users	A person with basic computer literacy shall be able to figure out how to use every function in the system. It shall be possible to access any online help needed to achieve this shall be directly from any function for which it is needed. For the purpose of this requirement, "basic computer literacy" means being comfortable using a personal computer and common desktop applications.
Convenient for power user employees	Any function used repeatedly and often, by any employee, shall be performable with a minimum of steps (including a minimum of keystrokes and/or mouse actions), and shall not delay that user by displaying instructions they already know.

The specific need percentages cited in the preceding examples come from the following two research studies conducted by Forrester Research, Inc. on behalf of Microsoft Corporation:

• "The Market for Accessible Technology-The Wide Range of Abilities and Its Impact on Computer Use," 2003, freely available from http://www.microsoft.com/enable/research/phase1.aspx

• "Accessible Technology in Computing-Examining Awareness, Use, and Future Potential," 2004, freely available from http://www.microsoft.com/enable/research/phase2.aspx

Extra Requirements

The bulk of the requirements in this section are for features that contribute to satisfying one or more accessibility requirements; that is, they are requirements at Level 3 as described in the "Content" section earlier in this pattern. They are divided into the topics that follow, and each is dealt with in its own subsection that follows. ("Specific need steps," however, has a separate subsection for each of four types of specific need.)

1. General accessibility Define steps to take that aren't limited to just one kind of specific need, and define accessibility etiquette to prevent our system from getting in the way of any kind of assistive technology.

2. Specific need steps Specify detailed requirements for the types of specific need identified in the example "Discussion" section: vision, sound, cognition, and dexterity. (Speech, however, is not dealt with, because few commercial systems depend on voice input.) Note that user preferences and tailoring for all kinds of specific needs are covered in the next topic.

3. Tailoring to an individual user Provide ways for an individual to adjust our system's user interface according to their user preferences.

4. Documentation and support Make documentation accessible to people with specific needs, and give them access to further assistance (including customer service).

5. Certifying compliance Describe the extent to which the system complies with an applicable law.

6. Usability

This section doesn't pretend to satisfy all the provisions of any particular accessibility law but uses the provisions of Section 508 of the U.S. Rehabilitation Act as its starting point, because that's the most prominent such law and the one whose stipulations go into the greatest detail (at the time of writing). This section addresses all the main demands as they apply to the software of a system. But this section isn't comprehensive: it ignores other clauses that don't affect typical commercial systems, such as the captioning of instructional videos, special environments (for instance, user interaction via a telephone), or embedded systems. Check what's relevant to your system, and write requirements on any additional topics that apply to it. The underlying principle is that everything that you present to your users should be accessible. Any requirement relating to a law or standard should identify which clause (and which law or standard) it satisfies or contributes to satisfying. If you're building a system for multiple jurisdictions, you might need to mention more than one law.

Many of the examples that follow contain a statement that they are "intended to satisfy" particular clauses of Section 508. These are indicative only; they represent only my (non-legal) opinion. When you specify real requirements yourself, however, you should make stronger statements: write that they are "deemed to satisfy" or that they "satisfy" the relevant clauses. But if you do so, you must verify thoroughly that each requirement does achieve what it claims. Whenever a system must comply with a law, the steps needed to achieve compliance must be identified, identified as early as possible, and seen by the widest possible audience. To achieve those goals, the requirements are the place to identify the steps, and the place to state categorically that you believe that each requirement is sufficient to satisfy the part of the law to which it relates.

All the examples that follow are, as all requirements should be, as technology-independent as possible. Even those stipulations of Section 508 that are specifically for HTML are expressed here in general terms. This section uses the term presentation unit to mean a self-contained set of information that is intended to be displayed together, such as an HTML page. However, where relevant, each example explains the implications when HTML is indeed the medium. Some technologies contain features that make it easier to implement accessibility, but this isn't the place to discuss them. If you're using a particular technology (say, a browser-based user interface), you can write requirements for specific ways in which it must be used to improve accessibility.

General Accessibility

In examples that are self-explanatory enough not to need further introduction, this section covers a few good practices and matters that apply to more than one kind of specific need.

Open table as spreadsheet

Summary	Definition
Don't interfere with accessibility features	The system shall not interfere in any way with features of the operating system or other products that are identified as serving accessibility purposes (assistive technology). This includes external devices that might be present solely for accessibility purposes. This is intended to satisfy §1194.21 (b) in Section 508.
Synchronized multimedia alternatives	The system shall provide a semantically equivalent alternative for the video and/or audio parts of any multimedia presentation or animation that shall be synchronized with the main presentation. One alternative might suffice for both media. It is also acceptable to present the content of the presentation in the form of static information. This generally means providing an alternative stream using a different medium (usually text and/or audio) that is synchronized to the main stream, to help people who have difficulty perceiving either video or audio. This is intended to satisfy §1194.21 (h) and §1194.22 (b) in Section 508.
Readable without style sheet	It shall be possible to fully perceive and understand a presentation unit without any additional resource that defines aspects of its presentation style (a "style sheet"). The intent of this requirement is to bar style sheets from containing semantic information, because assistive technology might be unable to extract that information. This is intended to satisfy §1194.22 (d) in Section 508.
Downloadable by people with specific needs	Whenever software is available for download to the user's machine, instructions for downloading and installing shall themselves comply with all accessibility requirements in this specification, and downloading shall not begin until instructed by the user. This is intended to satisfy §1194.22 (m) in Section 508.
Avoid duplicate command components	Any presentation unit that ordinarily contains multiple user interface components to initiate the same command shall provide some way to avoid duplication of components that have the same purpose (in particular, in the case of HTML, duplicate navigation links). The intent of this requirement is to avoid unnecessarily burdening users of assistive technology and users who have difficulty reading the screen. This is intended to satisfy §1194.22 (o) in Section 508.

The following are two alternative ways of approaching the matter of users having to respond in a given length of time. Avoid the first whenever you can, because it involves a more complex user interface for the user and the building of additional functionality.

Open table as spreadsheet

Summary	Definition
Control of timed responses	The user shall be informed whenever they are expected to respond within a fixed length of time and shall be given the opportunity to indicate that they need more time. This is intended to satisfy §1194.22 (p) in Section 508.
No timed responses	The system shall never expect the user to respond within a given fixed length of time. This does not preclude the system dealing with exceptionally slow responses in whatever manner is appropriate (for example, if the circumstances reflected in the original display no longer apply). This is intended to satisfy §1194.22 (p) in Section 508.

A related matter is screens that automatically refresh without the user asking:

Open table as spreadsheet

Summary	Definition
Auto-refresh control	For any screen that auto-refreshes (that is, redisplays itself) spontaneously, the user shall have the option to switch auto-refreshing off. If auto-refreshing occurs after a given length of time, the user shall be able to modify that time.

People with specific needs must be able to authenticate themselves when biometric means are in use (that is, when a uniquely distinctive body part, such as a fingerprint, is used to identify the user). (See the user authentication requirement pattern in Chapter 11, "Access Control Requirement Patterns," for more.) The following example insists on that users who are unable to use a biometric reader must still be able to authenticate themselves:

Open table as spreadsheet

Summary	Definition
Biometric identification alternative	If a biometric form of user identification is used (for example, a fingerprint reader), any person shall be able to be identified by other means if they do not possess the requisite biological characteristics (which includes missing that body part or not being physically able to present it to the reader). This is intended to satisfy §1194.26 (c) in Section 508.

Specific Vision Needs

The vast bulk of information presented by commercial systems is designed to be visual, which is why this subsection has the most subjects for requirements. Many of them are intended to help assistive technology to present information in an alternative way, which is difficult enough at the best of times. Take a look at the source of an HTML page and try to pick out the bits that a user is interested in: for a rich page, it's not easy, even without the myriad tricks that page writers use to get just the right appearance. Or imagine explaining the contents of a Web page to someone who can't see it, when at the same time you can't see any of the graphics in it.

Let's start with the biggest single driver of assistive technology, which affects the building of every part of the user interface:

Open table as spreadsheet

Summary

Definition

User interface component semantics

Information about each user interface component shall be programmatically available, such that assistive technology can determine (and present to the user via other means) its type, state, content, and identity (name and description). When soliciting information from the user (via an "electronic form"), the semantic information shall be complete enough to allow the user to enter and submit data. When applied to an HTML page: A textual explanation shall be provided for every user-perceivable non-text element via "alt," "longdesc," or equivalent HTML attributes, or in element content. Each table column and row heading shall be a "th" HTML element. Each cell in a complex table shall be unambiguously associated with its column and row heading(s). Each frame shall have a textual title. This is intended to satisfy §1194.21 (d) and (l) and §1194.22 (a), (g), (h) and (i) in Section 508.

Don't be a nuisance when users with specific needs have less free screen space than other users:

Open table as spreadsheet

Summary

Definition

Screen and window sizes

The system shall not make assumptions about a user's screen size (number of pixels wide or high) or the size or position of any of the windows within which the system's user interface is displayed. The intent of this requirement is to accommodate users with specific needs who could have a screen with lower resolution than most users or who have to devote some of their screen "real estate" to assistive technology (such as an onscreen keyboard).

The following two examples relate to the screen focus. You might think that you needn't worry about screen focus matters because standard user interface technologies take care of this themselves, and to a large extent they do. For example, a browser displaying HTML pages can be expected to do so. But these requirements are still important as instructions to developers not to break them (if there are ways to do so-for example, using scripts embedded scripts in HTML pages). In addition, when choosing a user interface infrastructure, add these to the requirements that it must satisfy.

Open table as spreadsheet

Summary	Definition
Screen focus indicated	The user interface component that currently has focus (that is, will receive any input from the keyboard or equivalent device) shall be identified by a clear onscreen indication. This is intended to satisfy part of §1194.21 (c) in Section 508.
Screen focus programmatically exposed	The screen focus shall be programmatically exposed so that assistive technology can determine the current focus and be notified when focus changes. This is intended to satisfy part of §1194.21 (c) in Section 508.

If you have text to display, then display it as text; don't use graphics or anything else that assistive technology can't make sense of. Even attaching the text itself to an image of a piece of text is tedious to present non-visually.

Open table as spreadsheet

Summary	Definition
Display text naturally	Text shall be presented through text-specific user interface infrastructure operations, such that assistive technology can retrieve at least the text content, text input caret location, and presentation style attributes. This is intended to satisfy §1194.21 (f) in Section 508.

Here's a rule to insist on universally:

Open table as spreadsheet

Summary

Definition

Flashing frequency

Nothing presented visually by the system shall flash, blink, be perceivable as flashing or blinking, or cause the screen to flicker, at a frequency greater than two per second and lower than 55 per second. This includes text, blank areas of color, video, and animations. The primary motivation of this requirement is to avoid triggering a seizure in a susceptible person (for example, someone at risk of an epileptic seizure). Secondarily, avoid irritating everyone else. This is intended to satisfy §1194.21 (k) and §1194.22 (j) in Section 508.

Now for a few rules on using color responsibly:

Open table as spreadsheet

Summary	Definition
User colors never overridden	The system shall not override any user-selected color, color contrast level, or other display-related attribute. This is intended to satisfy §1194.21 (g) in Section 508.
Information never via color only	Color coding shall never be the only means of conveying any information, indicating an action, prompting a response, or distinguishing a visual element. That is, if all color were removed, the system could be used equally as well. When applied to HTML, each page shall be designed so that all information conveyed with color is also conveyed in another way that does not depend on color (for example, using context or some other form of markup). This is intended to satisfy §1194.21 (i) and §1194.22 (c) in Section 508.
Choice of colors	Whenever a user is permitted to adjust color and contrast settings, a variety of color selections, representing a range of contrast levels, shall be provided. Note that some people cannot see white text on a black background, and others cannot tolerate a white or bright background and must have a black or dark background. This is intended to satisfy §1194.21 (j) in Section 508.

Presenting an image to a user and inviting them to interact with it is impossible in most cases if the user can't see it. Section 508 focuses on a specific case for which special provision can be made: what are called "image maps," where clicking on a nominated region initiates an action associated with that region. Situations where a user is asked to point to a position on the screen (such as on a geographical map or when using a graphics editor) are monumentally hard to present non-visually; either avoid them altogether, or recognize that this part of your system is not accessible. Here are a couple of alternatives to choose from:

Open table as spreadsheet

Summary	Definition
Image interaction alternatives	Whenever a user is asked to select from a range of discrete options by selecting a location in a graphical area (in an image, typically), there shall be an alternative, non-graphical method of presenting the same options and letting the user select one. This is intended to satisfy §1194.22 (e) and (f) in Section 508.
No interaction with graphics	The system shall not ask a user to select from a range of discrete options by selecting a location in a graphical area (such as an image). This is intended to satisfy §1194.22 (e) and (f) in Section 508.

Whenever software dynamically generates what the user sees (as in a script embedded in an HTML page), assistive technology might not be able to keep track of what's going on-so neither will the user. A script is generally either purely cosmetic (to make the display prettier) or it does some real processing. In the first case, we can ask for a non-script textual alternative for users with a visual disability or impairment-most of whom won't benefit from the extra prettiness. It's unreasonable to ask for a non-script alternative in the second case, because that means duplicating the functionality; it's better to demand that the script use standard user interface components that accessible technology can detect and interact with. These complementary approaches are reflected in the following two requirements:

Open table as spreadsheet

Summary	Definition
Text equivalent of cosmetic script	Any presentation unit that contains its own software to display content to the user (such as a script or applet in an HTML page) shall contain explanatory text, associated with the software, that conveys the same information. This is intended to partially satisfy §1194.21 (l) in Section 508.
Scripts to use only standard user interface components	Any presentation unit that contains its own software to display content (such as a script or applet in an HTML page) shall cause only standard user interface components to be used to display information and to accept input from the user. This is intended to partially satisfy §1194.21 (l) in Section 508.

Specific Sound Needs

Sound is very much a secondary output medium in most systems, especially commercial systems (except for sound produced by assistive technology such as screen readers). Making a system convenient for a person with hearing difficulties to use should therefore be easy enough. But bear in mind that removing sound outputs altogether can cause difficulties for other users (particularly those with visual impairments). Here are two alternative ways to deal with the use of sound for alerting the user:

Open table as spreadsheet

Summary	Definition
Visual cue for audio alert	Whenever a sound is played for the purpose of alerting the user, a visual cue shall also be invoked. This is intended to satisfy §1194.22 (b) in Section 508.
No sound alerts	Sounds shall not be used for the purpose of alerting the user. This is intended to satisfy §1194.22 (b) in Section 508.

And here's one other method that gives users some control over sound:

Open table as spreadsheet

Summary	Definition
Sound volume adjustable	Whenever sound is played, it shall be possible to adjust the volume.

Specific Cognition Needs

Our aim here is to make the system easier to understand. It's hard to demand this in requirements, because the most important aspects are subjective-such as to write all text in clear language (mentioned in the equivalent Level 2 requirement in the "Example(s)" section). Section 508 makes one narrow demand:

Open table as spreadsheet

Summary	Definition
Consistent icon meaning	Any image used to identify a control, status indicator, or other programmatic element shall be used to mean the same thing wherever it is used. This is intended to satisfy §1194.21 (e) in Section 508.

One further aspect is covered in the preceding "General Accessibility" section: giving users all the time they need to respond.

Specific Dexterity Needs

Manual dexterity is relevant to us only as far as it relates to instructing the computer to do something. The contemporary devices of choice are a keyboard and a pointing device (typically a mouse). It's reasonable to assume that control over any assistive technology used to perceive computer output can be achieved using the keyboard, mouse, or a means built into the technology. Requirements need not be concerned with how assistive technology might achieve this (though analysts, developers, and testers would benefit from knowing). Here's a requirement to make input easier for some:

Open table as spreadsheet

Summary	Definition
Keyboard only	It shall be possible to perform all input to the system (including all navigation and initiation of operations) by using the keyboard alone. An exception is granted for purely graphical operations in situations where using the keyboard is inherently impractical. This is intended to satisfy §1194.21 (a) in Section 508.

Tailoring to an Individual User

There are three ways to make a screen in a system accessible to users with specific needs:

1. Incorporate accessibility into the definition of the screen directly. Technology like HTML has many accessibility features, and systems should be developed to take advantage of them. Proper use of common user interface elements lets assistive technology do its job. But even so, this approach can involve compromises: the sheer size and complexity of many pages detract from their accessibility. So it's a laudable approach, but not always enough.

2. Create a second, accessible version. Sometimes an organization wants to include in a system's user interface features that are not accessible (say, scripts to display fancy animated menus). That's fine, according to Section 508, so long as an alternative is provided that is accessible. Of course this means that you have to maintain two implementations on an ongoing basis, and you have the headache of checking that they're consistent

3. Tailor it to suit each individual user. A library might have a big set of conventional books and another (inevitably smaller) set of Braille books for the blind, but a software system can be much smarter than that. Why not transform each page dynamically to suit each individual user? It's perfectly possible if we care to take the trouble. Almost all commercial Web-based systems already perform dynamic generation of output for many other purposes, so it's not a big step.

These three approaches are not mutually exclusive. The first way should always be implemented to its fullest extent, even if the second and/or third ways are needed, too.

Tailoring our system for each user gives us much flexibility. There are two parts: providing a way for a user to specify their preferences, and then taking those preferences into account when presenting the user interface to them. For a Web-based system, we can create lean HTML pages devoid of any baggage that the current user doesn't want. Here are a few things for which we could beneficially define user preferences:

• Frames: yes, no, or don't care.

• Whether to duplicate command components (such as buttons and navigation links).

• Preferred location of command components: top, left, right, or bottom of screen.

• Colors. At least two preferences must be supported: background and foreground. Consider having the software check for and warn against incompatible or unreadable choices (such as choosing identical or similar colors for background and foreground).

• Font sizes and styles.

• Screen auto-refresh: yes, no, or don't care.

• Minimum time needed for a response.

Alternatively, for some of these factors, you can use values that are chosen by the user and recorded as operating system settings (such as system colors and fonts). This saves users the trouble of having to express their preferences more than once.

Be sensitive in what you ask users. Don't ask about disabilities directly. Each item in this list is a way in which the system can be tailored, and if you ask in these terms, people are unlikely to be offended. Offer an "I don't care," "no preference," or "no response" option if the question is a matter of any sensitivity at all. Also, never ask for preferences that aren't implemented; it can be very frustrating.

Just for completeness, here's a requirement for the option that Section 508 permits to offer an accessible alternative for each part of the user interface that isn't accessible:

Open table as spreadsheet

Summary	Definition
Text-only equivalent pages	For each presentation unit that does not comply with the accessibility requirements in this specification, there shall be an equivalent that does comply. The functionality of any such equivalent shall always be consistent with the original, even when changes are made. This is intended to satisfy §1194.22 (k) in Section 508.

Documentation and Support

There's no point in going to the trouble of making your system accessible if no one knows about it or no one knows how to take advantage of its accessibility features. More generally, users with specific needs should be able to obtain general assistance as well as anyone else. The following requirements convey these goals:

Open table as spreadsheet

Summary	Definition
All documentation accessible	All documentation available to users shall be available in a form that is itself readily accessible to users with specific needs. This is intended to satisfy §1194.41 (a) in Section 508.
Accessibility documentation	Descriptions of all accessibility-related features shall be available. Note that the previous requirement demands that this documentation is itself accessible. This is intended to satisfy §1194.41 (b) in Section 508.
Accessible customer service	All services provided to assist users (customer service) shall be accessible by users with specific needs. In particular, all support services available via the user's computer shall satisfy all the accessibility requirements in this specification. This is intended to satisfy §1194.41 (c) in Section 508.

Certifying Compliance

It isn't always enough for a system to comply with a law. Sometimes, you have to document how well it complies. In the case of Section 508, companies wishing to sell electronic and IT products to the U.S. government must fill in a Voluntary Product Accessibility Template (VPAT). It's handy to know in advance whether a document of this nature is expected, because parts of it can then be written while the system is being built. As examples, completed VPATs for Microsoft products can be found at http://www.microsoft.com/industry/government/section508.mspx.

Here's an example requirement:

Open table as spreadsheet

Summary	Definition
Complete a VPAT	A Voluntary Product Accessibility Template (VPAT) shall be completed for the system. The purpose of this is to describe how well the system satisfies Section 508 accessibility requirements, as a prerequisite to marketing the system to agencies of the U.S. government. Source: http://www.access-star.org/ITI-VPAT-v1.2.html

Usability

Usability is important, but it is a matter of good user interface design and not something that requirements can guarantee. No matter how hard the requirements might try, it's always possible to build an unfriendly system that satisfies them: there's no magic prescriptive way to prevent it. It depends on using good user interface designers and involving user representatives. Conducting usability studies with people with disabilities can also provide valuable insights on the practical usability of a system.

Usability requirements often ask for user interface characteristics that sound attractive, but which are define in such imprecise terms that they're meaningless to developers and testers. They ask for the user interface to be "easy to learn" or "intuitive," to have a "logical flow of input," to "use softly saturated colors," or to "group information by subject." They sometimes mandate particular user interface constructs-drag-and-drop, check boxes, drop-down lists, toolbars, for example-without indicating in what circumstances they should be used; these are all part of the design, and requirements have no business getting involved at this level. Leave the user interface designers and developers to pick the best user interface component and technique for each task. Unhelpful or unnecessarily constraining usability requirements do nothing but reduce developers' confidence in whoever specified them.

That leaves little for example usability requirements to say, but here are a couple of token efforts:

Open table as spreadsheet

Summary	Definition
Sensible default values	The system shall assign the most sensible default value to each input-capable field, wherever practical.
Common operations convenient	It shall be convenient for the user to initiate each common operation within a particular function. This shall be taken to mean a single keyboard operation or a very small number of mouse clicks and little mouse movement.

Considerations for Development

To do a good job developing accessibility capabilities, there are three areas that a software engineer should as a starting point have a working knowledge of:

1. The range of specific needs that computer users have This requirement pattern mentions the main categories, but it's only a start.

2. The accessibility features built into the operating system and other products and technology you're using (Such as Web browsers and HTML.) Popular operating systems come bundled with various accessibility utilities that many people (including developers) are unaware of, including an onscreen keyboard, screen magnifier, and screen reader. The underlying accessibility features of popular operating systems are also very extensive. Learn what they can do for you.

3. A few of the most important types of assistive technology and a rough idea how they work This can give you a feel for what you should do to allow these products to work properly-because you understand what you'd want if you were in their developers' shoes. For example, a screen reader for a blind person must interpret visually-oriented constructs (say, by looking at an HTML page, or-more tricky-by getting hold of the individual user interface components displayed by a desktop application), decide which bits the user's interested in, and then output its conclusions to a speech synthesizer. (If you want a challenging development job, here's a fertile field for you!)

Developing to help assistive technology, then, involves providing as much semantic information as possible-that is, to signal, as far as you can, the role and purpose of each item that you present on the user interface.

IBM's developer guidelines for accessibility-at http://www.ibm.com/able-contain implementation suggestions for popular technologies (including HTML, Java, Windows, and Unix). The guidelines themselves mirror Section 508 to a large extent.

Considerations for Testing

Before doing anything else, testers should gain an appreciation of accessibility issues and an understanding of all relevant laws and regulations (such as Section 508).

Some accessibility features are amenable to a certain degree of automated testing, and there are many available resources that can help you test the accessibility of a system. In fact, accessibility features built into the operating system itself and standard applications such as Web browsers can themselves drive automated testing. Get to know the tools that are most suitable. For a start, there are several (some of which are free) that analyze HTML pages and tell how accessible they are and how to improve them, including

• http://webxact.watchfire.com-a free service that judges the accessibility of any Web page

• http://zing.ncsl.nist.gov/WebTools-a range of "Web metrics" tools for testing usability and accessibility

In addition, some browsers allow you to see a text-only view of any Web page you visit.

Verify that user interface resources (such as HTML pages) adhere to guidelines and standards (for example, that they both use accessibility-friendly tags and do so in the correct manner). This is easier than testing the user interface's accessibility.

Try using the system with a few different types of assistive technology, both those built into the operating system (such as a screen magnifier and screen reader) and dedicated products. Use the system without the mouse for a day or two. Put yourself in the shoes of each type of user with specific needs. Ideally, involve people with disabilities in your testing; they will give you a better picture of your system's accessibility than anything else. Testing accessibility thoroughly is expensive and time-consuming.

One approach to putting yourself in various users' shoes is to invent a range of "personas." This is a concept that Alan Cooper describes in his book "The Inmates are Running the Asylum," 1999, and the idea is that you create a handful of fictitious people as realistically as you care to and then imagine how they would react when they use your system. In effect this takes the notion of "actors" one step further, so you create several personas for an actor. It's impractical to do this for more than one or two actors, so pick those that are the most important-say, a customer. Then devise a persona for each kind of specific need that you want to test, give them a name, a brief life history, and a personality: Chris is color-blind, Martine is hard-of-hearing, Nelson has one arm, Great-Uncle Augustus is computer illiterate, and so on.

IBM's developer guidelines for accessibility (mentioned in the "Considerations for Development" section) contain detailed testing advice for each guideline.