Accessibility advocates worldwide are urging the software industry to develop mainstream products that are accessible to people with disabilities and older users by following accessible design principles. The business rationale is simple: Accessible design makes products more attractive for many users, not only those with disabilities. For example, an application designed for usability by all people, including those who cannot see, will also be better suited for mobile devices with small screens. All users will be more efficient and make fewer errors if they have a product designed with cognitively disabled users in mind. In other words, accessibility is an untapped market opportunity with potentially high rewards.¹

Lawmakers are also pushing to make products accessible, especially those for Web sites. In the US, section 508 of the Rehabilitation Act mandates that all federal agencies purchase only accessible products and provide information on the Web in a barrier-free manner. Similar regulations are either under consideration or in force in other countries, including Australia and many European countries. In Germany, for example, the 2002 anti-discrimination law requires that federal government Web sites be accessible by the end of 2005.

In general, accessibility regulations rely on a common, standardized view of what makes a software product or Web site accessible. The Trace Center at the University of Wisconsin and the World Wide Web Consortium (W3C) have been pioneers in developing guidelines for accessible design in the software and Web domains.² Today, accessibility guidelines are available for the following areas:

• Software in general ³
  
  
• Major operating systems and platforms
  
  
• The Web
  
  
• E-learning applications
  
  
• Public terminals
  
  
• Telecommunications and other domains

However, despite all of these guidelines, standards, and regulations mandating accessibility,⁴ most mainstream products are still not designed with disabled users in mind. Why is it that most software developers and Web designers know so little about accessible design principles?

Embedding accessibility design in the development process

First, at present, accessibility guidelines and standards are static objects. To have a real impact on product development, they need to be embedded into today's development environments and made operable and practical. Software development projects typically have stringent time and budget constraints; designers and developers do not have time to wade through long lists of accessibility criteria.

Our contention is that accessible design practices should be so tightly integrated into an organization's software engineering process that they become unremarkable. In other words, team members should easily be able to follow them routinely, just as they would follow sound engineering practices of any kind. In effect, such an integration would extend and enhance product usability for a wider range of people in a wider range of environments.

This integration would also represent the next evolutionary phase in accessible design. The first phase was exploration: finding out what works and what doesn't in terms of accessibility. The second phase was convergence: the development of commonly agreed-upon accessibility guidelines for specific areas, such as the Web, e-learning, and so forth. Now, with a baseline of acknowledged guidelines and standards, we are ready to implant the principles they define into software development tools and environments. Then, developers can use these tools to automatically assess a product's accessibility with respect to specific user groups and also for process-integrated guidance on how to apply accessibility principles.

Second, designers tend to think about accessibility as a patch they can apply to a product after it is complete. It is an afterthought (or a "never-thought") rather than an integral planning consideration. That makes it expensive. "Adding" accessibility to a Web application after development costs around ten times more than building it in from the beginning.⁵ As a consequence, many people consider accessible design to be unaffordable, and therefore, harmful to product competitiveness.

Again, embedding accessible design principles into popular software development processes and tools would resolve these problems. If we treat accessibility requirements as ordinary requirements, then they will appear in developers' task descriptions, together with functional and performance requirements. Developers need not do anything extraordinary to make a product usable for people with disabilities; all they have to do is develop the product to meet specified requirements.

Back to top

Integrating accessibility principles into RUP

Application development is not a new discipline, and adopting proven best practices can help organizations deal successfully with the complexity of application development. Our goal is to use these best practices as a vehicle for integrating accessible design principles into mainstream application development.

The IBM Rational Unified Process,® or RUP,® is a process framework and a collection of best practices for a team-oriented software development approach. In 2003, it was used by about half a million users worldwide, within more than 3,000 companies.⁶ RUP is designed to be easily configurable for specific projects in specific organizational contexts. Projects or organizations may either develop their own plug-ins to accommodate their specific needs or incorporate third-party plug-ins available within the RUP community.

RUP provides a common understanding of concepts and workflows, and it comes with templates and checklists for various points in the development process. This makes it an ideal vehicle for incorporating accessible design principles, and we use it in this article to demonstrate how this can be done. However, as you read, please keep in mind that the concepts and methods we propose can be embedded into any iterative application development process.

Gathering requirements

Although accessibility is sometimes defined as "usability for all users," some aspects of accessibility go beyond this, taking into consideration people with different sets of abilities and personal tools. Today, a significant aspect of accessibility is interoperability with assistive technology, and therefore, conformance with established standards.

Current accessibility regulations and policies require that most products be accessible to users with a very broad range of functional limitations and within a broad range of age groups (with some exceptions; for example, an online banking system does not have to be designed for use by six-year-old children.)

Although we often think of accessibility as an inherent software quality, it is not really a binary attribute (i.e., one that is either true or false), but rather a relationship between a product and a user within in a particular context. Therefore, instead of asking, "Do we want to make this product accessible?", we should ask, "Who are the target users (i.e. intended and required) for this product?" Further, we will want to know: "What are their needs?" and "Under what circumstances will they use this product?" These questions are consistent with the RUP "develop a vision" activity that takes place during the Inception phase, at the beginning of a software development project.

Let's take an online banking application as an example. Before we begin designing the product, we must first identify potential users' functional and non-functional requirements if we expect the product to meet our goal of serving more customers at lower cost than the bank can achieve through its bricks-and-mortar channel alone. Here is a sample of these requirements:

• The application must be simple to use -- no one wants to read a manual in order to do banking business.
  
  
• The application must be usable by a variety of people: men and women, the young and the elderly (who may be too frail to go to the bank), English and Spanish speaking, experienced computer users and technophobes.
  
  
• The application must be usable by the elderly and others who have difficulty reading small text. The application must be usable by people of all ages with limited manual dexterity who have difficulty using a mouse.
  
  
• The application must be suitable for use in the home environment. Most customers will access it via home computers with Internet connections.
  
  
• Users must have the ability to disconnect while working on their wire transfer order because they pay Internet charges by the minute.
  
  
• Images must be easy to recognize, even for users who have poor vision.
  
  
• For the blind, at least one screen reader should be available on targeted execution platforms and work well with the application. Alternatively, the product could be designed to provide audio output.

Note that our initial requirements gathering is based on the iterative development approach advocated in RUP. Our assumption is that we will add, modify, and drop requirements during the lifecycle as indicated by technical, time, budget, or other drivers. We will also develop the application in defined iterations, each of which incrementally contributes to the application's defined scope and quality standards. Nevertheless, early in the process, it is critical to define an initial set of requirements (including use cases) that is as complete as possible. These requirements will serve as the basis for further iteration planning and risk management. At any point in the process, the requirements set should reflect current knowledge about the envisioned product.

Once we capture accessibility requirements (including legal mandates), we can treat them as we would any other requirements. Accessibility should serve as a criterion for judging overall product quality in the same way that other functionality serves to determine product quality. In other words, if the product is not accessible for target users, then the product is defective.

Once we identify the target user base and derive our accessibility requirements, what is the best way to communicate those to designers and developers? Creating a long list for them to address manually is not practical for most projects. Realistically, we must capture these requirements in a form that is convenient and accessible to all team members. Using personas, embedded in use cases and scenarios, is one way of doing this.

Employing use cases and scenarios

Numerous mainstream software engineering projects have employed use cases successfully to specify an application's external behavior. Use cases make functional requirements accessible and understandable for all stakeholders involved in a project.

Introduced by Ivar Jacobson in 1992,⁷ a use case is defined as a sequence of actions a system performs that yields an observable result of value to a particular actor.⁸ The Unified Modeling Language (UML) defines a graphical notation for use cases, which focus on what a system should do rather than how it should do it. Use cases act as a common language for communication between the customer (i.e., the users) and the system developers. Therefore, they can be used to capture requirements very early in a development project.

Whereas use cases capture a generalized view of a user and a task, scenarios describe a specific instance of a use case in terms of a concrete workflow. Scenarios use specific data, specific events, and possibly a specific user interface, sometimes depicted on a storyboard. Development teams typically generate a few scenarios per use case to illustrate both a typical flow of events and various error conditions (see Figure 1). Scenarios are based on real data, which makes them a suitable basis for test cases later on in the process.

Figure 1: Every use case has an assigned set of scenarios.

RUP employs use cases to link usage descriptions to an application's architecture and code. In essence, use cases function as drivers for incremental application development and threads that connect various development activities throughout a project lifecycle.

However, use cases and scenarios have limitations. They regard users merely as "actors" and capture their user interface needs -- and their abilities -- only implicitly, if at all. Although these techniques provide an excellent means to describe system behavior, they cannot convey adequate information on real users' environments and interface needs.

Adding personas to capture accessibility requirements

Using personas, a concept introduced by Alan Cooper in 1999,⁹ is an appropriate way to fill this gap. Specifying a persona involves assigning a fictitious name and face (photo) to a system user and then writing a rough description of a day in that person's work life. Although the fictional persona is portrayed as an individual, the profile typically reflects a whole group of users.

Cooper distinguishes between primary and secondary personas. The primary persona represents the main targeted users; it is therefore the main driver for designing the application's user interface. A secondary persona has additional needs; people who fit this description can use the primary persona's interface only if changes are made to address these needs. Of course, these changes must not conflict with the interface needs of the primary persona or those of other secondary personas.

In practice, using personas has resulted in effective, user-centered design. Personas have enabled developers to view their systems through the eyes of a variety of potential users with varying interface needs and preferences.

Typically, product designers have little knowledge of how people will actually use the product and even less about the end users' needs and goals. This is especially problematic if the designers are young, technically sophisticated, and designing a product that will be used by older people, among others. It is also a significant problem for people with disabilities. Personas can help designers understand how older people and disabled people will use a product if they are defined as people with individual feelings and struggles in life.

As developers work with such personas over time, they will grow more familiar with their needs and preferences -- and even empathize with them. The disabled users that these personas represent will become tangible, ubiquitous presences in the development process.

A persona specification typically includes the user environment, including any assistive technology that the person might need to use the product. You might write multiple descriptions for one or, alternatively, split up one user group into multiple personas to represent the range of users who are blind (speech output users, Braille users, congenitally blind, blindness acquired late in life, etc).

Personas alone are not a substitute for specific accessibility requirements; rather, they are devices that add meaning and context to these requirements. They can make the requirements more concrete and easier to understand. Over time, they can help designers internalize the requirements so that they follow them as a matter of course, without having to memorize them or follow them superstitiously. Superstitious¹⁰ conformance to accessibility requirements usually results in designs that meet specifications but are not necessarily optimal or even operational. It is far more effective to use personas both to illustrate accessibility requirements during design, and then later, to derive testable evaluation points during implementation and testing. We will discuss this latter function later on.

You should have a set of associated personas for every human actor (see Figure 2). For each set, you must designate one primary persona; the others are all secondary. The primary persona should drive the user interface design for every use case that involves the associated human actor. Then, for each of these use cases, you should "replace" the primary persona with each secondary persona in succession, amending the user interface design, and making sure that the user interface meets the needs of each secondary persona. You can follow a similar procedure for scenarios. In rare cases, two personas should be primary because they have conflicting user interface needs. In such instances, you can duplicate the use case, assign each use case one primary persona, and create a separate user interface for every use case.

Collectively, use cases, scenarios, and personas constitute a powerful technique for user-centered analysis and design. Use cases capture the overall functional behavior of a product; personas specify a (diverse) set of target users for a use case and can therefore express accessibility requirements; and scenarios, linked to specific use cases, describe a real-life sequence of events for a real user.

Figure 2: Every use case has an associated set of personas.

How many personas do you need? To represent a complete set of users, including users with multiple disabilities (common among older people), our research shows that you may need as many as thirty personas, given the great variability among this group and the many dimensions of disability. It would be advantageous to obtain full coverage with a smaller number; and work on this is underway at the University of Wisconsin's Trace Center. For now, however, using a set of personas that does not represent the diverse array of limitations, ages at onset, skills, and so forth among people with disabilities can lead to serious misunderstandings and wasted effort. Even designers who are earnest about accessibility often inadvertently overlook important user groups' needs - including those of aging users. More research needs to be done to identify a standard set of personas for use in application development. Again, heuristics and design guidelines for accessibility are critical for creating a manageable design process with personas.

Ensuring accessibility for user support

When you finish developing a product, the users who deploy it will need support. Here is another place where personas are useful; they can drive the support mechanisms for these users. You can use the personas to develop product documentation (e.g., user's guide, installation guide, course and training materials). If you plan to distribute documentation in printed form, you might also have to make it available in electronic form. You should check these documents, as well as other online materials (e.g., online help, release notes, Web pages for download) for accessibility for targeted user groups. If the product is to be sold as a physical package, you may need to check the packaging's accessibility as well. If you are holding a tutorial event, then the room should be accessible.

If you decide to offer a hotline for instant user support, then you should check accessibility for that, also. You may need to install a separate hotline for text telephone users and include its number in the documentation.

Testing for accessibility

RUP describes testing as a means for continuously assuring quality throughout the software development lifecycle.¹⁰ Early testing can significantly lower the cost of completing and maintaining the software. Tests are derived primarily from requirements, but they draw from other sources as well. For example, you test after you discover and correct specific error conditions. For today's complex software applications, automated tools are essential for generating test data, and for running and analyzing tests.

If you have captured accessibility requirements using a specified set of personas that are integrated into your use cases and scenarios, as we described above, then you can make accessibility testing an integral part of your continuous lifecycle testing activities. Jim Heumann of IBM Rational describes a method to generate test cases from use cases and scenarios.¹¹ As we noted earlier, every use case has a set of scenarios representing the main and alternate flows of events, respectively. Testers can derive one or more test cases for each scenario and attach data values to them.

These test cases are useful for evaluating a product against its functional requirements. They also provide concrete user interfaces for use cases, which let you evaluate the product against its accessibility requirements; you can base your tests on accessibility evaluation points derived from a set of personas.

As we have seen, you can assign a set of personas to each use case and its human actor to create an integrated approach for accessible design. No matter which persona you use in a test case, the test data will be the same, because the flow of events is the same for the primary and secondary personas. However, secondary personas typically extend or enhance a scenario's usability requirements, and these additional requirements must be checked.

To run a test case, it is sufficient to construct the test data based on the primary persona and then do additional accessibility checks based on the secondary personas. For example, if your primary user uses a mouse and keyboard for visual interaction, a secondary persona who uses a screen reader and keyboard navigation would add the following requirements:

• All elements must be exposed through the platform's accessibility API.
  
  
• Images must have textual equivalents.
  
  
• All elements must be accessible through the keyboard.

For a secondary persona with hearing impairment, you would ensure that you have provided volume adjustment capability for sound output, subtitles for video clips, and so forth. For a secondary persona with a language or learning disability (which might be invisible), you would pay special attention to the product's ease of use, the reading level for online help text, and so forth.

Using automated and manual tests to verify accessibility

As with most testing, it is advantageous to automate the testing you do against accessibility requirements. With an automated test tool, you can run regression tests repeatedly during the development lifecycle to ensure that your system architecture and user interface are still sound and that accessibility features are still intact after you make changes. Ideally, you can even generate the script that implements the test case (or part of it) automatically. However, not all aspects of accessibility lend themselves to automated testing. And it is important not to rely too heavily on those aspects that are suitable for such testing.

RUP's testing recommendations comprise unit testing, integration testing, system testing, and pilot testing. Techniques for testing against accessibility requirements are roughly the same for all of these areas (with the exception of pilot testing, which mainly involves testing on real users). It is desirable to begin testing as early as possible. Unit tests, executed by developers, allow you to identify and fix problems early on, which lowers both costs and project risks. Fixing problems you detect through later testing typically involves more than one person -- and therefore, more overhead costs.

In many projects, developers write unit tests at the same time -- or sometimes even before (as in test-driven development) -- they write their code. This is a feasible approach if the unit tests are reasonably small and cover only essential functional requirements. If developers had to write code for accessibility evaluation points in every test case, that would add a great deal of work. Fortunately, accessibility requirements are common across test cases and functional units running on the same platform. Most accessibility requirements are concerned with user interface design, and are the same for use cases with similar user interfaces. Hence, developers can reuse evaluation points across project test cases and use cases, using their current testing tools to generate test code automatically and validate a product against accessibility evaluation points.

Furthermore, there are specialized commercial and free tools for accessibility checking that can help simplify and automate the testing process. Most of these tools evaluate Web pages on the basis of guidelines and regulations.¹² Some allow you to configure the set of evaluation points to apply to your application.

Accessibility evaluation points are atomic checkpoints specific to a particular platform; unfortunately, not all of them can be tested by machines. For example, a machine can test whether a text equivalent is available for an image, but it cannot test the quality of the text or even determine whether the text is meaningless filler.

However, a machine can take over to perform uniform, repetitive tasks once a human being has made such a determination. For example, if a tester manually validates a particular text for a particular image, then he can program a machine to validate the same text for copies of the image throughout the application. Then, in subsequent test runs, a human tester will not need to look at the text equivalent again unless the image or the text has changed since the last test run.

Unfortunately, there are fewer tools that focus graphical user interfaces, and most are much less sophisticated than the others we have mentioned. However, this situation should improve as the demand for productivity tools to support accessible design increases.

Deriving accessibility evaluation points from personas

Identifying accessibility evaluation points is not a trivial matter. These points should be based on the personas involved in a use case and their contexts of use (see Figure 3). If you add a persona to some or all use cases, you should also add checkpoints to the pertinent test cases to make sure that the system is accessible to the new persona.

Figure 3: Test cases are derived from use case scenarios; evaluation points are derived from personas and included in the test cases.

Ideally, you could use an automated tool to derive accessibility evaluation points based on personas and their contexts of use. For this to be feasible, you would need a seamless connection between personas and accessibility test tools. This approach would also raise specific requirements regarding the standards and guidelines from which the evaluation points are drawn. For discussion purposes, we will assume guidelines and standards that comprise a set of evaluation points that developers can use for product checking. Of course, real standards and guidelines actually contain general accessibility principles that developers need to translate into platform-specific evaluation points.

Let's also assume that our guidelines and standards explain how each evaluation point affects usability for different types of users (personas) and classify user benefits as essential, important, or beneficial. If the system does not meet an essential evaluation point, the persona will not be able to use the system at all. If it does not meet an important evaluation point, the persona can use the product, but only with great effort and in an inefficient way. If the system fulfills a beneficial evaluation point, the product will be more usable for the persona, although it would still be functional without meeting the criteria.

In some instances, an evaluation point may actually make it harder for a particular persona to use the product. We can also define three degrees of disadvantage: excluding, impeding, and inconvenient. Excluding means that if the evaluation point is met, the persona cannot use the product at all. Impeding means that the persona could use the product, but only with considerable effort. Inconvenient means that the product is less usable for the persona, but the persona can still use it without significant hardship.

Taken together, the relationship between an evaluation point and a persona can be described along a scale of seven values:

1. Essential
   
   
2. Important
   
   
3. Beneficial
   
   
4. Neutral
   
   
5. Inconvenient
   
   
6. Impeding
   
   
7. Excluding

The goal is for a product to meet all essential criteria and as many important criteria as possible for all personas without creating any excluding or impeding elements for others.

In our ideal set of standards and guidelines, each guideline would have multiple sets of evaluation points, with each set pertaining to a specific platform. That way, you could switch runtime platforms in the middle of a project and simply trade your former set of evaluation points for a set geared to the new platform. Your requirements -- based on the set of personas -- would remain stable, and would still drive the selection of evaluation points for the new platform.

Mitigating accessibility-related risks

In any application development project, the project manager has to ensure that the product is developed according to a set of requirements, on time, and within budget. When using the iterative development approach embodied in RUP, the project manager maintains a list of risks sorted by likelihood of occurrence and impact. Each successive iteration tackles risks that are most likely to occur at the time and that would have a severe negative impact on the product. Typically, teams derive these risks by looking at requirements that the product does not yet meet. If they have included accessibility requirements in their initial set, then they can mitigate accessibility risks early on, just as they would other usability problems.

For example, during the RUP Construction phase, a developer might determine that the product cannot be accessed by a persona using a screen reader. To mitigate this risk, the team could build a prototype in the targeted runtime environment and then test it with a screen reader.

When change requests come in, they need to be scrutinized for potential conflicts with existing requirements. Such changes can destroy an application's accessibility for some users; every change should be analyzed with regard to the project's set of personas. For example, if you decide to display help information as a tool tip rather than in a separate window that would open by user request, the tool tip might not be accessible to screen reader users. If your persona set implicitly contains a requirement for interoperability with screen readers, you could anticipate this problem by doing a check against requirements before making the change.

Expert reviews and user testing

The persona-driven design approach we have been discussing will provide basic guidance for creating accessible products, but as personas are only approximations of actual users, it is important to complement this approach with expert reviews and real user testing. Of course, it is also important for the designer to have complete information about potential users and fully understand persona characteristics. If designers make faulty assumptions about what a persona can do, they may design a product that such a person could not actually use. Since most designers are not familiar with disabled people or their capabilities, this type of error is common.

The best way to avoid creating a product that remains inaccessible at a late stage of development is to conduct user testing during every iteration -- but budget and time constraints usually make this impractical. For many projects, the best alternative is to conduct reviews, using experts who understand the characteristics of people with disabilities and their implications for various product designs. Through such reviews, you can discover many of the same design problems that you would identify through user testing and obtain guidance on how to fix them.

The best strategy is to engage these experts for testing throughout the project lifecycle. At the beginning they can help to identify the product's targeted users as well as regulatory requirements regarding accessibility and usability. In addition, they should guide the critical task of creating personas, based on the identified user base. This will pay off multiple times over the development lifecycle.

During every iteration, these experts should conduct accessibility reviews to discover design problems, based on heuristics and their own expertise. This is particularly important for earlier iterations, when it is easier to correct design problems. Based on these expert reviews, it may be necessary to modify the set of personas or clarify their characteristics for designers as the iterations progress.

However, although such expert reviews are significantly easier to conduct and cheaper than user testing, some design problems can be discovered only through user testing. We recommend at least some user testing of prototypes early in a project to mitigate major accessibility risks. Your accessibility experts can help plan, conduct, and evaluate these tests. These activities will yield benefits for your organization that extend beyond your current project. As you fine-tune your personas in response to test results and provide more meaningful descriptions to the designers, you will be developing effective assets that you can store and reuse across all your software development projects.

Back to top

Roadmap for universal design with RUP

As we noted earlier, RUP can be adapted to become an integrated development framework for accessible design. This section provides a rough outline (roadmap) for doing so.

As we noted earlier, you can tailor RUP workflows, workflow details, templates, reports, and checklists to include accessibility-related tasks.

For example, one focal point for applying the approach we have described is the RUP artifact User Interface Prototype. By deriving a user interface design in a more formal way through the application of personas, and by using advanced tools that can check the user interface against generated evaluation points, you can mitigate fundamental accessibility risks early in the development process. This is similar to mitigating architectural risks in the Elaboration phase, as described in RUP.

Beyond simple tailoring, we suggest extending RUP with three additions:

• Personas as a new artifact type
  
  
• Evaluation points for accessibility testing
  
  
• A new accessibility manager role
  
  

Adding personas

As we described earlier, personas represent user groups; in an artifact, they can be supported with demographic and other data. Application designers can devise personas according to the target user base and associate them with product use cases. Once you profile them, you can reuse personas, with slight modifications to accommodate different application contexts. Eventually, RUP plug-ins might offer sets of adaptable personas covering a great range of users, including those with a variety of disabilities. Designers could then adapt these to their specific project context.

Adding accessibility evaluation points

Our recommendation is to include accessibility evaluation points in RUP that are based on common accessibility standards and guidelines, and available for a variety of runtime platforms. Each evaluation point would provide platform-specific information relating to each persona in the plug-in set and be classified according to the categories we outlined earlier: essential, important, beneficial, neutral, inconvenient, impeding, or excluding. Application designers could then choose a set of relevant accessibility evaluation points based on their chosen personas. Ideally, both personas and their corresponding evaluation points would be supplied by vendors whose tools support a semi-automated testing process based on RUP.

Adding an accessibility manager role

We propose the addition of a new RUP accessibility manager role that would oversee process tailoring to reflect accessibility-related standards and guidelines employed by the organization and project. The person(s) who assumes this role would conduct expert reviews and serve as an advisor for project accessibility issues. However, the actual work of designing accessible products for target users is still the responsibility of project team designers, developers, testers, and others in hands-on roles. The organizational goal must always be to integrate and engrain accessible design principles into existing development team process and practices.

To support these three major additions to RUP, organizations would also augment some existing process elements to reflect accessible design principles. For example:

• Add an "Accessible design" concept page describing principles for enhancing and extending usability in software development, listing RUP activities that are relevant for accessibility, and providing references to important literature and standards.
  
  
• Extend RUP workflows with accessibility-related activities, modifying existing workflow details rather than adding new ones.
  
  
• Update artifacts, such as checkpoints, templates, and reports, to accommodate accessible design principles. For example, the Software Architecture Document could have an additional section on accessibility.

Back to top

Conclusion

This article briefly outlines an integrated approach for developing accessible software applications through use cases and personas that drive product development and dictate evaluation points for iterative testing. Embedding this approach into a proven process framework, such as RUP, is an ideal way to introduce it into a development organization. Eventually, RUP plug-ins could be developed to integrate elements of this approach into the standard RUP framework.¹³

Beyond the concepts we have described, development teams could apply architectural patterns and user interface patterns to generate code that meets the needs of their target personas. In RUP, these patterns could be made available as design mechanisms that would increase code quality and boost development productivity.

In conclusion, we hope that this article will spur "inclusive thinking" among application development organizations, encouraging them to practice user-centric planning and build accessibility features into software products right from the beginning -- rather than treating them as an afterthought late in the development lifecycle. We also hope that tool vendors and third-party suppliers for RUP and other development frameworks will begin embedding an integrated approach for accessibility into their products.

For all software development organizations, we believe that the approach we describe in this article will ultimately increase productivity and application quality. In making products that are accessible and practical for all potential users, progressive organizations can take advantage of new market opportunities and gain a strong competitive edge.

Back to top

Acknowledgments

This work was partially funded by the National Institute on Disability and Rehabilitation Research, US Dept of Education, under Grant H133E030012. It was conducted at the Universal Interface and Information Technology Access Rehabilitation Engineering Research Center of the University of Wisconsin, Trace Center. The opinions herein are those of the authors and not necessarily those of the funding agency.

Back to top

Notes

¹ See "The Wide Range of Abilities and Its Impact on Computer Technology." Research Study by Microsoft, conducted by Forrester Research, 2003. Available at http://www.microsoft.com/enable

² See Application Software Design Guidelines, Version 1.1, 1-June-1994. Trace Center, University of Wisconsin (available at http://trace.wisc.edu/docs/software_guidelines/software.htm) and Web Content Accessibility Guidelines 1.0, W3C Recommendation 5-May-1999 (available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/).

³ See 1) American National Standards Institute (ANSI) Draft Standard for Trial Use (DSTU) 2003: "Human Factors Engineering of Software User Interfaces." Human Factors and Ergonomics Society, Santa Monica, California and 2) ISO TS 16071:2003: "Ergonomics of Human-System Interaction: Guidance on Accessibility for Human-computer Interfaces

⁴ For a list of accessibility standards and guidelines, see the Access Technologies Group Web site: http://www.accesstechnologiesgroup.com/Resources

⁵ See "Design Accessible Sites Now," Forrester Report, Dec. 2001. http://www.forrester.com/ER/Research/Report/Summary/0,1338,11431,00.html

⁶ Philippe Kruchten, The Rational Unified Process: An Introduction. Addison-Wesley, 2004.

⁷ See Ivar Jacobson, Object-Oriented Software Engineering: A Use-Case Driven Approach. Addison-Wesley, 1992.

⁸ Philippe Kruchten, The Rational Unified Process: An Introduction. Addison-Wesley, 2004.

⁹ See Alan Cooper, The Inmates Are Running the Asylum. SAMS/Macmillan, 1999.

¹⁰ By superstitious behavior, we mean that a person continues to do something in a certain way that does not correlate with necessity -- just because it worked that way before. For example, a phone user might always turn off his phone at the end of a call because his previous telephone required him to turn off the phone in order to hang up. Or, certain computer users might always fully delete and reenter information into a new record rather than just editing the old record -- a vestigial behavior associated with older technology. Or, someone who does page layouts might always use a certain format because she received it as a rule of thumb from another designer -- not because she understood the basis for that designerÂ’s decisions. In other words, people engage in superstitious behavior when they continue to do what they used to do without questioning or understanding why -- even if the action is no longer necessary or sufficient within the current context.

¹¹ See Paul Szymkowiak and Philippe Kruchten, "Testing: The RUP Philosophy." The Rational Edge, February 2003.

¹² See Jim Heumann, "Generating Test Cases from Use Cases." The Rational Edge, June 2001.

¹³ See Web Content Accessibility Guidelines 1.0, W3C Recommendation, May 5, 1999 (available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/).

¹⁴ Although the issue of making RUP itself accessible to development team members with disabilities is beyond the scope of this article, we are currently giving special thought as to how visually impaired people might pursue the best practice of "visually modeling software" through alternative means.

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Embedding accessibility design in the development process
• Integrating accessibility principles into RUP
• Roadmap for universal design with RUP
• Conclusion
• Acknowledgments
• Notes
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Try Rational System Architect

See how this fully integrated collection of models and documents can help you better align your IT systems and infrastructure to simplify business processes

Special offers