SPOKES IN THE WHEEL: THE CRITICAL ROLE OF ALL PLAYERS IN MAKING TECHNOLOGY ACCESSIBLE

By Terry Thompson

INTRODUCTION

The wheel: A smooth ride depends on the strength of each of spoke, and no spoke provides its support in isolation. Spokes support one another, and operate in relationship to one another. 
Like spokes in the wheel, a variety of players, individually and through relationships with one another, play critical roles in making technology accessible. As electronic and information technology continues its exponential growth toward permeating all aspects of contemporary society, it also continues to offer great potential to individuals with disabilities in attaining independence, including their K-12, postsecondary and career goals. However, in order for this potential to be realized, all players must be educated about their roles, must accept their roles, and must fulfill their roles in making technology accessible to all users. Players include consumers, technology developers (including developers of assistive technology, operating systems, software applications, user agents, and authoring tools), standards organizations, K-12 and postsecondary schools, employers and advocates.  This paper examines the role of each of these players, and explores the relationships between players.  

THE ROLE OF CONSUMERS

Successful products are generally those that meet consumer needs. In pursuing an academic degree, consumers with and without disabilities are likely to have a need for computers. They use these computers to write papers, search for information on the web, communicate using email, perform mathematical calculations and statistical analyses, and many other tasks. There are differences, however, in the specific computer technologies that will best meet this need for individuals. Some individuals ("power users") need multiple disk drives and ports to accommodate a variety of peripherals. For these consumers, a desktop computer best meets their needs. Others need the increased portability provided by a laptop or notebook computer. Still other users need even greater portability and a less obtrusive device: a handheld personal digital assistant (PDA) may meet their needs. 
Individual consumers have similarly variant needs when it comes to input devices. Some need a keyboard, some need a pointing device such as a mouse or trackball, and some need both. There are tremendous varieties of types of keyboards and pointing devices that users prefer. Some consumers use neither keyboard nor pointing device, and instead need an alternative input system such as speech recognition, head pointer, or eye-gaze system. 

Individual consumer needs also vary when it comes to output devices. Some consumers need to receive their computer output through large cathode-ray-tube (CRT) monitors for maximum color depth and resolution. Some need smaller liquid crystal display (LCD) monitors due to workspace constraints or portability needs. Some consumers have no need for a monitor, and instead receive their computer output audibly through a screen reader and speech synthesizer, with headset or speakers. Some users need to receive their computer output on a Braille device. 

This diversity of need is often misrepresented as being binary: Consumers without disabilities need X, consumers with disabilities need Y. In fact, all users have different needs and preferences. People with disabilities are no exception. These different needs influence the roles of many of the other players, particularly technology developers. 

THE ROLE OF TECHNOLOGY DEVELOPERS

Arguably, all technology is assistive technology, in that it assists users in performing tasks that would otherwise be difficult or impossible. For example, the automobile is a technology that allows humans to overcome our inability to walk great distances efficiently; calculators benefit consumers who have deficiencies in their ability to mentally process mathematics; and the spell checker in most word processing programs allows consumers to overcome imperfect spelling skills. 

Generally, the term assistive technology applies to technology that was developed specifically for users with disabilities, as opposed to other users. The Assistive Technology Act of 1998 defines "assistive technology devices" as "any item, piece of equipment, or product system, whether acquired commercially, modified, or customized, that is used to increase, maintain, or improve functional capabilities of individuals with disabilities. A few common examples of computer technologies that are generally categorized as AT include screen readers for users with blindness, screen magnification software for users with low vision, and scanning/reading software for users with learning disabilities.
It is sometimes beneficial to group such technologies together under the label assistive technology. It is helpful within the context of this paper, as assistive technology developers play unique roles in technology accessibility (see the following section, "The Role of Assistive Technology Developers"). Such categorization is also necessary in a legal context, as if entities covered by a given law are charged with responsibilities related to AT, they must have a clear understanding of how AT is defined by that law. The Assistive Technology Act of 1998, for example, provides grants for states to provide programs that address consumers' assistive technology needs, so clearly states need to a clear definition of assistive technology within this context.   

However, the distinction between AT and non-AT is often much more fuzzy than such categorization would suggest. For example, trackballs are often grouped in the assistive technology category since they are easier than mice for many people with physical disabilities to use. However, trackballs are primarily marketed to and used by the general population, as they meets consumers' needs for a pointing device that has superior comfort, ergonomics, and durability compared to most mice. Similarly, speech recognition technology was in its infancy marketed almost exclusively as an assistive technology. However, it now is marketed primarily to, and purchased primarily by, consumers in the general population. 

Given the fuzzy line between AT and non-AT, it is often helpful in some contexts to exercise the "all technology is assistive technology" model. This model avoids lumping certain groups of technology into a category that might be perceived as "special" or otherwise unrelated to the work of other players. For example, based in part on the perception that "assistive technology is different", assistive computing technology in higher education has traditionally been provided by disability services offices, usually in isolated locations. Migrating AT into the public computing environment in higher education requires a fundamental shift in philosophy, to a position that accepts AT as a technology not unlike other technologies, and therefore falling within the scope of responsibility of those responsible for installing and supporting all other computing technologies. 

Another benefit of the "all technology is assistive technology" model concerns technologies whose primary disability market is users with hidden disabilities, such as learning, cognitive or psychiatric disabilities. For example, scanning/reading applications can read scanned text aloud, and highlight the text as it's being read. These applications are extremely helpful for sighted individuals who have disabilities that affect reading. However, many universities have a difficult time persuading students to use them. One plausible explanation for this is that consumers with hidden disabilities are reluctant to use products that clearly identify them as having a disability. If these products' benefits are marketed to non-native English speakers, and even to the general population, they would perhaps be less likely to be perceived as stigmatizing, and would be more readily utilized by consumers who need them. 

The "all technology is assistive technology" model is also important for mainstream technology developers. From the author's experience (and to his initial surprise), software developers, when asked about their products' accessibility, often respond with "people with disabilities are not our target market". It seems, therefore, that accessibility must be communicated differently. Technology developers are not being asked to develop products for people with disabilities. They are being asked to develop products that consider the needs of their broadest possible user base, and to recognize that individuals within this user base have different needs, and will be using a variety of input and output technologies to interface with the developers' products. 

THE ROLE OF ASSISTIVE TECHNOLOGY DEVELOPERS

Developers whose products are "assistive technology" in the traditional sense have unique responsibilities toward improving technology accessibility. As with any product, AT developers must fully understand the needs of their primary users. Most AT developers have excelled in this area. Many of the developers are in fact individuals with disabilities themselves, or have some personal connection with disabilities that has led them to the AT field. 

However, it also critical that AT developers understand the role they play in the larger context, as spokes in the wheel. AT Developers must work in partnership with other players, particularly all other categories of technology developers, in order to assure that their product provides input or output to the mainstream products others are developing. For example, consider the computing needs of college students described earlier: word processing, the web, email, math and statistics. Given these needs, it is not sufficient for a screen reader to talk if it doesn't provide the college student with access to these applications. Providing access to a full range of application requires collaboration between AT developers, software application developers, and operating systems developers. 

AT developers must also conform to standards. One important standard for web accessibility is the Web Content Accessibility Guidelines (WCAG 1.0) developed by the World Wide Web Consortium (W3C). The WCAG 1.0 is discussed more fully in the "Content Developers" section. D'Amour and Roy (2002) tested the level of support for WCAG 1.0 provided by multiple versions of three major screen readers. None of the screen readers fully supported the standard. The screen reader that was most compliant with the standard supported only 66% of relevant checkpoints. 

THE ROLE OF OPERATING SYSTEM DEVELOPERS

On any computer, the operating system (OS) is the set of programs that performs basic tasks that are necessary for the computer to be functional. The OS provides a software platform on top of which application programs can run. Common operating systems are Microsoft Windows, Apple's Mac OS, Unix and Linux. OS developers play three primary roles in making technology accessible. Each is discussed below. 

Out-of-the-Box Functionality

In addition to the OS itself, operating system developers tend to provide a bundled core set of simple applications programs. These applications make the OS useful out of the box, allowing users to perform basic tasks such as word processing, calendaring, and mathematical calculations without having to purchase additional software products. Given the "useful out of the box" notion that has led to the availability of these products, it follows that the OS should be "useful out of the box" for all consumers, including those with disabilities. Following this thinking, basic assistive technology programs should be bundled into the OS. In fact, many operating systems do provide basic accessibility features that provide visual access to system sounds, provide keyboard control of the mouse pointer, and allow users to control keyboard behavior. Some operating systems come bundled with simple magnification software and an on-screen keyboard, and recent versions of both Windows and Linux have included a screen reader. For some operating systems, however, the bundled tools provide a very basic level of access, but generally lack the full functionality of products sold separately. 

The Application Program Interface (API)
Most operating systems provide an (API) to programmers so they can write applications consistent with the operating environment. All programs developed using a common API will have a similar interface, which makes applications easier to learn and use. The API provides a set of building blocks, and programmers assemble these building blocks into an application. It is important that the API provide support for accessibility. For example, all menus and controls in a graphic user interface should be accessible via keyboard, not just mouse; and should be displayed with a font and color scheme that can easily be customized by the user. As long as the API provides the means for delivering these and other accessibility features, applications within that environment can be accessible. However, accessibility of applications requires that software application developers use the accessibility features of the API. 
Communicating with Assistive Technologies
In order for assistive technologies (AT) to convey meaningful information to users about an application's user interface, the AT first must be able to access that information from the application. Microsoft's solution to this problem is Microsoft Active Accessibility (MSAA), which has been available since Windows 95 as an add-on and was built into subsequent Windows releases. MSAA is a technology that provides a standard, consistent mechanism for exchanging information between applications and assistive technologies. For example, MSAA allows applications to expose screen readers to the type, name, location, and current state of all objects and notifies screen readers of any Windows event that leads to a user interface change. 
Another environment, Sun Microsystems' Java, is unique in that it is not in itself an operating system, but is a general purpose programming language. It is designed to be platform independent: A compiled Java program can run on a variety of operating systems, including all of those mentioned above. Sun makes Java accessibility possible through its Java Accessibility API, which is a part of the Java Foundation Classes, a set of Java class libraries used in building graphic applications. The Java Accessibility API exposes user-interface components to assistive technologies such as screen readers and speech recognition systems. Sun has also developed other tools that participate in the communication between Java and assistive technologies, and a variety of resources documenting their use.
Assuming that an operating system developer has done its part to provide a means by which applications can communicate with assistive technologies, it is then the responsibility of both software application developers and AT developers to fully build support for this capability into their applications. 
THE ROLE OF SOFTWARE APPLICATION DEVELOPERS
As noted in the "Consumers" section, software application developers need to recognize that consumers of their products are likely to have a variety of characteristics, and are likely to be using a wide variety of technologies and configurations to access their products. A set of twelve accessibility standards covering both software applications and operating systems was developed by the Architectural and Transportation Barriers Compliance Board (Access Board), and published in the Federal Register on December 21, 2000. This was part of a larger set of Electronic and Information Technology Accessibility Standards, the development of which was required by the Section 508 of the Rehabilitation Act Amendments of 1998. 
Section 508 requires that federal agencies procure, develop, maintain, and use accessible technologies, unless it would pose an undue burden to do so. It has provided a stimulus for a growing number of software developers to addressing the accessibility of their applications. Two prominent examples are Adobe Systems, Inc. and Macromedia, Inc., who have made significant improvements to the accessibility of their Portable Document File (PDF) format and Flash animation technology, respectively. Both are now more compatible with assistive technologies, and provide features within their authoring tools that allow content developers to create accessible content. Both, however, are dependent on AT developers building tools that support the new improved format, and on content developers understanding and incorporating the improvements into the content they're creating. 
While companies who sell to the federal government are improving accessibility of their products in response to Section 508, those in other markets are perhaps less motivated to do so. This is particularly true of educational software that is developed for the K-12 market. Golden (2001) surveyed 19 "award-winning" instructional software companies, and found that 65% were not aware of accessibility as an issue, 100% were not currently addressing accessibility in product development, and 88% had no plans to address accessibility in the future. Clearly advocates have challenging work ahead in this market. 

THE ROLE OF USER AGENT DEVELOPERS
User agents are specific types of software applications that play a major role in delivering web content to consumers. The W3C defines "user agent" as follows: 
"Any software that retrieves and renders web content for users. This may include web browsers, media players, plug-ins, and other programs--including assistive technologies--that help in retrieving and rendering web content." (W3C User Agent Accessibility Guidelines 1.0, Glossary)
Content developers communicate to users through the user agent. In order for this communication to be successful, the content developers much communicate accessibly, and user agents must correctly interpret and relay the message. The W3C has developed two related sets of guidelines, one for each player, that address its need. In addition to the WCAG 1.0 (guidelines for content developers), the W3C has developed a set of twelve User Agent Accessibility Guidelines (UAAG 1.0) that clearly define the role of user agent developers in supporting accessibility. 

THE ROLE OF AUTHORING TOOL DEVELOPERS

Authoring tools are specific types of software applications that allow content developers to more easily create content. Popular web authoring tools include Microsoft FrontPage and Macromedia Dreamweaver. Courseware packages such as Blackboard and WebCT might also be considered within this category, as they provide instructors or other develops distinct interfaces for authoring their online courses. 

As software applications themselves, authoring tools should be accessible to content developers who have disabilities. Beyond this, the role of authoring tool developers in making technology accessible is to provide the tools with which content developers can create accessible content. The W3C has also developed guidelines for this group, the Authoring Tool Accessibility Guidelines (ATAG 1.0). 
Currently, all major web authoring tools allow content developers to create fully accessible web pages. However, none of them support accessible design techniques exclusively from their graphic user interface. Some accessible design techniques require that developers make modifications directly to the HTML code.

THE ROLE OF CONTENT DEVELOPERS

Content developers play an especially critical role, due to their quantity. There are very few operating systems, and a relatively small number of software applications in all categories. However, there are conceivably millions of content developers creating web pages, authoring PDFs and Flash applications, designing on-line courses, and developing other content. Advocates face a tremendous challenge in educating all these content developers about their roles. On the other hand, it is generally much easier to create change in an individual than it is to create change in an organization. For this reason, web content developers may in many cases be more receptive to the message of accessibility than other technology developers, and in a better position to provide an immediate solution to a problem.  

The WCAG 1.0 was the first set of formal guidelines for web content developers. It became an official W3C Recommendation on May 5, 1999. It lists fourteen guidelines, and additionally provides a list of checkpoints for each guideline. There are a total of 65 checkpoints. Each checkpoint has been assigned a priority level (1-3), where Priority 1 checkpoints address barriers that make access impossible for one or more groups of users. Priority 2 and Priority 3 checkpoints address barriers that make access difficult and somewhat difficult, respectively.

By comparison, there are sixteen Section 508 standards that specifically address the accessibility of "Web-based intranet and internet information and applications". These standards closely parallel the WCAG 1.0 Priority 1 checkpoints, but there are some differences. Section 508 standards define the minimum level of web accessibility for web sites developed or used by the Federal government. Although in many instances the 508 standards and the WAI guidelines are identical or very similar, in general, WAI standards represent a higher level of accessibility. 

Web content developers are increasingly aware of accessibility issues. Hypertext Markup Language (HTML) originated in 1992, and is now only on version 4.0.1. Although considerable advocacy work still remains, a growing number of web developers seem to be applying accessibility techniques. However, content produced with newer technologies, such as PDF, Flash, and others) has only recently been capable of accessibility, so the long process of educating PDF and Flash content developers is in its infancy. 

The W3C is currently working on WCAG 2.0, which in its current draft streamlines the number of accessibility guidelines from fourteen to five: Web content must be perceivable, operable, navigable, understandable, and robust. The previous guidelines are much more specific and consequently more limited in their scope: They apply primarily to HTML as it was being used by content developers at the time the guidelines were created. WCAG 2.0 is intended to provide a more general set of guidelines, which are applicable across technologies and more durable with time. With this approach, web content developers can attain a more broad understanding of accessibility issues, and can apply the guidelines regardless of whether they're developing content using HTML, PDF, Flash, or some future technology. 
THE ROLE OF STANDARDS ORGANIZATIONS
A major player mentioned throughout this paper has been the World Wide Web Consortium (W3C). The W3C's role is to develop specifications and guidelines (as well as software and tools) that promote the interoperability of all web technologies. In terms of accessibility, their role is to provide guidelines that assure that content developers, authoring tools, and user agents are all on the same page, and products developed by all parties will support the same set of guidelines. Accessibility guidelines and related products fall under the scope of a W3C subgroup, the Web Accessibility Initiative (WAI), but the activities of this subgroup permeate all other subgroups, and standards produced by the W3C consistently address accessibility issues. 

Other standards organizations may also play significant roles. For example, the Internet SOCiety (ISOC) is an international professional membership society that provides leadership in addressing issues that confront the future of the Internet, and is the organization home for the several groups that are responsible for Internet infrastructure standards. In 2002 and early 2003, a Disabilities chapter was formed within the ISOC, to assure that accessibility is addressed within other ISOC activities. Also, The IMS Global Learning Consortium is an organization develops and promotes open specifications for online distributed learning activities, including a set of Guidelines for Developing Accessible Learning Applications. 

THE ROLE OF K-12 AND POSTSECONDARY SCHOOLS

The college student described in previous examples has a need for computing technology in order to complete his or her assignments, tests, and other academic activities. If all players related to technology development have fulfilled their roles, the student will be able to perform these activities successfully. One of the key areas in which schools are significant is in their role as content developers. Instructors who are using technology to deliver their curriculum must following accessibility guidelines and techniques to assure that all students can access that curriculum. Instructors may work in collaboration with technical design teams, in which case the team has the same responsibility. Additionally, many educational entities have support teams who provide training and support services to faculty and staff who are newly utilizing technology in their teaching. In these cases, the support teams play a role in assuring that all players are adequately trained on accessibility issues. In higher education, this has traditionally occurred through occasional courses and workshops that deal specifically with accessibility. However, these events tend to attract only those who already have some awareness and interest in accessibility. Another approach that is increasingly implemented is to embed accessibility information into the context of mainstream trainings and workshops. If an instructor is taking a course to learn how to design web pages, he or she learns in that course how to do so without excluding users. 
The challenge in getting any or all of these players to fulfill their roles is that often there is no stimulus: Neither the instructor, nor any member of the design team, nor any member of the support team, has any experience with nor interest in accessibility. In these cases, it is the role of the advocate to provide the stimulus, perhaps by working with the training and support teams, and empowering them to disseminate the accessibility message. 

Schools also play a role in assuring that students have access to the technology they need. For examples, if students have access to computer labs, schools have an obligation to provide the input and output devices necessary so that all students can access those labs. Schools also have an obligation to purchase technology that is accessible, as described in previous sections. Section 508 requires that federal agencies procure, develop, maintain, and use accessible technologies, unless it would pose an undue burden to do so. Although Section 508 directly applies to federal agencies, many questions and issues have been raised regarding its applicability to other entities, including educational entities. Whether or not entities outside of the federal government are covered by Section 508, the accompanying accessibility standards provide the only legal definition of technology accessibility across its six categories of electronic and information technologies. Thus, Section 508 provides technical clarification to schools that must provide an accessible education in accordance with other laws, such as Section 504 of the Rehabilitation Act and the Americans with Disabilities Act. 

As stated earlier, assistive technology in higher education has traditionally been provided in small, centralized assistive technology (AT) labs, often within the context of the Disability Services office. Many institutions, however, are departing from this model, and now use AT labs only to supplement the availability of AT across the broader campus-wide computing environment. The isolated "AT Lab" model generally fails in providing students with disabilities equal access to computing resources, as the isolated AT labs often don't have support for the full set of network applications that students might access in the larger public labs. Students in isolated AT labs also don't have access to the support staff and peer support that is often available in the larger labs, or the discipline-specific support that is available in college or departmental labs.  

Schools also have a responsibility to train students with disabilities in the use of assistive technologies, to the same extent that they train non-disabled students to use mainstream technology resources. Ideally, a student entering postsecondary school will have already mastered the use of any assistive technology that best meets their needs. This mastery can come from many sources: state vocational rehabilitation services, independent living centers or other organizations who offer assistive technology training, state assistive technology centers funded by the Assistive Technology Act of 1998, AT vendors, or private tutors.  K-12 schools can also provide this training, or can play a role in helping students to locate the above or other resources for funding, training and support. 

THE ROLE OF EMPLOYERS

If students experience success in their education, the skills they acquired should prepare them for the workplace. The tools learned in college are likely to be comparable tools encountered in the workplace, and can be made accessible using similar assistive devices and deployment techniques as those utilized successfully in school. If school was not highly successful in providing accessible technology, employment provides a fresh new opportunity for employees with disabilities to gain unprecedented access. Employers are prohibited under Title I of the ADA from discriminating against employees or potential employees on the basis of disability, and are required to provide reasonable accommodations. For many employees reasonable accommodations might include technology solutions.   

THE ROLE OF ADVOCATES

The term "advocates" in this context refers to those who advocate for themselves, those who advocate for other individuals, and those who advocate for systems change. The role of advocates is to assure that all other players are aware of their roles, and to perpetually remind them that they must fulfill their roles.  They have the most challenging of roles, because they must understand the roles of other players, must educate those players, and must persuade those players to fulfill their roles. 

Some organizations may have positions or departments whose responsibilities for the organization include this type of advocacy. Higher education disability services groups are one example. In other organizations, the advocacy role may fall upon the shoulders of individuals who have an interest. Advocates from the outside can influence an organization by reaching key individuals within an organization who might be receptive to the message, and who might have sufficient drive and/or influence to spread the message further, and to attract additional supporters.  
 
THE ROLE OF LEGISLATORS

The role of legislators in any society is to assure that the society is organized in such a way that all players are encouraged to do their part, or to suffer consequences. Despite the best work of advocates, some of the players defined in the proceeding paragraphs may not be sufficiently persuaded to do their part in making technology accessible. Thus, legislation may be necessary. Section 508 has been mentioned several times throughout this paper, as have Section 504 and the ADA. Section 508 has played a particularly important role in making technology accessible. Since its passing in 1998, technology developers have worked with unprecedented zeal to address their products' shortcomings, as otherwise they risk losing or missing out on lucrative contracts with the federal government.  

CONCLUSION

Making technology accessible is a complex and difficult problem, involving many players. It's easy to assign blame to an individual technology developer, or content developer, or educational entity, though doing so is often an oversimplification of the problem. All players must do their part in order for the wheel of progress to continue rolling toward a promising and accessible future.

REFERENCES

Adobe and Accessibility. Retrieved March 1, 2003 from http://access.adobe.com/

The Americans with Disabilities Act of 1990, S. 993. Retrieved March 1, 2003 from http://www.usdoj.gov/crt/ada/pubs/ada.txt

Assistive Technology Act of 1998, S. 2432. Retrieved March 1, 2003 from http://www.ncddr.org/relativeact/statetech/ata98.txt

D'Amour & Roy (2002). How assistive software supports web accessibility. Paper presented at CSUN 17th Annual International Conference Technology and Persons with Disabilities, Los Angeles, CA. Retrieved March 1, 2003 from http://www.camo.qc.ca/ntic/csun2002en.htm

Golden, D. C. (2001). Instructional software accessibility: A status report. Retrieved March 1, 2003 from http://www.ataporg.org/software%20accessibility%20survey.htm

IMS Guidelines for Developing Accessible Learning Applications. Retrieved March 1, 2003 from 
http://www.imsglobal.org/accessibility/accessiblevers/index.html

Internet Society (ISOC). Retrieved March 1, 2003 from http://www.isoc.org/ 
Macromedia Accessibility. Retrieved March 1, 2003 from http://www.macromedia.com/macromedia/accessibility/

Microsoft Active Accessibility: Architecture. Retrieved March 1, 2003 from http://msdn.microsoft.com/library/en-us/dnacc/html/actvaccess.asp

Sun Microsystems. Java Accessibility. Retrieved March 1, 2003 from http://java.sun.com/j2se/1.4/docs/guide/access/index.html

W3C Authoring Tool Accessibility Guidelines 1.0. Retrieved March 1, 2003 from http://www.w3.org/TR/ATAG

W3C User Agent Accessibility Guidelines 1.0. Retrieved March 1, 2003 from http://www.w3.org/TR/UAAG

W3C Web Content Accessibility Guidelines 1.0. Retrieved March 1, 2003 from http://www.w3.org/TR/WCAG

W3C Web Content Accessibility Guidelines 2.0: Working Draft 22. Retrieved March 1, 2003 from http://www.w3.org/TR/WCAG20