Web Accessibility and Collaboration to Support Learning for Blind People

Autore:

Ing. Giulio Mori

Relatori:

Ing. Alessio Bechini Dott. ssa Maria Claudia Buzzi Dott. ssa Marina Buzzi

Web Accessibility and Collaboration

to Support Learning for Blind People

Anno 2012

UNIVERSITÀ DI PISA

Scuola di Dottorato in Ingegneria “Leonardo da Vinci”

Corso di Dottorato di Ricerca in

INGEGNERIA DELL’INFORMAZIONE

ABSTRACT

The increasing spread of the Information Technology (IT) and multimedia devices, along with the impressive growth of Web 2.0 applications (wikis, social networks, blogs, etc.), have radically changed communication and ways of acquiring information and knowledge. Collaboration between individuals in combination with an active, enriched sensorial experience for the user, have produced new paradigms for learning and teaching, compared to the classic passive methods of the past. Unfortunately, enriched and multimedia applications are usually designed for the sighted, and are often ineffective for blind users, who typically interact with a computer by screen reader via vocal synthesizer and a keyboard. This thesis investigates the design of accessible and usable Web e-Learning tools and specifically collaborative environments to support learning for blind people, overcoming their difficulties during the interaction. After a description of the main difficulties encountered by blind users when interacting via screen reader, and the basic principles for creating accessible interfaces, the design, implementation and test of several prototypes for improving the learning experience of blind people will be described.

Specifically, a prototype of a Web tool for transforming digital documents into structured audio podcasts (according to the document structure) that has been designed and developed, will be presented. The structured audio podcasts (one mp3 file for each document section) are downloadable via Web and loadable on an mp3 player. Structured podcasts represent an effective tool for blind students who wish to explore document contents during the critical phase of surveying educational material. User tests of the system performed with blind users have highlighted their appreciation for structured audio podcasts compared to a time division method (e.g., 5 minutes per podcast). Furthermore, the W3C WAI-ARIA-based system interfaces have been evaluated successfully by blind users, who considered them easy to navigate and explore. The system provides other facilities for audio emphasizing some visual information embedded in the document (bold, italics, tables, etc.). The system also generates special audio formats (i.e., Rockbox and DAISY) to facilitate exploitation of educational material on a portable audio device.

Furthermore, the new cooperative learning paradigm shows how active participation and collaborative interaction are fundamental for improving the learning experience. However, e-learning collaborative environments are complex and rich in dynamic content and therefore complex to access for a sightless person. Therefore, we investigated accessibility and usability via screen reader of Web collaborative editing tools, selecting Google Docs as a case study. A modified version of the Google Docs interfaces designed and implemented to fix detected accessibility problems will be presented. Moreover, an accessibility inspection of the main collaborative functions of Google Docs was performed, also considering the importance of the awareness. The analysis of main groupware features of typical collaborative tools and the experience on Google Docs have provided us with interesting indications regarding the design of accessible and usable interfaces for cooperative tools.

TABLE OF CONTENTS

ACKNOWLEDGMENTS ... 1

LIST OF FIGURES ... 3

LIST OF TABLES ... 7

1. INTRODUCTION ... 9

1.1 Main Aims ... 10

1.2 Overview ... 13

2. WEB USER INTERFACES INTERACTION PROBLEMS ... 15

2.1 Importance of Accessible and Usable Interfaces ... 16

2.1.1 Referral Guidelines ... 19

2.2 Blind User interaction ... 21

2.2.1 Screen Reader Limitations ... 23

2.2.2 W3C WAI-ARIA Suite ... 26

2.3 Importance of Testing Applications with Real Blind Users ... 27

2.3.1 Concrete Encountered Difficulties ... 27

3. DESIGN OF TOOLS TO SUPPORT E-LEARNING ... 29

3.1 Cone of learning... 30

3.3.1 Need of a new Paradigm of Learning ... 31

3.2 Design proper e-Learning Tools ... 32

3.2.1 Appropriate e-Learning Tools for Blind Users ... 33

3.2.2 Enriching the Sensory Learning Experience ... 33

3.3 Efficiency and Advantages of Audio Podcasting ... 35

3.3.1 Benefits of the Structured Educational Material... 37

3.3.2 USER TEST 1: Listening or Reading? ... 38

3.3.2.1 Main Target of Evaluation ... 38

3.3.2.2 Description ... 38

3.3.2.3 Results ... 39

3.3.3 Preparing Audio Podcasts ... 40

3.4 A Web System Delivering Educational Structured Audio

Podcasts... 42

3.4.1 System Architecture ... 42

3.4.1.1 Identification of the Section Titles ... 43

3.4.1.1.1 Heuristics... 44

3.4.2 Emphasizing Visual Information into the Audio Podcasts ... 45

3.4.2.1 Special Features ... 45

3.4.2.1.1 Additional Heuristics ... 46

3.4.3.1 The Web Input Interface ... 47

3.4.3.2 The Web Output Interface ... 48

3.4.4 Special Output Audio Formats ... 49

3.4.4.1 Rockbox ... 49

3.4.4.1.1 An interesting Future Alternative ... 51

3.4.4.1.2 Rockbox Tests ... 52

3.4.4.2 DAISY ... 52

3.4.5 Heuristics Valuation ... 53

3.4.5.1 Training Set... 53

3.4.5.2 Test Set ... 54

3.5 USER TEST 2: Impact of the Structured Audio Podcasts on Blind

Users ... 55

3.5.1 Main Target of Evaluation ... 55

3.5.2 Description ... 55

3.5.3 Results ... 57

3.6 USER TEST 3: Accessibility of the Web User Interfaces of the

Audio Podcasting System ... 58

3.6.1 Main Target of Evaluation ... 58

3.6.2 Description ... 58

3.6.2 Results ... 60

3.7 Technical Information ot the Audio Podcasting System ... 61

4. COLLABORATIVE ENVIRONMENTS ... 63

4.1 Collaboration Improves Learning ... 63

4.1.1 Computer Supported Cooperative Work ... 64

4.1.2 Groupware Features ... 64

4.1.2.6 Time and Space ... 66

4.1.2.7 Awareness ... 66

4.1.3 Related Works on Accessibility, e-Learning and

Collaboration ... 67

4.2 Google Docs: a Typical Groupware Environment as a Case of

Study ... 69

4.2.1 Accessibility Problems of Google Documents ... 70

4.2.1.1 Methodology ... 71

4.2.1.2 Results ... 71

4.2.1.3 Some Considerations ... 73

4.2.2 Modified Interfaces to Facilitate Blind User Interaction ... 74

4.2.2.1 Fixed Accessibility Issues ... 75

4.2.2.2 Discussion on the Modified Interfaces ... 78

4.2.3.1 Google Documents in Details ... 79

4.2.3.2 USER TEST 4: Evaluation of the Groupware Functionalities of Google Documents ... 83

4.2.3.2.1 Main Target of Evaluation ... 83

4.2.3.2.2 Description ... 84

4.2.3.2.3 Results ... 85

4.2.3.2.4 Improvement Proposal ... 87

4.2.4 Accessibility Analysis of the Groupware Functionalities of

Google Documents ... 88

4.2.4.1 Invite People ... 89

4.2.4.2 Get the link to Share, Email as Attachment, Send Message to collaborators ... 91

4.2.4.3 Seeing Who is Accessing ... 92

4.2.4.4 Publishing as a Web page ... 92

4.2.4.5 Upload ... 93

4.2.4.6 See Revision History ... 94

4.2.4.7 Comments Insertion ... 96

4.2.5 Discussion on the Awareness of some Groupware

Functionalities of Google Documents ... 97

4.2.5.1 Awareness in Groupware Applications and Shared-Workspace Context ... 97

4.2.5.2 Elements in the Workspace Awareness ... 98

4.2.5.3 Framework Techniques to Provide Workspace Awareness ... 100

4.2.5.4 Seeing Who is Accessing ... 101

4.2.5.5 See Revision History ... 102

4.2.5.6 Comments Insertion ... 106

4.3 Combining Accessibility, Collaboration and Awareness ... 107

4.3.1 Summarization of Benefits for the Users ... 107

4.3.2 Basic Guidelines for Accessible Collaborative Editing

Environments ... 108

5. CONCLUSIONS ... 111

REFERENCES ... 115

APPENDIX ... 123

APPENDIX 1 - USER TEST 1: Listening or Reading? ... 123

Questionnaire ... 123

APPENDIX 2 - USER TEST 2: Impact of the Structured Audio

Podcasts on Blind Users ... 126

Questionnaire Online ... 126

APPENDIX 3

– USER TEST 3: Accessibility of the Web User

Interfaces of the Audio Podcasting System ... 128

ACKNOWLEDGMENTS

I have always thought that we are masters of our destiny, but sometimes life is bizarre… because some “subtle threads” seem to guide us towards one direction rather than another…

A special thanks goes to Barbara Leporini and Victor M. R. Penichet: …that evening in an ice-cream shop in the August of 2008, you were really able to convince me, giving me the idea of starting the Ph.D. Program in Information Engineering. Barbara experience on the “world of the blind people”, together with Victor’s knowledge about the collaborative environments, have represented a precious help during this research.

I am very grateful to my tutors Maria Claudia Buzzi and Marina Buzzi, for giving me the opportunity to do this interesting research and for their invaluable support during my Ph.D. In 2008 after 9 years in research at CNR in Pisa, I was about to quit this job... and without the opportunity you gave me that year, probably I would have never got a permanent position as a researcher on the 16th December 2011. I have learned a lot from this extraordinary experience during these almost four years with you.

Many thanks to my internal tutor Alessio Bechini for his precious feedback.

Thank you to all participants of the performed user tests, because their precious feedbacks have contributed to the results of this thesis.

I would like to thank my father Marcello, to have me encouraged and sustained during this experience.

Many thanks to all people encountered during my life, which have in some way contributed conducting me to write this thesis.

Last but not the least, I am extremely grateful to my mother Paola and my grandparents Renato, Massimina and Lina for their priceless support they gave me during their life. I love you so much forever.

LIST OF FIGURES

Figure 1: Two examples of screenshots generated by the “Visual Impairment Simulator” [30]: the vision of a user with glaucoma (a); the vision of a user suffering

from diabetic retinopathy (b) [31]. ... 22

Figure 2: Basic keys to explore an interface with a screen reader. ... 24

Figure 3: The sequential mode of the screen reader to scan the interface elements, introduces many difficulties on the interaction.. ... 25

Figure 4: Cone of Learning (Dale 1969). ... 30

Figure 5: A Web Syndication with RSS feeds notifies the user about the updates of a Web site. ... 36

Figure 6: Extraction of the structure of a document. ... 37

Figure 7: Users’ age of the test 1 sample. ... 39

Figure 8: Distribution of the mp3 players users on the basis of the age. ... 39

Figure 9: Typical methods to create audio podcasts: (a) recording live events, (b) personal recording, (c) using a software converter (e.g., vozMe).. ... 41

Figure 10: Architecture of the Web “Automatic Structuring Text for Audio Learning System”. ... 43

Figure 11: Auditory usage of the structured podcasts on an mp3 player. ... 46

Figure 12: The Web input interface of the system. ... 47

Figure 13: The Web output interface of the system. ... 49

Figure 14: Example of the file-system structure on a Rockbox player. ... 51

Figure 15: Rockbox simulator of the Sandisk Sansa e200. ... 52

Figure 16: The Olympus DM-5 mp3 reader and the “Book Wizard Reader” software. ... 53

Figure 17: Partial screen shot of one Italian online questionnaire supported by vocal alerts. ... 59

Figure 18: The Time-Space matrix. ... 66

Figure 19: Google Documents is an instance of Google Docs for editing or sharing documents online. ... 70

Figure 20: The Google Documents main interface divided into functional areas. . 72

Figure 21: An inaccessible dialogue window showing an informative message. .. 73

Figure 22: The Landmarks window. ... 76

Figure 23: Implementation of a hidden label. ... 76

Figure 24: The modified main interface of Google Documents. Each one of the 5 areas has been associated with a standard WAI-ARIA landmark and with a personalized label. ... 77

Figure 25: The modified interface of the editor. ... 77

Figure 26: A huge toolbar navigable sequentially (a); a toolbar organized in groups [128] (b). ... 79

Figure 27: Analysis of the test results. ... 86

Figure 28: Test of the main interface of Google Documents. ... 89

Figure 29: Test of the editor interface of Google Documents. ... 90

Figure 30: The “Sharing settings” window (a); Warning message for “no added people” (b). ... 91

Figure 31: The “Email as Attachment” window (a); The “Send message” window (b); Warning message (c). ... 92

Figure 32: Feedback about who is accessing (a); Warning for collaborators modifying the same part of the document at the same time (b). ... 93

Figure 33: Access the “Publish” functionality (a); The “Publishing” window (b). ... 93

Figure 34: Access the “Upload” functionality (a); The “Upload” interface (b). ... 94

Figure 35: Three ways to access the “Revision History” functionality. ... 95

Figure 36: The “Revision History” interface (a); The “Compare Revisions” interface (b). ... 95

Figure 37: The not accessible (via JAWS) “comment” item (a); A comment into a document (b). ... 96

Figure 38: Issues to be considered from HCI methods to design user interfaces for CSCW systems. ... 97

Figure 40: Example of use of the hidden labels and WAI-ARIA landmarks/regions in paragraphs containing text changes. ... 104 Figure 41: Audio emphasis of some inserted and deleted text... 106

LIST OF TABLES

Table 1: Examples of Web barriers depending on disabilities. ... 16

Table 2: The WCAG 2.0 Guidelines. ... 19

Table 3: Training set results. ... 54

Table 4: Test set results. ... 54

Table 5: Analysis of Google Documents functionalities based on groupware fundamentals: (Coll.: collaboration, Coop.: cooperation, Comm.: communication, Coord.: coordination, Inf. Sh.: information sharing, Aw.: awareness, Sy.: synchronous, As.: asynchronous, S.S.: same space, and D.S.: different spaces)... ... 80

Table 6: Elements of workspace awareness (Gutwin, 2004). ... 99

CHAPTER 1:

INTRODUCTION

The incredible growing success during last twenty years of the World Wide Web (commonly known as Web, and defined as a system of connected and interlinked hypertext documents [1]), has profoundly changed the way of gathering and sharing information of people. From 1991, when the researcher Tim Berners-Lee of Conseil Européen pour la Recherche Nucléaire (CERN) in Geneva defined the HTTP protocol (HyperText Transfer Protocol), the first version of HTML language (HyperText Markup Language), designed to format and present hypertext information, has continuously improved dramatically. In particular, information contained into the hypertext documents (known as Web pages) can be accessed through a Web browser software and visualized on a screen of a computer or a mobile device.

Growth of Web has followed the more demanding requirements of technologies, and modern applications has been designed trying to satisfy the more increasing users’ needs. Main reasons for these quickly growing requirements have been: 1) the impressive development of the Information Technology (IT) producing any kind of electronic devices (like desktops, smart phones, pdas, tablets, vocal platforms, digital TVs, High Definition or 3D large screens, etc.) and 2) the necessity for more sophisticated and multi sensorial ways of communication.

Nowadays, Internet supporting Web is a sort of global system of interconnected computer networks, exploited by millions of private, public, academic, business, and government networks, of local to global scope, and this explains the rapid expansion of user communities. Huge numbers of interactive interfaces and hypermedia applications encourage participation of users in a collaborative and cooperative way. The Web is an unprecedented opportunity that should guarantee equal access to information to people of every condition all over the world, but unfortunately reality is different, because Web sites, Web technologies and Web tools are usually badly designed or designed fundamentally for sight, and this scenario does not enable people with disabilities to exploit this chance.

Besides, Web sites (defined as a set of related Web pages hosted on a server computer and containing multimedia contents, including text, video, music, audio, images, etc. [2]), can be accessed by people using any kind of electronic device. This is the epoch of information where people is continuously overloaded by an incredible amount of data and instantaneously available knowledge. Unfortunately, observing the actual reality, all this way of delivering information is designed to primarily rely on vision, excluding de facto totally blind people who are considered in literature encountering more difficulties to complete a task respect to the other singular sensorial disabilities [3, 4, 5]. This thesis want to focus on blind users and their difficulties to interact on the Web.

Furthermore, the new Web 2.0 applications such as wikis, social networks, blogs, etc., have changed not only the way of communicating or acquiring information, but

have also contributed to facilitate transformation of classic methods of teaching and learning. In fact, many studies show that sharing personal experiences and collaboration between users, students and teachers have a more efficient impact on learning and facilitate social interaction [6, 7]. E-Learning is defined essentially as the computer and network-enabled transfer of skills and knowledge [8], but this kind of approach does not provide satisfying results. The new paradigm of learning should take into account relationships between persons, exploiting new technologies and available electronic devices, giving the possibility to personalize rhythms of studying according to the student abilities.

Unfortunately, collaborative environments and learning tools in general are not always designed to be effectively used by blind users who necessarily interact using an assistive technology to guide them. Even if the assistive technologies try to facilitate the interaction of special needs users removing technological barriers, they have the disadvantage of introducing new levels of interaction difficulties. Blind users typically interact with a computer using a screen reader in combination with a vocal synthesizer (a software that describes vocally what a sighted user can see on the screen), and a keyboard. Assistive technologies for blind users on other kind of devices can be different, and this should be considered during the design phase.

Digital Divide refers to any inequalities between groups, broadly construed, in terms of access to, use of, or knowledge of information and communication technologies [9]. Accessibility is a basic requirement for every system or product in order to guarantee equal access, opportunities and use to all, including differently-abled, while Usability aims to guarantee ease of use and user satisfaction during the interaction. Accessibility and Usability are crucial requirements for designing Web interfaces.

Considering the previously described issues, the main topic of this thesis is the investigation on difficulties of blind users interacting on Web, finding particular criteria to facilitate the design of the learning tools and the Web collaborative applications. Actually from our knowledge, there are not many works in literature which are focused on blind users combining accessibility, collaboration and learning topics.

1.1 Main Aims

Even if I had spent 8 years in the research at the “Institute of Science and Information Technologies” (ISTI) of the National Research Council (CNR) in Pisa with an experience on Usability of multimedia and multiplatform devices, when my Tutors gave me the opportunity to start the Ph.D. program, I had just begun to work in their new research group at “The Institute of Informatics and Telematics” (IIT) at CNR of Pisa, so we had to plan from scratch the new research topics. Before taking any decision, we started to ask us some questions about the possible research subjects.

Proper questions are crucial because help persons to find solutions, and the preliminary brainstorming was useful to gather a list of ideas spontaneously.

“The important thing is to not stop questioning. Curiosity has its own reason for existing.”

Albert Einstein

“That is the essence of science: ask an impertinent question, and you are on the way to a pertinent answer.”

Bronowski, Jacob

“Quality questions create a quality life. Successful people ask better questions, and as a result, they get better answers.”

Anthony Robbins The contribute of the blind researcher Barbara Leporini of ISTI – CNR on the Accessibility and e-Learning was significant, together with the experience of my Tutors on those research topics. That basis fitted well to my interests and past experience on Web and multimedia devices. The challenge was to elaborate original scientific contributes.

The first question we asked was:

QUESTION 1: Can people with disabilities be really able to use the Web and exploit its potential benefits and resources?

Actual society where all information rely on visual, tends to assume that every kind of people could access the Web and benefit of it, but reality is completely different. The first objective of this thesis is to analyse interaction problems and the referral standards guidelines available on Web User Interfaces (WUIs) in general and especially related to people with special needs.

Designing WUIs for every kind of disabilities is a really hard goal, since the vast range of different needs. So the collaboration with the blind researcher Barbara Leporini oriented the choice of the disability category to focus on. Besides, as described in the Introduction section, total blindness is considered the singular sensorial disability encountering more difficulties to complete a task respect to the others, and this reason was an additional suggestion for the final target.

However, designing applications and interfaces for users with a particular disability must take in account real users experiencing that disability, to concretely understand their difficulties, their exigencies, their realities and their points of view, otherwise the final results cannot be impartial and correct.

In fact, the second important question was:

QUESTION 2: Will we have the resources and possibilities to test our applications with real blind users, collecting their feedback and suggestions? We are lucky to say that the answer to this question was affirmative, because Barbara Leporini is actually the regional president of “Italian Union for blind and visual impaired people” (UIC - “Unione Italiana dei Ciechi e degli Ipovedenti - ONLUS” [151]), and also regional director of the “Institute for Research, Training and Rehabilitation” (I.RI.FO.R. - “Istituto per la Ricerca, la Formazione e la Riabilitazione - ONLUS” [71]). So, Barbara really gave us the opportunity to find a certain number of blind users to test our solutions, otherwise this task would have been more complicated having to contact the associations for blind people as externals. Barbara Leporini has been totally blind since childhood and uses the JAWS screen reader (we will describe better in section 2.2 and 2.2.1) every day; thus, she is very familiar with JAWS functions and she is able to use advanced commands.

As we will show, we have chosen to design accessible user tests online because they can be performed following the rhythms of the users (anywhere and anytime). Depending on the application to be tested, we considered completely blind users and sometimes also visually impaired ones.

After that start, as we said, we had to understand which kind of applications for blind users could be designed in the e-Learning field.

Indeed the third question was:

QUESTION 3: Which kind of difficulties have blind people to deal with, during the learning and study phases?

On the base of Barbara Leporini experience on difficulties of blind students (for example: going over a lesson again is critical, etc.), we understood that there was the need of a new paradigm of learning, being able to exploit the modern technologies and devices, using alternative sensory channels to access the typical visual information contents, beyond classical teaching methods.

Technology could not be the only ingredient to support this kind of needs for blind students, but it was necessary to consider the actual learning methods limits. As a consequence, the fourth question was:

QUESTION 4: Are traditional learning methods really efficient for blind people? As we will describe in section 3.1, the cone of learning [10] shows a more efficient new learning method considering: 1) collaboration and communication between users (or students and teachers), 2) the importance of having real active experiences while doing things, 3) valorisation of personal abilities and differences, 4) adaptation to personal rhythms of students beyond the typical class limits, etc.

These requirements are fundamental for every kind of user or student independently of their status and conditions.

E-Learning can be a future opportunity to exploit modern technologies supporting the design of environments and tools, considering these new more efficient requirements for learning. Unfortunately e-Learning is not yet completely diffused in the academic environments, and in addition, higher education is not yet using technology to its best advantage and rapid industry development is infrequently in correlation with the educational programs.

As we understood that collaboration is an important factor to facilitate learning, we started our investigation together with the researcher Victor M. R. Penichet of the Computer System Department, of the University of Castilla-La Mancha, in Albacete, Spain, due to his experience on the groupware applications and the awareness. Awareness is an important groupware feature that aims to understand, who is collaborating with a user, what a collaborator is doing and where. Awareness is really important for every kind of user and its integration with the accessibility can greatly improve the perception of blind users about their status in a collaborative environment.

Taking in account the previous considerations, the final question was:

QUESTION 5: What kind of benefits for blind people can we expect from combining accessibility and collaboration in the design of Web applications and tools supporting e-learning?

From our knowledge, there is not so much material in literature combining accessibility and collaboration to design Web applications and tools supporting learning for blind users; however this kind of research can be useful also for any kind of users, improving their interaction and specifically providing a satisfactory usability.

This thesis wish to specifically address QUESTION 5, analysing problems and trying to provide suggestions and basic guidelines to improve the design of the collaborative learning tools and environments for blind users. Obviously it is not a definitive answer, but it is a good beginning derived from the concrete experience acquired from blind people, analysing their real needs, designing accessible and usable solutions aimed at improving life of millions of individuals worldwide.

1.2 Overview

Chapter 2, Web User Interfaces Interaction Problems, presents an overview of the standard guidelines related to the importance of design accessible and usable interfaces. The chapter describes how blind users interact using a screen reader with a vocal synthesizer, and explains the encountered difficulties. In addition a description of the W3C main guidelines as the Web Content Accessibility Guidelines 2.0 [117] and the Accessible Rich Internet Applications Suite (WAI-ARIA) [11] are presented. In particular, the WAI-ARIA Suite has been created by

W3C to facilitate the design and the implementation of the Web interfaces especially for blind people. At the end, the chapter discusses about the importance of testing the applications with real blind users, and our difficulties encountered designing interfaces for this kind of disability.

Chapter 3, Design of Tools to Support e-Learning, discusses about a new more efficient paradigm of learning, focusing also on the requirements for blind users. There is a review of the advantages and benefits of audio podcasts applied to the structured educational material respect to the traditional reading. It will be presented also a user test that shows the preference of blind users to listen to podcasts with an mp3 player respect to “reading” with a screen reader. The second part of the chapter presents a Web prototype to transform digital documents (in txt or Word format) to structured (following the structure of the document) mp3 audio podcasts downloadable and listenable to on an mp3 player. The architecture and the main features of the system are presented, together with the special audio Rockbox and DAISY formats to guide blind users during the interaction and navigation on mp3 players. At the end, an evaluation of the heuristics (tried on 100 rtf/doc and 100 txt files of a training set, and 110 rtf/doc and 100 txt files of a test set) is showed. Moreover, the results of two user tests about the impact of the structured audio podcasts and the accessibility efficiency of the user interfaces of the system, are discussed.

Chapter 4, Collaborative Environments, describes the Computer Supported Cooperative Work (CSCW) field and the Groupware application features. As a case of study, the collaborative environment Google Documents is deeply analysed. A description of the accessibility problems of Google Documents found while using a screen reader are discussed; after that, a prototype of the modified user interfaces to solve those problems is presented. Groupware functionalities of Google Documents are also examined and an accessibility study has been performed on them. In addition, we will provide an analysis on the awareness and some possible suggestions. Finally, on the acquired experience from the main typical groupware features and from our analysis of Google Documents, the chapter combines the accessibility, the collaboration and the awareness trying to extract basic designing indications.

Chapter 5, Conclusions, summarizes the work of this thesis, discussing also the significant results as a consequence of our research questions outlined in section 1.1. In addition, suggestions for future works will be proposed.

Appendix, provides the detailed questionnaires of three user tests performed with blind users.

CHAPTER 2:

WEB USER INTERFACES INTERACTION PROBLEMS

Web is a huge knowledge container where people can access in few seconds to obtain information of their interest. Every person has the right to access this container of available information from every part of the World. This is the main aim of fighting the digital divide guaranteeing this right to everyone. Unfortunately reasons of the exclusion of people from this universal right can be the cultural inequalities between individuals, low level of instruction, poor quality of technological structures of geographic areas at different socioeconomic and demographic levels, differences of age and sex, different cultural or ethnic membership groups, any kind of disabilities, etc.

“The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability” [12].

“The power of the Web is in its universality.

Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, W3C Director and inventor of the World Wide Web Users can access information knowledge through an interface, so speaking about Web, it easy to understand how great importance can have the design of proper WUIs for everyone. Accessibility is a basic requirement for every system to guarantee equal access and opportunity to all, including differently-abled. Usually, special needs users access the Web content and interact with multimedia applications by means of assistive technologies hardware or software depending of the particular kind of disability: for example, blind people use a screen reader with a voice synthesizer or a braille display, low vision users utilize a magnifier, etc. Assistive technologies are a support for people with disabilities, but as side effect, introduce additional difficulties during the interaction.

“The impact of disability is radically changed on the Web because the Web removes barriers to communication and interaction that many people face in the physical world. However, when websites, web technologies, or web tools are badly designed, they can create barriers that exclude people from using the Web” [12].

Guaranteeing only the access to the information is not sufficient, because it is necessary to consider also the user satisfaction during the interaction with a user interface. Usability of a Web site [81, 118, 26, 27] should guarantee user satisfaction, ease of learning and remembering its organization and functionalities, user effectiveness, efficiency to complete quickly the desired tasks of the Web site, which has been designed for. Applying accessibility and usability criteria from the

very beginning of the designing phase is really important to reduce costs avoiding their later introduction.

2.1 Importance of

Accessible and Usable Interfaces

The reasons for the difficulties during the interaction with a WUI can be really various; in fact accessibility does not only refer to people with disabilities, because many users can operate in a vastly different context. Users cannot be able to see, hear, move or process information for any reasons: for example, 1) people can have difficulties to read or comprehend a foreign language or a text written in “bureaucratese” language, 2) people may be in a situation where their eyes, ears or hands are occupied during other activities or situations (forced to check continuously a monitor or a production line, working in noise environment, while driving, etc), 3) people use obsolete technology which can be an obstacle to benefit from the information (due to small text screens, low internet connections, old hardware or browsers), etc.

Accessibility is a general concept describing a system that can be used by everyone including also people with disabilities. However focusing on users with disabilities, currently most of the Web sites have “technical barriers” that make difficult or impossible to use the Web. As we said, assistive technologies try to support users with special needs, but unfortunately they introduce further difficulties in addition to the current “technical barriers” of Web. An accessible WUI is an interface where potential technical barriers have been removed and the user interaction with an assistive technology is simplified.

The Web Accessibility initiative (WAI) group of the World Wide Web Consortium (W3C) has as a mission, the same goal of the W3C Consortium: “to lead the Web to its full potential”. In addition, the WAI group has extended this mission: “to lead the Web to its full potential to be accessible”. In Table 1 there are some examples of Web technical barriers taken from the W3C WAI group [13] depending on most important kind of disabilities [14].

VISUAL DISABILITIES

Blindness:

 images without alternative text

 graphical alert without alternative text/advice

 complex images (e.g., graphs or charts) inadequately described

 video without text or audio description

 video subtitles not announced by screen reader

 tables that do not make sense when read serially (in a cell-by-cell or "linearized" mode)

 frames without "NOFRAME" alternatives, or without meaningful names

 forms that cannot be tabbed through in a logical sequence or that are poorly labeled

 browsers and authoring tools that lack keyboard support for all commands

 browsers and authoring tools that do not use standard application programmer interfaces for the operating system on which they are based

 non-standard document formats that may be difficult for their screen reader to interpret

Low vision:

 Web pages with absolute font sizes that do not change easily

 Web pages with inconsistent layout that are difficult to navigate when enlarged, due to loss of surrounding context

 Web pages, or images on Web pages, that have poor contrast, and whose contrast cannot be easily changed through user override of author style sheets

 text presented as images, which prevents wrapping to the next line when enlarged

 many of the barriers listed for blindness (above) depending on the type and extent of visual limitation

Color blindness:

 color that is used as a unique marker to emphasize text on a Web site

 text that inadequately contrasts with background color or patterns

 browsers that do not support user override of authors' style sheets

HEARING IMPAIRMENTS

Deafness:

 lack of captions or transcripts of audio on the web, or Sign Language video translation

 requirements for voice input on Web sites

 difficult reading content for lack of clear and simple language

 lack of content-related images in pages full of text which can slow comprehension for people whose first language may be a sign language instead of a written/spoken language

Hard of hearing:

 lack of captions or transcripts for audio on the Web, including webcasts

PHISICAL DISABILITIES

Motor disabilities affecting the hands or arms:

 Time-limited response options on Web pages

 Browser and authoring tools that do not support keyboard alternatives for mouse commands

 Forms that cannot be tabbed through in a logical order Speech disabilities:

 websites that require voice-based interaction and have no alternative input mode

COGNITIVE AND NEUROLOGICAL DISABILITIES

Attention deficit disorder:

 distracting visual or audio elements that cannot easily be turned off

 lack of clear and consistent organization of Web sites Intellectual disabilities:

 use of unnecessarily complex language on Web sites

 lack of graphics on Web sites

 lack of clear or consistent organization of Web sites Memory impairment:

 lack of clear or consistent organization of Web sites Mental health disabilities:

 distracting visual or audio elements that cannot easily be turned off

 Web pages with absolute font sizes that do not enlarge easily Seizure disorders:

 use of animations, blinking text, or generally of visual or audio frequencies that can trigger seizures

MULTIPLE DISABILITIES

 visual and auditory perceptual disabilities:

o lack of alternative modalities for information on Web sites, for instance lack of alternative text that can be converted to audio to supplement visuals, or the lack of captions for audio

 other

Table 1 – Examples of Web barriers depending on disabilities.

Accessibility aims to remove “technical barriers” but alone is not enough, because it is also important simplify the interaction: every kind of users or students in general (independently of their condition), should be able to operate easily with an interface, gathering quickly information of their interest and concentrating on the learning process, without wandering around the interface functionalities, wasting extra time or being confused by the way the information are presented. An interface can provide proper accessible information, but can be also completely unusable. Reasons for a bad usability can be several; for example:

1) navigability of a Web site can be really frustrating if connections between pages are missing or user’s interaction needs additional and useless clicks to access other pages;

2) information are presented confusedly with too many elements on the page or layout is not structured properly and similar elements are not grouped in different areas;

3) important elements of the interfaces are not immediately perceivable; 4) excessive number of clicks needed to reach the final content:

5) concise description for the labels of the elements;

6) text fonts are too small or the applied colour contrasts are not readable, etc.

Sometimes there is the tendency to address accessibility and usability as two separate aspects, but they are both strictly related to support in the best way user’s interaction. Designers should be aware of both accessibility and usability principles from the beginning. This is particularly important for people with special needs, where use of assistive technologies introduce additional difficulties. On the basis of the user interaction analysis, general accessibility and usability guidelines have been designed to support all possible user needs.

2.1.1 Referral Guidelines

The W3C WAI group have published the 11th December 2008, the Web Content Accessibility Guidelines (WCAG 2.0) to make Web more accessible and usable. The WCAG 2.0 are a new version taking into consideration both accessibility and usability criteria, while WCAG 1.0 was focused just only on the accessibility. WCAG 2.0 have been organized in four main categories: 1) perception (perceivable), 2) interaction (operable), 3) comprehension (understandable), and 4) robustness (robust), as shown in Table 2 [117].

1. Perceivable

 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, Braille, speech, symbols or simpler language.

 1.2 Provide alternatives for time-based media.

 1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

 1.4 Make it easier for users to see and hear content including separating foreground from background.

2. Operable

 2.1 Make all functionality available from a keyboard.

 2.2 Provide users enough time to read and use content.

 2.3 Do not design content in a way that is known to cause seizures.

 2.4 Provide ways to help users navigate, find content, and determine where they are.

3. Understandable

 3.2 Make Web pages appear and operate in predictable ways.

 3.3 Help users avoid and correct mistakes. 4. Robust

 Maximize compatibility with current and future user agents, including assistive technologies.

Table 2 – The WCAG 2.0 Guidelines.

These guidelines (together with the success criteria and techniques [15]) are simply general principles, which are not suitable to design in concrete Web interfaces for blind users. As we will see in section 2.2.2, something else will be necessary. Besides, guidelines are periodically updated, and just only the 3rd January 2012, “WCAG Techniques Updated - Learn about the informative guidance” [16], have been introduced, together with the “Media Accessibility User Requirements - W3C Working Draft” [17], which is a document aggregating the accessibility requirements of users with disabilities that the W3C HTML5 Accessibility Task Force has collected with respect to audio & video on the Web. W3C WAI group has designed other standards, guidelines, and techniques concerning accessibility, depending on the application to design:

 Web Content Accessibility Guidelines (WCAG), for websites [117]

 Authoring Tool Accessibility Guidelines (ATAG), for authoring tools [18]

 User Agent Accessibility Guidelines (UAAG), for browsers [19]

 Accessible Rich Internet Applications (WAI-ARIA), for rich web applications [11, 20, 22]

 Accessibility Information for Specific Technologies, for HTML, XHTML, CSS, and scripting techniques [21]

In addition some countries have established specific accessibility guidelines. In USA, Section 508 Amendment of the Rehabilitation Act [23], has been enacted to eliminate barriers in information technology and to make available new opportunities for people with disabilities. European Union with Communication “Towards an accessible information society” [24] makes suggestions for improving both web accessibility in particular and e-accessibility (related to the Information and Communication Technologies - ICT), to research and deploy technology solutions in favour of people with disabilities and elderly persons. Another target is reinforcement of cooperation and standardization with Member States.

As a demonstration of the continuing evolution of these guidelines, in 2004 in Italy, the “Stanca Law” (04/2004) [25], established dispositions to favour access of people with disabilities operating by means of information technologies. Unfortunately, the “Stanca” Law was composed of 22 general technical requirements, and denoted a sort of self-certification, which did not represent a sufficient method to confirm a Web site as completely accessible. This certification prerequisite was necessary, especially for Public Administrations favouring access of people with disabilities. Italian CNIPA (Centro Nazionale per l'Informatica nella

Pubblica Amministrazione) started a monitoring activity focused to adequate just some public Web Sites to be accessible (24 public Web sites in 2006, 42 public Web sites in 2007); although the interest of this set of public administrations to participate to this experimental activity, these small numbers give an idea of how the situation was far from being definitive and satisfactory. The new draft decree was issued in 2010 (taking into consideration the WCAG 2.0, the 22 principles have become 12), but has not yet been officially gained as a new decree-law. Speaking about usability, in addition to the WCAG 2.0, most important references for usability guidelines are the ISO 9241-11: Part 11: Guidance on Usability, 1998-03-15 [81] document, and the suggestions of authors Nielsen and Norman (in particular J. Nielsen: Designing Web Usability: The Practice of Simplicity, 2001[26]; J. Nielsen & H. Loranger: Prioritizing Web Usability, 2006 [27]; N. Norman: Emotional Design: Why We Love (or Hate) Everyday Things, 2005 [28]).

ISO 9241-11: Part 11: Guidance on Usability defines usability as the “effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments”.

Specifically ISO 9241.11, defines:

 Effectiveness as “the accuracy and completeness with which specified users can achieve specified goals in particular environments”;

 Efficiency as “the resources expended in relation to the accuracy and completeness of goals achieved”;

 Satisfaction as “the comfort and acceptability of the work system for its users and other people affected by its use”.

However even if usability suggestions and guidelines of Nielsen and Norman are rather general for every kind of user, they are continuously evolving taking in account improvement of technologies and style life changes of people (for example use of e-commerce applications, interaction through social networks, and more exigent multi sensorial experiences).

As we described in previous sections, designing Web interfaces and applications for every kind of user with disabilities is a really arduous objective, so for the reasons explained in section 1.1, we decided to focus the work of this thesis on completely blind users.

2.2 Blind User Interaction

Speaking about visual disabilities, is like entering into a vast world with different facets. Although there are several controversies in terminology, visual impairment (or vision impairment) can be defined as follow:

“Visual impairment (or vision impairment) is vision loss (of a person) to such a degree as to qualify as an additional support need through a significant limitation of visual capability resulting from either disease, trauma, or congenital or degenerative conditions that cannot be corrected

by conventional means, such as refractive correction, medication, or surgery” [29].

Visual impairments are divided into two general categories: blindness and low vision. Low vision disabilities refer to a degree of vision loss, presenting different kind of visual diseases (in Fig. 1a and Fig. 1b are showed two examples of low vision pathologies), while blindness refers to totally blind people, who cannot see at all.

Fig. 1 – Two examples of screenshots generated by the “Visual Impairment Simulator” [30]: the vision of a user with glaucoma (a); the vision of a user suffering

from diabetic retinopathy (b) [31].

Focus of this thesis is supporting learning for totally blind users, and we will use the term blind, which is typically used in literature to avoid any reason of misunderstanding. We have already explained in section 1.1 reasons for the orientation on blind users: 1) numerous user studies suggest that totally blind have

(a)

more difficulties to complete a task [3, 4, 5] than those with other singular sensorial disabilities, and 2) the concrete opportunity to test our applications with real blind users.

Designing applications for people with disabilities should consider the three principal human interaction sub-systems (Model Human Processor): perceptual, motor and cognitive [32]. In [5] authors present results of an accessibility test on 100 Web sites with users with visual, motor and perceptual disabilities. Results show that mean task success rate of 76% goes down to 53% considering totally blind users. In [3] the authors show how “users searching for information on the web reveal that, unsurprisingly, people who are sighted find searching the web much easier than visually impaired people. Furthermore, people who are visually impaired, but possess enough sight to be able to see part of the screen (either up close or using magnification), find searching the web easier than those whose sight is severely impaired (i.e., those who are either totally blind or have very limited sight)”. In fact in [4] authors valuated this gap, showing that blind users need approximately twice longer time than sighed users to explore search results and three times to evaluate the related web pages.

There is a tendency to assume that people who become blind manage better with blindness than people who were born blind, because they have more references and memories. However, this tendency can depend on individual knowledge and life experiences [33], that as we will see in section 3.1, they are important factors for learning.

Blind people interact with a user interface using an assistive technology called screen reader in combination with a voice synthesizer or a Braille display. The latter is expensive and slow, so it is rarely used. Obviously blind users cannot use a screen and a input device like a mouse, so they usually use a keyboard. From our experience, blind users do not prefer using a vocal input instead of a keyboard because the latter is more immediate and quick. In fact vocal recognition cannot work properly sometimes, depending on the context (noise environment, no correct pronunciation of the user, etc.), and in addition, the required time of speaking is typically higher than pressing some keys. This thesis focuses on the interaction through a screen reader with a vocal synthesizer as kind of assistive technology, plus a keyboard (in case of usage of a personal computer).

2.2.1 Screen Reader Limitations

A screen reader is software describing by means of a vocal synthesiser, contents of an interface (or a Web page), usually appearing on the screen.

In this thesis we will focus on the JAWS screen reader [119] because it is one of the most popular screen reader worldwide [120] (commonly used in Italy [121]), working on Windows with a Personal Computer (PC) to provide access to today’s software applications and to the Web. JAWS may also provide output to braille displays. JAWS is also configurable through scripting. One advantage of scripting is that it allows customizations to be shared among users, increasing accessibility for all. In particular considering evolution of JAWS during these last three years, we

used the versions 10, 11 and 12 of this product to test our applications. Depending on the user experience, JAWS can provide basic commands (through keys combinations) to interact with the interface; instead, advanced commands permit to access more sophisticated functionalities.

JAWS announces the text associated to one element of the interface, where the user has positioned the cursor through the keyboard. Basic and most used keys of a screen reader (see Fig. 2) are “Tab” (every time is clicked, focus goes on the next interactive element of the interface), “Shift+Tab” (every time is clicked, focus goes on the previous interactive element of the interface), and “arrows” keys (every time an arrow is clicked, JAWS explores the interface content between an interactive element and the current one, going in the direction of the pressed arrow). Spacebar and Enter keys are used to select or activate a choice.

Fig. 2 – Basic keys to explore an interface with a screen reader.

Unfortunately JAWS, or a screen reader in general, works sequentially (scanning contents of a Web page from the top to the bottom, and from left to right), and this way of operating introduces many additional difficulties for blind user interaction, needing an important cognitive effort.

Main issues derived from the sequential interaction with a screen reader are:  Information overload: Web pages contain not only text, but also

multimedia elements, like images, video, banners, podcasts, etc. (see Fig. 3). In addition blind users need to know not only the textual labels of the interactive elements, but also the information about their typology (for example: link, button, pull-down menu, radio button, check box, etc.). All this kind of information can produce a confusing audio overload during blind user interaction.

 Lack of interface overview: Blind users do not have a global perception of the whole interface, and they have to navigate for a long time before to access the desired information.

 Lack of page context: use of Tab key speeds up navigation, but user does not know what is written between an interactive element and another, thus it may be necessary reiterate the reading process with arrow keys.  Difficulties to establish precise objectives: Due to the sequentially, a

blind user cannot know the content of a Web page (unless the Web site is static without any dynamic change or because the user knows it very well). In fact, supposing a blind user wants to read the article (indicated with the rectangle and the arrow in Fig. 3) of a dynamic Web site like for example “The New York Times”, user does not know anything about the presence of that article until she/he arrives there while she/he is navigating, and in addition, unless she/he know about its existence, a lot of time passes (with many pressed keys) before she/he could reach and read it.

Fig. 3 – The sequential mode of the screen reader to scan the interface elements, introduces many difficulties on the interaction.

 Long time interaction: Visual sensorial channel is quicker than listening. As a metaphor, if listening is sequential, visual channel works “in parallel” (with a glance, user can understand the whole interface). In addition audio memory is volatile, so it is not easy for a blind user remembering current status and context position in the application [34].

 Difficulty for understanding UI elements: Links, content and widget labels of the interactive elements should be self-explanatory and not content-dependent.

 Difficulty for working with form elements: An application should notify to the users, if some previous fields of the form have not been filled in.  Content serialization and structure mixing: The screen reader

this is important because a blind user can figure out the layout of the interface, but this additional information forces the user to have an additional cognitive effort.

From previous considerations, we can understand how can be important designing fully accessible interfaces by a keyboard. Interfaces containing elements that cannot be activated or cannot receive focus via keyboard are not accessible and usable for blind users.

Considering also the difficulties introduced by the sequential way to operate of the assistive technology like a screen reader, it is very important to find some mechanisms to permit to the user to quickly skip from a part of the interface to another, speeding up the user interaction especially if the final target should be the support for learning. In addition actual Web sites interfaces are really complex, containing more and more multimedia (Rich Internet Applications - RIAs) [22], and they are designed fundamentally for the visual sensorial channel excluding people with visual disabilities, so it is crucial to deliver the same content in alternative ways of communication.

2.2.2 W3C WAI-ARIA Suite

Principles of WCAG 2.0 on accessibility and usability are important especially if considered in the preliminary phases of Web designing, but are too general to solve particular difficulties of a certain kind of disability. Usually certain functionalities of a Web site are no accessible to blind users who cannot use a mouse. W3C WAI group have thought the Accessible Rich Internet Applications (WAI-ARIA) suite [11] (together with the authoring practices [124]), specific for blind users interacting with a screen reader and keyboard, favouring effective interaction with the Rich Internet Applications. WAI-ARIA allows to associate semantic attributes to the elements of an interface (roles, status and properties), making them accessible via screen reader. Role attribute is related to the nature of the object: for example an image can assume the role of a button, and the screen reader can know when it detects it. Status attributes are properties related to the user action: for example, the status information attributes associated to the image, inform the user if that button is active, has been pressed, etc. Properties attributes are essential for the nature of a given object: for example the properties of the image can provide the data values of the button (for example the label).

WAI-ARIA supports delivering of dynamic contents (AJAX, DHTML) daily updated and loaded on a portion of the Web page (for examples traffic or meteorological news) instead of reloading the entire page, because otherwise this kind of information could not be communicated to the blind user, and would be exploited just only by sighted users. WAI-ARIA permits drag & drop via keyboard, and also supports developers to define the main regions of a user interface splitting in smaller parts, so that a blind person could move quickly to the desired area instead of being forced to interact sequentially. WAI-ARIA regions list is a sort of “summary” of the areas in the whole interface layout.

Unfortunately, WAI-ARIA is not yet an affirmed standard and not fully supported by Web meta-languages, browsers and screen readers, so it is normal for a developer

facing with some kind of incompatibilities and strange behavioural problems during the interaction of the blind users. Besides, management of WAI-ARIA attributes require often many lines of Javascript. Many examples are proposed by the Illinois Center for Information Technology and Web Accessibility [128].

2.3 Importance of Testing Applications with Real Blind Users

At the beginning of this research, I was trying to understand the experience of a blind user during the interaction on a Web site. I turned off the screen of the computer, I decided to utilize only the keyboard without the mouse, and I wore the headphones to be guided by the screen reader JAWS and the vocal synthesizer: the result of my experience was terrific because I did not know what to do and I was completely lost! Things have improved with practice and with experience, but every time I tested preliminary implemented versions of the applications together with Barbara Leporini, she made me notice some details I had not “seen”. I realized how much important could be for a designer, testing personally the applications, but also having feedbacks from real blind users because of their concrete different point of views.

As we explained in section 1.1, it is not trivial to find a certain number of users with a kind of disability. UIC and I.RI.FO.R. have given the opportunity to gather blind users having some computer skills with different levels of experiences. On that basis, we decided to exploit user tests online as an efficient opportunity to collect suggestions from real blind users during our experiments. Our priority target was oriented to blind users operating with a screen reader and a vocal synthesiser, but also low vision users operating with a screen reader or a magnifier gave us interesting opinions and suggestions about what to improve. In 3.3.2, 3.5, 3.6 sections, we will analyse the results of these tests, while in the Appendix section, we will provide the utilized questionnaires.

2.3.1 Concrete Encountered Difficulties

In addition to the accessibility and usability designing problems of Web sites for blind users, and the further difficulties introduced by the assistive technology screen reader, there is another important concrete factor to face with: the incompatibility of different Web browsers having different behaviours on the same Web interface. This is a challenge that designers and developers have to face with. Even using standard X/HTML code, we have experimented this reality. As a supplementary compliance, different screen readers present different troubles depending on the application, and also different versions of the same screen reader can present different performances. Each version of a screen reader (in our case JAWS) fixes some problematic behavioural functionalities, improving blind user interaction. This is not a trivial aspect, because a screen reader version is expensive and all blind users cannot permit continuous upgrades of the software. Also WAI-ARIA is recent standard continuously in evolution that is not definitely fully supported by the X/HTML code as well by the standard meta languages for Web; in fact during development, many lines of Javascript code have been necessary to manage WAI-ARIA attributes. Development of accessible Web

interfaces for blind can give efficient results just only if improvements are in a synergistic supported by:

1. the screen reader release, 2. W3C WAI-ARIA,

3. Web browsers, 4. the (X)HTML code.

As a one of these important factors does not support necessary changes, the final result will not be satisfactory for the final user.

In this work, we have identified the Mozilla Firefox browser as the most compatible browser with JAWS, WAI-ARIA and actual X/HTML standard; however we have verified our Web interfaces with Mozilla Firefox and also with Microsoft Internet Explorer. Google Chrome browser has presented many difficulties with JAWS so we have decided to discard it during this research. We have used versions 3.6, 4, 5, 6 and 7 of Firefox, and versions 8 and 9 of Internet Explorer. We will show in section 4.2.4, how versions 10, 11 and 12 of the JAWS screen reader together with different browsers have presented different accessibility results. Accessibility is a recent aspect of the Web, and even if the blind users are a minority part of world population, designing accessible and usable interfaces, can provide concrete benefits also to sighted users (for which majority applications are designed).