... application development due to not consider accessibility in software life cycle together to ... The development process of accessible web applications does not require a specific methodology .... Good structural marking and good contents in ...
DRAFT VERSION Lourdes Moreno, Paloma Martínez, Belén Ruiz-Mezcua. Inclusive Usability Techniques in Requirements Analysis of Accessible Web Applications, 1st International Workshop on Web Usability and Accessibility (IWWUA 2007) in conjuntion with WISE, 2007, Nancy, France, January, 2007, Springer Berlin / Heidelberg, ISBN: 978-3-540-770, Volumen: LNCS 4832-0423, Páginas: 423-428, url.
Inclusive Usability Techniques in Requirements Analysis of Accessible Web Applications Lourdes Moreno, Paloma Martínez, and Belén Ruiz Computer Science Department, Universidad Carlos III de Madrid Madrid, Spain {lmoreno,pmf,bruiz}@inf.uc3m.es
Abstract. To follow accessibility standards does not guarantee complete accessible web applications. There are difficulties in web application development due to not consider accessibility in software life cycle together to forget important aspects in user interaction. A proposal to evaluate the benefits of using usability techniques with inclusion in the analysis phase of a web application development is presented. Keywords: Accessibility, Software Engineering, Inclusive Design.
1 Introduction The vertiginous growth in the use of Internet with more and more people using the Web makes necessary an advance of technology devoted to avoiding the exclusion of user groups. Due to the fact that not everyone has access to the Web in the same way, it is necessary to take into account this diversity to provide full accessibility to the Web contents. Designers usually find difficulties in the design of accessible web pages because of scarce and inadequate methodologies and tools. The majority of the these tools aren’t integrated in the development software but are designed to be used a posteriori, in evaluation phase, when detecting barriers increments costs, need of resources and sometimes it is even impossible to achieve a solution. It is necessary to include this in the cycle of process development, from its conception to the launch phase. Also if a technical approach based on meeting accessibility standards regarding web code is followed, it has the inconvenience of going away from the users experience and therefore questions of the interaction of the Web with important users and the access to it could go unnoticed. All of this leads to the necessity on integrating usability and accessibility in software processes following a User Centered Design (UCD) using usability techniques. The UCD [1] focuses on the idea of fulfilling user needs in every phase of the development process. It considers the following phases: analysis, design- prototypeiterative evaluation, implementation and maintenance. This iterative process allows evaluating the design during the development cycle and not only to evaluate the web page in its final stage. M. Weske, M.-S. Hacid, C. Godart (Eds.): WISE 2007 Workshops, LNCS 4832, pp. 423–428, 2007. © Springer-Verlag Berlin Heidelberg 2007
424
L. Moreno, P. Martínez, and B. Ruiz
The development process of accessible web applications does not require a specific methodology in itself; it only makes sense when the methodological approach includes accessibility criteria. Traditional standards that could be adapted are ISO/IEC 12207:1995, IEEE 1074-1997 for development processes for information system on the Unified Process for Object-oriented development. Proposals focused on web engineering with processes, models and adequate techniques to work with this type of information could be WSDM, SOHDM, OOHDM, UWE, OO-H, W2000, WebML amongst others.
2 Case Study: The Spanish Centre of Captioning and Audio Description (CESyA) A web site is currently being developed for the recently created organism, CESyA [2]. It works towards the accessibility in audiovisual media using captioning and audio description services. One of the requirements that should be fulfilled is that the web has to be usable and accessible according to the standard WAI accessibility, coinciding in this particular case that amongst potential users disabled people are found. Some experiments have been carried out on this web site to enable the evaluation of the consequences that would imply applying or not inclusion in the analysis phase. In this experimentation two development processes have been carried under the same domain, but with different ways to act in the capture of requirements. In the so-called “Inclusive Case” the work has been developed in the framework of Inclusive Design and not in the so-called “Non Inclusive Case”. The initial hypothesis was: the inclusive case needs fewer changes in the redesign of the interface, and consequently, has produced a reduction of costs in the development, avoiding new requirements to have in mind in the development phase. So, following the iterative model, the case study which needs fewer changes in this evaluation will have a smaller or inexistent increment in the next process iteration. The analysts’ team and the participants in the following phases in both experiments have similar characteristics. They do not have experience in design and development of accessible web applications but they have been given some training in accessibility items based on the WAI [4] documentation. The web applications that are being developed are based on similar technological profile with a basic core (WCAG1.0+XHTML+CSS with procedures for the dynamic contents). 2.1 User Modeling In the user modeling tasks, several user groups have been taken into account in order to analyze their necessities in the CESyA area. These groups have been defined under the consideration of common attributes amongst users according to their access characteristics such as age, profession, frequent use of internet, information needs and software used, such as different browsers, players, etc. These common attributes which enable to model groups have been obtained through to investigation, interviews with clients and users, surveys, etc.
Inclusive Usability Techniques in Requirements Analysis
425
Once these attributes and values have been established, we have an approximation to all the users we want to reach to, and some User profiles considering common attributes. In the Inclusive Case, more attributes are considered both in user’s characteristics, for instance, whether user has a disability or not, and in access characteristics, for instance, special browsers as well as only text browsers, adapted assistive hardware technology amongst others. Taking into account these new variables causes an increment of the number of users and contexts of use which need to be studied. Consequently, a new approach in modeling users is needed so that the study could be feasible. A first approximation of optimizing this task could be: a) the interaction of people without disabilities with the computer in an unfavorable context, b) the interaction of people with disabilities in normal environments or where the accessibility of the product does not vary. In this way, it will result more viable to give coverage to a greater number of users. As a second approximation, the application of scenarios, described in the next section, is considered. 2.2 Scenarios with Characters With the approach of Scenarios with characters, the size of sample is minimized by studying various User profiles in only one scenario. The Inclusive case does not mean an exaggerated additional cost and additionally web designer becomes familiar with the user and designs taking into account his/her characteristics. The majority of the audience has been covered due to the creation of seven imaginative Scenarios in the case of the Non Inclusive Case and ten Scenarios in the Inclusive Case (see figure 1). But in the Inclusive Case, as we have to keep in mind factors such as the use of magnifiers, screen readers, etc, we must investigate matters that will affect the future design of the user interface such as: how users with screen readers will access information, how to access it with a magnifier, how is someone supposed to design and write texts to make them more comprehensible, etc. These aspects of the accessibility in the Inclusive case have proactively been considered for the future design phases. 2.3 Card Sorting Starting from the users´ behavior, the objective is to understand how users imagine the organization of the information and how they collect concepts and by means of this understanding the mental model of the user. In the Non Inclusive Case we assume that it is enough to facilitate the access to the information by following the guidelines, and that mental organization of how to organize the web information is independent from the access characteristics of web users. In the Inclusive Case it has been found, with the help of real users with disabilities, a diversity in some groups. Therefore, interviews allow us obtaining valuable information about (a) detecting possible barriers modifying the architecture of
426
L. Moreno, P. Martínez, and B. Ruiz
Fig. 1. A scenario for the CESyA web according to the Inclusive case
information and (b) the design of post phases knowing that the elements of the architecture could have problems which would require attention and reinforcing its design.
3 Analysis of Testing Results There are many factors that have been detected in the Inclusive Case in relation to the Non Inclusive one that are necessary to have in mind in the design phase. These included: (1) different types of hardware and software access can produce accessibility barriers, especially in the indirect access to the web by users who need assistive technologies, (2) different levels of browsing in the in different groups of users, etc. (3) Concerning the information architecture, different mental models where information is clustered.
Inclusive Usability Techniques in Requirements Analysis
427
Table 1. Some problems and improvements in user testing barrier/ improvement
NON INCLUSIVE CASE
INCLUSIVE CASE
description link
Non-adequate attribute title . The links have to be more descriptive
Few observations. Contextual information is given, the attribute title with value
Icon and decorative image
The decorative images are labelled in XHTML with the alt = " text equivalent " attribute
No observations, the decorative image with the alt =” “ and icon is included in CSS with a correct marking in the XHTML
Invisible shortcuts
Inexistent. The users have suggested them as an improvement.
No observations, they do exist to skip the initial browsing and go to the main content
Visibility edges interface
Presence of navigation menus in the corners but the users with magnifiers do not see them.
No observation. There are no elements situated in the corners or edges of the interface
Types of text Font
The font type used is Verdana. The users would prefer bolder fonts.
No observations. Arial is the font type used from the Sans Serif family, very legible according to literature.
Language accessibility
Many problems have been found in the comprehension of the texts.
Few problems have been detected but it is an area for improvement.
Structural marking
Disabled users have asked for a better structural marking, better definition of the header elements
Few observations. Good structural marking and good contents in relation to defined the Arquitecture of the information
redimensions design
Although relative units according to WCAG 1.0 have been implemented users have observed that precision is lost in the design of the presentation when making bigger or smaller the font size
No observation. Precision is lost in the design of the presentation when changing the font size in 3 levels, considered an exception on the web.
Multimedia elements
Users have asked for control options for the user, of information, format types, time, weight, etc. Some users could not access this resource
Few observations: The following procedures have been tried: accessible audiovisual content (with caption and audio description) and a facilitated access (with download, progressive download or streaming) + intuitive and usable access to the user (control, format, connection, size, time information).
Panoramic screen
There is a loss in the precision in the design of the presentation due to the flexible design
No observation. Precision is not lost in the design of the presentation or in the use of the hybrid model
Different browsers
Loss of precision of the presentation in some browsers
No observations. The same presentation is assured in the different browsers
As a hypothesis, the two prototypes implemented according to the two analysis cases, Inclusive and Non Inclusive Case are to comply the WCAG 1.0 (level AAA). Regarding usability, on a earlier stage of the prototype, there were two heuristic evaluations. According to obtained results, barriers and improvements were found and, in both cases, they were corrected. About these prototypes, a more extensive accessibility evaluation was taken following the WAI methodology and the usability, such as: 1) Expert and Manual revision following Validation Methodology WAI. 2) A test was made with users in both cases, including people with or without disabilities and diverse conditions of usage to evaluate usage aspects and access in both prototypes. This test has been based on the questionnaires and forms that users have filled in: • Forms where the accessibility characteristics and context of use are reflected, as well as software and hardware characteristics in tests development. • Questionnaires to evaluate usability according to heuristic evaluation, and accessibility of the different areas of the Web. The most important enhancements in accessibility, as was suggested by users according to the test carried out, are shown in table 1. These items have been
428
L. Moreno, P. Martínez, and B. Ruiz
translated into new needs included in the Non Inclusive Case in this stage of the development process. This provokes a new re-design phase different to the inclusive case, which confirms the initial hypothesis.
4 Some Conclusions The benefits that the WCAG 1.0 guidelines are well known, and their help is undoubtedly fundamental for designers. The UCD framework with the use of usability techniques allows us to come closer to the necessary user, but the benefits of the inclusion [3] in the analysis phase after this experimentation are distinguishable. From WCAG 1.0 we have seen that accessibility guides provide better knowledge about detecting barriers and accessibility evaluation applicable a user interface prototype in an advanced phase of Design-Evaluation, than knowledge about how to design in analysis phase. For professionals without previous experience in the development of accessible web applications, the guides make knowledge obtained in the inclusive case an added value. Validation carried out with user’s participation has shown this, due to the fact that guidelines do not make explicit which are the success factors in the compliance of accessibility and usability requirements. The Analysis Phase of the Inclusive Case evidently requires more effort and is more costly than the Non Inclusive Case. On the other hand, this cost is viable as it has been previously explained, due to the approximations to the modeled user. But in the experimentation, it has been proved that this knowledge, not obtained in the Non Inclusive Case, requires in the iterative process of development an increment of accessibility much more costly with more adjustments in the design. We are working in a methodology that includes the accessibility into Software engineering process. Precise methodologies to help those professionals in designing and developing accessible Web applications are necessary.
References [1] Bevan, N.: Usability Net Methods for User Centred Design. Human-Computer Interaction: theory and Practice (vol 1). http://www.usabilitynet.org/tools/13407stds.htm (2003) [2] Centro Español de subtitulado y Audiodescripción (CESyA), http://www.cesya.es, http://www.rpd.es/cesya.html (2006). [3] Newell, A.F., Gregor, P.: User Sensitive Inclusive Design: in search of a new paradigm. In: En: CUU 2000. First ACM Conference on Universal Usability (2000) [4] W3C, Web Accessibility Initiative (WAI) http://www.w3.org/WAI/ (2006)
