...applications (similar to the Web version of Turbo Tax **), claims-processing systems (similar to those used inside insurance companies), workload-management systems, correspondence-routing systems, and call-center systems. Such applications require complex navigation, extensive data entry, conditional relationships among different data elements, and multiple interrelated user tasks. The baseline software architecture for the front end of these Web applications is DHTML (dynamic HTML), which is dynamically produced using Java ** technologies. DHTML may include HTML (Hypertext Markup Language), CSS (Cascading Style Sheets), and JavaScript **.

There are several common challenges encountered when working with project teams to improve accessibility. One is lack of comprehensive guidelines that apply to interactive Web applications. While there are many published sources of information on Web site accessibility (1,2) and the needs of users with disabilities, existing Web accessibility guidelines typically focus on the design of static informational Web sites or basic Web forms (4-9) and do not address design issues that typically arise in complex software applications. They generally discuss each individual accessibility issue in a vacuum, without addressing external design constraints or the interrelation of issues. Moreover, the introduction of accessibility into an application that is already fully developed can involve significant redesign and recoding, which may be considered outside the project's scope and budget. Obtaining input from accessibility specialists before coding starts (during user-interface design and specification) reduces the risk of rework but does not eliminate the need for significant manual testing and recoding. For this reason, it is important to look across suites of related applications and identify ways of supporting accessibility through the use of reusable components that consistently implement common business rules, design requirements, and other site-wide functionalities, including accessibility.

Two of the authors recently completed an analysis of documented accessibility violations and recommendations; in the analysis more than 1,300 accessibility issues, which were identified during evaluations of 80 software applications over a three-year period, were compiled and categorized. This analysis led to the creation of a list of "Top 20" accessibility issues, (10) which we have used in developing user-interface standards and in reviewing the architectural implications of accessibility.

Although we considered a wide spectrum of disability types, we discovered a stronger emphasis on vision-related disabilities than on other disabilities. There are probably several reasons for this emphasis, including the fact that vision-related challenges to access are the most numerous and significant, the access solutions are relatively feasible, and the fact that people with vision-related disabilities are some of the most active participants in the job market and some of the strongest advocates for their causes. This paper does not discuss the full list of recurring accessibility issues; instead, it focuses on those issues that can be addressed within an intermediate architectural layer of reusable software components. We argue that addressing accessibility issues within such an architecture can significantly enhance accessibility, and failing to address them within such an architecture can significantly limit accessibility.

Accessibility and usability

Software is accessible when the user interface is designed to meet the special needs of people with disabilities, allowing them to use software in a manner that is similar to the way that people without disabilities use it. Disabilities may include a limited ability to see, hear, or move (including using a keyboard or mouse), or to process certain types of information easily or at all. Software accessibility is often accomplished by ensuring that necessary information about user-interface elements is available to various assistive technologies, such as screen readers for users who are blind, magnification software for users who have low vision, or speech input software for users with mobility impairments. Although Section 508, (11) the World Wide Web Consortium Web Accessibility Initiative (12) (W3C ** WAI), and even the ADA (13) (Americans with Disabilities Act) seek to recommend or mandate various accessibility standards, our primary focus is on the shared goal of all such standards: ensuring that users with disabilities can use software effectively and with a reasonable amount of effort.

Accessibility is closely related to usability, the art and science of ensuring that software is efficient and effective to use and that its use is satisfying for users. Usability practitioners sometimes consider accessibility to be a subcategory of usability, despite the fact that, in practice, accessibility is usually handled separately from usability. Although the goals of accessibility and usability are similar in many ways, the specific design enhancements needed to support usability for a general audience and accessibility for users with disabilities may differ significantly and may pose conflicting goals. In addition, different groups of users with disabilities have different needs. Our experience in balancing the needs of these different user groups has led us to conclude that in some situations, one solution for all users is not desirable. (14) The idea of multiple views tailored to the needs of different user groups is explored further in this paper.

Software architecture

There are numerous definitions of "software architecture" in the technical literature. (15) Essentially, software architecture describes the organizational structure of a software system including components, interactions, and constraints. Architectural interactions are abstractions for how components interact in a system. An architecture includes the constraints on component selection and the rationale for choosing a specific component in a given situation. (16) For our purposes, software architecture describes the function of components of a system, including their interaction with each other.

There are many different aspects to the architecture of a system, including the computer hardware, software, and network. Even though this paper discusses software that is developed using a DHTML front-end architecture, our focus is on an intermediate application layer. This layer is located between the back-end processes or databases (or both) and the presentation-layer technologies (such as HTML, CSS, server-side scripting [e.g., Java-Server Pages **] and client scripting [e.g., Java-Script **]). In addition to the business-logic code, this intermediate application layer includes typically proprietary common reusable software components. Just as most software is not designed to run directly on top of an operating system, complex systems are commonly built in development environments that include such an additional layer. This layer of software components includes tools, functions, and 2estrictions that form the core design and basic architecture of the site or the applications on a site. It consistently implements common business rules, design requirements, and other site-wide functionalities. When such an intermediate architectural layer is used, it can serve either to limit accessibility if it is not designed with accessibility in mind or to enhance accessibility if it is designed with accessibility in mind.

In recent years, several authors have begun to describe the relationship between usability and architecture. Bosch described a direct relationship between architectural decisions and the ability to meet quality requirements. (17) Juristo, Moreno, and Sanchez researched the architectural implications of usability issues and pointed out the danger of assuming that usability only affects the presentation component of software systems. (18) John and Bass (19) have done extensive work on this subject and have illustrated how, despite the best efforts of architects to create modularized software that facilitates changes, it becomes difficult to meet user-experience requirements after architectures are already defined. Reference 19 describes a scene in which usability issues are presented, and one of the developers exclaims, "Oh, no, we can't change THAT!" The problem is that the requested modification reaches too far into the architecture of the system to allow economically viable and timely changes to be made. Even when the functionality is correct and the user interface is separated from that functionality, some architecture decisions may unknowingly limit the ability to implement usability requirements. Bass, John, and Kates have published a collection of architecture patterns intended to help architects anticipate and accommodate usability. (20)

Although these works do not directly address accessibility issues, the relationship between usability and architecture is similar to the relationship between accessibility and architecture. In our experience, a common reason given by development teams for declining to implement accessibility features or enhancements in complex Web applications is a lack of architectural support and the cost in time and money involved in implementing enhancements that require architectural modification. Conversely, after an accessible solution is built into the architecture, it is much easier to consistently extend that solution across multiple applications. In light of this, the goal of this paper is to extend the existing work on the relationship between usability and architecture by providing a set of architectural recommendations to improve the user experience for people with disabilities.

ACCESSIBILITY ISSUES AND SOFTWARE ARCHITECTURE SOLUTIONS

This section provides specific information about addressing accessibility within an architecture of reusable software components.

Using libraries of reusable objects

A common challenge in developing accessible applications is the significant knowledge gap that exists between software developers and accessibility specialists. Most developers do not have experience or training in coding for accessibility, and most accessibility specialists have limited programming training or experience. These specialists may not be able to provide sample code that developers can use to achieve the desired results. This leads to inconsistent results; for example, different developers have varied levels of accessibility awareness, and even when they do implement accessibility features, they may use different approaches, or code the same approach differently. In addition, even when accessibility features are implemented properly, they must still be manually applied to each individual...

NOTE: All illustrations and photos have been removed from this article.



More articles from IBM Systems Journal
An architecture and applications for speech-based accessibility system..., September 01, 2005
Evaluating accessibility by simulating the experiences of users with v..., September 01, 2005
Managing usability for people with disabilities in a large Web presenc..., September 01, 2005
A proposed architecture for integrating accessibility test tools., September 01, 2005
Are guidelines enough? An introduction to designing Web sites accessib..., September 01, 2005

Looking for additional articles?
Search our database of over 3 million articles.

Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication name or publication date.

About Goliath
Whether you're looking for sales prospects, competitive information, company analysis or best practices in managing your organization, Goliath can help you meet your business needs.

Our extensive business information databases empower business professionals with both the breadth and depth of credible, authoritative information they need to support their business goals. Whether it be strategic planning, sales prospecting, company research or defining management best practices - Goliath is your leading source for accurate information.