Toward User-Centered, Scenario-Based Planning and Evaluation Tools

Shifting the Focus to Usability

By analyzing the needs, abilities, constraints, and usage patterns of people with disabilities across an entire web site, it is possible to shift the focus of developers from a “compliance” mentality to a more beneficial focus on the usability of the end product. This kind of shift of focus has been evident in the way that the World Wide Web Consortium (W3C) has approached version 2.0 of its Web Content Accessibility Guidelines (WCAG) [1]. Whereas WCAG 1.0 [2] presented developers with a list of do’s and don’ts mostly within the technology of HTML, WCAG 2.0 takes a more holistic approach that spans current and future technologies, with the goal of providing broadly applicable principles, rather than isolated techniques. In the current working draft of WCAG 2.0, there are four broad principles under which all of the more specific guidelines and techniques are subsumed. These principles advocate that content should be:

• Perceivable – the user should be able to “get at” the content.
• Operable – interface elements must be usable.
• Understandable – the content must be organized and presented in a way that makes sense to the user.
• Robust – the content can be used with current and future technologies.

These principles can be applied to single web pages, but their real power is in their applicability across the web site as a whole. In broad terms, if only most of the site is designed with accessibility in mind, then people with disabilities will be able to access only most of the site. If key sections of the site are not operable by keyboard, or if these sections are operable but not readily understandable, or if the core principles of WCAG 2.0 are somehow violated, then the overall experience of some users will be unfavorable. They might not be able to do what they wanted to do on the site at all. They will not be able to buy the book they were hoping to buy, or to find the information that they needed to find, or to sign up for the class that they needed to take. Whatever the user’s purpose for going to the site, it is the overall scenario—the user’s goals, the user’s actions, the user’s physical constraints—that must be examined in their entirety, otherwise the usability of the site may suffer.

User Characteristics and Constraints

Types of users must also be considered. Characteristics such as age, gender, interest, and disability type are integral to the planning process. Within disability types are a few major categories:

• Visual disabilities (blindness, low vision, color blindness)
• Deafness
• Motor disabilities (slow movement, inability to use a mouse, etc.)
• Cognitive disabilities (reading disorders, attention deficit disorders, etc.)
• Seizure disorders

Each of these types of disabilities affects a person’s ability to access web content in specific ways. For example, a blind person using a screen reader will need alternative text for all non-text content, keyboard access to all functionality, logical linear progression through the page and through the site, etc. It is beyond the scope of this paper to detail all of the specific needs of these disability types, but one point that must be emphasized is that each disability type must be considered within each scenario of web site functionality. People with the different types of disabilities must be able to proceed through the entirety of the scenarios without obstacles. Ideally, the web site would also be optimized to make the site not only accessible in a technical sense, but usable in a human sense. User-centered, scenario-based planning makes this possible.

Identifying Patterns in the User Experience

Patterns are important whenever users interact with data. An example of a usability pattern is the “warning” pattern. This pattern occurs when the user is about to perform an irreversible action—whether on purpose or accidentally, and whether the user understands the consequence of that action or not. To protect the user, the solution is to warn the user that the action is irreversible, and then provide the user with the choice to either proceed or cancel the action. This simple feedback can help prevent accidents or misunderstandings.

The concept of identifying patterns in the user experience is hardly a new one. The architect Christopher Alexander applied this approach to the design of buildings in a physical space [3]. Software engineers soon recognized the value in applying this kind of approach to the design of virtual environments. Trygve Reenskaug and others developed the influential Model View Controller (MVC) pattern language while working on SmallTalk-80 at Xerox PARC during the 1970s [4; 5; 6]. Though the idea is not new, it has not yet been fully applied to the realm of accessible Web design.

There are many attempts at creating pattern languages, but the simplicity of MVC allows for a basic discussion of the important ideas without losing sight of their relevance to web accessibility. The Model View Controller pattern addresses the problem of separating hardware and software into three main areas of functionality. First is the data model. Data must have a structure for the computer to work with. Next is the view. This label is a bit of a misnomer, especially in the context of disability issues, but the term refers to data as the user perceives it, whether visually on a computer monitor, aurally (by listening) through synthesized voice output, or haptically (by touch) through a refreshable Braille device. What the user perceives and what the computer perceives are oftentimes very different. The last item is the controller. The controller manages changes to the data model. Controllers reflect the user’s manipulation of the data via input devices such as mouse and trackball devices, keyboards, eye tracking systems, Braille devices, voice recognition software, and so on. By expanding the definition of “view” and “controller” to include a variety of output and input modalities, designers will be able to incorporate these scenarios, or use cases into their thought processes and later into their designs.

User-Based Scenarios within Tools

Within each broad scenario, it is necessary to consider the characteristics of different types of users with disabilities. Using the “warning” pattern again as an example, not all users will benefit from the same type of warning. A deaf user will not benefit from an audible error “buzzer.” A blind user will not benefit from an error graphic (unless it has appropriate alternative text). A person with slow muscle movements may not benefit from an error message that requires the user to react within a set amount of time, especially if that amount of time is brief.

The pattern characteristics of most of these user types are at least somewhat predictable, in the sense that developers can anticipate the appropriate sensory modalities, and/or physical constraints of the different categories of disabilities. These characteristics can be programmed into planning and evaluation tools so that the tools can navigate the web site in ways that replicate both the scenarios and the users’ characteristics. In essence, the tools can walk through the site, performing the same functions that real users would perform, and then evaluate the accessibility and usability of each of the steps along the way, from the perspective of users with disabilities. The tools can follow multiple paths within each disability type. For example, in an e-commerce scenario, the tool could:

• Follow an error-free path of selecting the merchandise and proceeding through all of the steps necessary to purchase it
• Enter in mistakes along the way, such as a faulty email address, or incorrect password
• Empty the shopping cart then add more items to it
• Return to shopping several times after entering multiple items into the shopping cart
• Etc.

The tool might be able to recognize and execute some of these patterns automatically, with built-in algorithms that recognize common scenarios in e-commerce situations. The tool could even be designed to “learn” such patterns based upon parameters that the tool users set over time. Where such pattern recognition is not possible, the tool could still be instructed to perform a set of pre-planned actions within a web site, as defined by the tool users.

Tools for Different Types of Developers

Variations on this basic idea allow for the creation of a conceptual planning tool that anticipates potential problems before any code or HTML is written at all. Planning tools of this nature could be designed for different types of audiences. Programmers could benefit from a tool that worked and acted like a Unified Modeling Language (UML) environment [7]. Designers could benefit from strictly conceptual tool that worked somewhat like an interactive flowchart or even a paper prototype process [8].

Final Thoughts

It is not enough to say that a web page passes an accessibility evaluation tool. People with disabilities are not interested in accessibility on a page-by-page basis. They are interested in the accessibility of their entire interaction. People go to web sites with some sort of purpose in mind. This purpose is what constitutes the scenario. Users of different kinds, with different types of disabilities will likely engage in the same overall types of interactions, or scenarios, so the characteristics of these users must be taken into account. This sort of user-centered, scenario-based planning and evaluation is the key to ensuring that the entirety of the user’s experience is taken into account when considering accessibility and usability.

Though they don’t exist yet, tools can be created to take advantage of patterns in these scenarios and user characteristics. These tools can be used to plan user interactions that are both usable and accessible. They can also be used to evaluate existing web content. Only when tool developers concentrate on the user experience as a whole—rather than on individual pages at a time—will these tools reach the level of maturity required to truly transform the web into an accessible and usable experience for the broadest range of users.

References

1. W3C: Web Content Accessibility Guidelines 2.0, http://www.w3.org/WAI/GL/WCAG20/ - external link, W3C internal Working Draft, 14 February 2004, accessed 14 April 2004 (2004).
2. W3C: Web Content Accessibility Guidelines 1.0, http://www.w3.org/TR/WCAG10/ - external link, accessed 14 April 2004 (1999).
3. Alexander, C. et al. A Pattern Language, Oxford University Press, New York, (1979).
4. Reenskag, T. M. H.P: Thing-Model-View-Editor—An Example from a Planning System. Technical note, Xerox PARC, (May 1979).
5. Reenskag, T. M. H.: The Model-View Controller (MVC), Its Past and Present. Paper presented at JavaZone 2003, Oslo, Norway (2003).
6. Buschmann, F.: Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley and Sons, Inc., New York, NY (1996).
7. Object Management Group: Unified Modeling Language, version 2.0, http://www.omg.org/mda/ - external link, accessed April 2004.
8. Snyder, C.: Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann, San Francisco, CA (2003).