Articles
Software Learning
Designing software architectures to facilitate accessible Web applications INTRODUCTION
As consultants to the United States Social Security Administration, a government agency that is committed to accessibility, we have maintained a focus on improving the user experience for all users of our Web applications. These applications include sophisticated data-entry 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 a 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 restrictions 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.
IBM Systems Journal, Sept, 2005 by David Hoffman, Eric Grivel, Lisa Battle
Article Source: http://www.findarticles.com