Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings Universitet SE-601 74 Norrköping, Sweden 601 74 Norrköping

LiU-ITN-TEK-A--09/059--SE

Improving web usability for thevisually impaired

Christoffer Kullman

2009-11-06

LiU-ITN-TEK-A--09/059--SE

Improving web usability for thevisually impaired

Examensarbete utfört i medieteknikvid Tekniska Högskolan vid

Linköpings universitet

Christoffer Kullman

Handledare Tony StockmanExaminator Ivan Rankin

Norrköping 2009-11-06

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Christoffer Kullman

AbstractThe Web has opened up many possibilities for disabled people to interact withsociety, but there is unfortunately a lack of parity between the user interfacepresented to different users.

This dissertation presents a proof of concept on designing a spatial layoutpresentation for blind users using a screen reader. This is done in three steps byfirst conducting a survey to determine current practices of web developers, thenimplementing an instant spatial feedback and comparison function that presentthe spatial layout, and ends with an evaluation of the spatial layout presentationby the way of user testing.

The survey yielded a set of guidelines for the realistic development of webtechnologies for disabled persons based on the participants answered. From theimplementation a concept for spatial feedback functions that are portable and ex-pandable is presented. The evaluation shows that the created spatial presentationmethod passes both objectively and subjectively.

i

Acknowledgments

I would like to thank my advisor at Queen Mary, Tony Stockman, for not onlygiving me the subject of my thesis, but for always being there to discuss, comewith ideas, and give me advice. I would also like to thank the staff and studentsat Queen Mary, University of London who made me feel at home and helped mewhen I needed it. A special thanks to Oussama Metatla for his ideas and advice.

On a personal note, I want to thank my family for their support, especiallymy parents who made it possible for me to live in London for half-a-year and mysister Johanna and her husband David for opening up their home to me. I wouldalso like to thank my girlfriend, Gabriella, for putting up with a long-distancerelationship.

iii

Contents

1 Introduction 11.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Outline of Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Literature Review 52.1 Goals of Auditory Interface Design . . . . . . . . . . . . . . . . . . 52.2 Relevant Research . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Relevant Implementations . . . . . . . . . . . . . . . . . . . . . . . 7

3 Survey 93.1 Purpose of Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Demographics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 General Information About Web Development Projects . . . . . . 103.4 Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Guidelines for the Realistic Development of Web Technologies for

Disabled Persons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Implementation 174.1 Goals and Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Current Spatial Feedback Function . . . . . . . . . . . . . . . . . . 204.4 Comparison Function . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Evaluation 235.1 Description of a Testing Session . . . . . . . . . . . . . . . . . . . . 235.2 Demographics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Objective Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3.1 Effectiveness of left/right and top/bottom recognition . . . 245.3.2 Instantaneous position recognition . . . . . . . . . . . . . . 255.3.3 The comparison function . . . . . . . . . . . . . . . . . . . 265.3.4 Closely-positioned objects . . . . . . . . . . . . . . . . . . . 285.3.5 Mental model . . . . . . . . . . . . . . . . . . . . . . . . . . 29

v

vi Contents

5.4 Subjective Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Results 336.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Benefits and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 346.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.4 Field of Application . . . . . . . . . . . . . . . . . . . . . . . . . . 366.5 Recommendations for Further Work . . . . . . . . . . . . . . . . . 36

Bibliography 37

Contents vii

List of Figures3.1 General information regarding web development . . . . . . . . . . 103.2 Participant’s test browsers . . . . . . . . . . . . . . . . . . . . . . . 113.3 Web developments views towards accessibility . . . . . . . . . . . . 13

4.1 Graphical concepts of a screen . . . . . . . . . . . . . . . . . . . . 184.2 Scheme for a frequency-based representation . . . . . . . . . . . . . 194.3 Scheme for a MIDI-based representation . . . . . . . . . . . . . . . 204.4 Scheme for a current spatial feedback function . . . . . . . . . . . 214.5 Scheme for a compare function . . . . . . . . . . . . . . . . . . . . 21

5.1 A participant during a test session . . . . . . . . . . . . . . . . . . 235.2 Checking horizontal and vertical positioning separately . . . . . . . 245.3 Answers in three different locations for instantaneous position recog-

nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.4 Tasks to test the comparison function . . . . . . . . . . . . . . . . 275.5 Result from four boxes task . . . . . . . . . . . . . . . . . . . . . . 285.6 Task for closely-positioned objects . . . . . . . . . . . . . . . . . . 285.7 Realistic test of mental model of the web page . . . . . . . . . . . 29

List of Tables5.1 Correct answers for instantaneous position recognition . . . . . . . 265.2 Participant’s answers to object relations to other objects . . . . . . 305.3 Usefulness of function . . . . . . . . . . . . . . . . . . . . . . . . . 305.4 Basic design concept . . . . . . . . . . . . . . . . . . . . . . . . . . 315.5 Simplicity of horizontal and vertical positioning . . . . . . . . . . . 315.6 Addition of functions . . . . . . . . . . . . . . . . . . . . . . . . . . 315.7 Would like the function to be implemented . . . . . . . . . . . . . 325.8 Would like more functions . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 1

Introduction

This chapter introduces the reader to the thesis by presenting a description of theproblem, the objectives, and limitations of the thesis as well as an outline of thereport and a critical look at the references.

1.1 ProblemThe Web has quickly become one of the most important tools in the world. News,commerce, government services, social interaction and more are now availableonline, even replacing traditional means for a large part of the Western World.The Web has become essential for receiving and providing information, as well asinteracting with a global society. With its development as a multimedia technologywhich deals in text, audio, and visual media in addition to the increasing accessto high-speed/low cost broadband, the Web has become a large part of daily life.

The development of Web-based technologies has provided a unique opportunityto help people that have difficulty interacting with society, such as those that arephysically disabled, to overcome the barriers they face normally. It falls to thedevelopers of these technologies and Web developers to take responsibility andprovide Web accessibility1 for these users. While many tools and solutions havebeen developed for this purpose, parity between disabled and non-disabled usershas not been achieved.

There are disconnects in the usability2 and accessibility of web pages and weblanguages between different presentation forms (screens for non-disabled users,screen readers for the blind users, etc.). A screen reader is a piece of softwaredesigned to present the information being displayed on a screen in an auditory orBraille format for a blind user. Their purpose is to try and give a blind personaccess to the usability and functionality of different software applications. It is

1The extent to which a product/website can be used by specified users with specified disabil-ities to achieve specified goals with effectiveness, efficiency and satisfaction in a specified contextof use[9]

2How well users can learn and use a product to achieve their goals and how satisfied they arewith that process (http://www.usability.gov/basics/index.html)

1

2 Introduction

worth noting that a blind user using a screen reader will only use the keyboardand not the mouse. Considering that in the US and UK only 3 percent of allbooks are ever produced in Braille, often a long time after initial publication[8],screen readers massively increase the amount of information available to blindpersons. In present form, after going through a few iterations to gain stability,screen readers such as JAWS and Window-Eyes have been produced that work wellwith a lot of standard web technology. A time delay between the latest mainstreamdevelopments and their availability in the associated assistive technology still exist,unfortunately [private communications with Tony Stockman]. An area where moretime and resources need to be invested when it comes to screen readers and otherassistive technologies is support for collaborative working, especially now thatsupport for single user operations are fairly well developed[10]. Blind users willwork with sighted colleagues and the tools available need to help them in thesesituations[6]. If focus is placed on blind users who use screen readers to access theWeb, there are errors that occur in a collaborative situation with a sighted userwhich show where the problems that cause these disconnects are found. Theseare[10]:

• Location disconnects where one person does not know where the focus of theother is.

• Layout disconnects due to the fact that the graphical user interface (GUI)and the auditory user interface (AUI) have different spatial organizations.

• Contextual disconnects where objects or layout around an area of focus areavailable to one user, but not the other.

• Holistic disconnect where one user has a more effective overview of the web-site which gives them an advantage in using the web page.

Most of these can be attributed to the fact that while spatial layout is an importantpart of the design of a GUI, it is not included in the screen reader created AUI.In the screen reader AUI, web pages are presented linearly making the user expe-rience vary greatly between sighted and blind persons. This, in turn, will makeit difficult for blind users to create an effective mental model of the web pagecompatible with working collaboratively with sighted persons[10]. Being that webpages are primarily designed for sighted users this means that the blind user willnot have access to the intuitive, emotional, or psychological design intent of theweb developer.

1.2 ObjectivesLooking at the problems described in section 1.1, the objectives of the thesis are:

• Conduct a survey to find out the current practices of web developers withregard to how they design their web page’s functionality, usability, and ac-cessibility.

1.3 Limitations 3

• Design a spatial layout presentation for the screen reader AUI using non-speech sounds.

• Implement this design for the Windows Operating System, JAWS ScreenReader and Internet Explorer due to their popularity among blind users[12].

• Implement the design using JAWS Script3 and Python4 as functions forinstant spatial feedback and comparison between two positions.

• Evaluate the resulting implementation with user tests.

• Analyze the results of the survey and evaluations and deduce some conclu-sions. Also consider a few recommendations for further work.

Note that the main objective of the thesis is not to create a perfect implementation,but to determine the most realistic methods to design solutions for blind web usersand realize a proof of concept concerning spatial layout web presentation in an AUI.

1.3 LimitationsThe limitations of the project are time- and resource-based. The survey is smallbecause of the time it takes to get participants would have taken away time fromthe implementation and evaluations. The cost it would take to contact multipleweb developer companies also led to a smaller survey. The two functions thatmake-up the implementation are by far not the only two proposed additions, ideassuch as an overview function to show the spatial location of the most importantelements, using sound to show information density, or playing different types ofsounds for different types of elements where all suggested, but fell out due totime constraints. The implementation does not use an actual simulation of anauditory 3D-space due to the computer resources which this requires of a user’scomputer, such as a high quality level sound card. The evaluation could havemore participants, and most likely more blind participants, if there was an addedincentive (monetary, food, etc.) that there were no resources for.

1.4 Outline of ReportIn chapter 2, there is a literature review that describes the background of thethesis by showing related research and implementations. Chapter 3 presents theresults from the web developer survey and defines a proposal on how to developweb solutions for blind users based on these. Chapter 4 gives a detailed descriptionof the implementation. Chapter 5 shows the evaluation results of the user tests. Inchapter 6, the benefits, restrictions and field of application of the results are shown.Conclusions, analysis, recommendations for further work will also be explored. Thereport concludes with chapter 7 and a discussion on the practical implementationsof the thesis.

3The scripting language for the JAWS Screen Reader.4A general purpose, high-level programming language.

4 Introduction

1.5 ReferencesOverall, the references used in this paper can be considered of good quality. Someof the papers may be considered old for a user interface-based paper, as a few aremore than 10 years old, but are still relevant. There are also a few web-basedsources, but these are from what can be considered trusted sources. Even if thestarting point might be Wikipedia, links were followed to get a more official sourcesuch as w3.org or WebAIM. One source[8] is a transcript of a presentation, but onthe page there was a video of lecture and the transcript is correct.

Chapter 2

Literature Review

This literature review chapter serves as a summation of applicable literature togive a background for the thesis. This includes the goals of auditory interfacedesign as well as relevant research and implementations.

2.1 Goals of Auditory Interface DesignBeing that the purpose of this dissertation is to explore a method to achieve someform of parity between the screen reader created AUI and the GUI for web pagesit would be helpful to define goals for auditory interface design.

Mynatt has presented five goals for screen reader design, these are: accessto functionality, iconic representations of interface objects, direct manipulation,spatial arrangement, and constant presentation [6, p.13]. There are also the ob-servations of Winberg, who found that when designing assistive technologies focus“should be on providing sufficient resources (talk, gestures, listening, remember-ing) to support collaboration rather than focusing on providing complete accessto all functionality.”[14, pp.54-55] He also added that “[h]aving sufficient resourcesto monitor the other person’s actions” and to “look for examples where the audi-tory presentation made it possible to collaborate”[14, p.76] are appropriate areasto focus on to understand how to support collaboration. Another important factthat he found during his research is that there is a “disengagement from the audi-tory display to re-orientate and re-establish the state of the auditory space, which. . . emphasizes the need to support getting a quick overview.”[14, p.76]

Combining the ideas of Mynatt and Winberg gives the following goals for col-laborative auditory interface design.

• Access to functionality, specifically where it would provide parity in the userexperience of a GUI and an AUI and enhance collaboration. For collabora-tion this means designing functions so they work in tandem with the con-versation that would naturally occur between two users, for example bothwould understand the command “Go up and to the left.”

5

6 Literature Review

• Iconic representation of interface either earcons or auditory icons (these con-cepts will be explained in section 2.2).

• Direct manipulation to give direct interaction with the interface.

• Provide the spatial arrangement and have a constant presentation in orderto lessen the effects of dis-engagement from the auditory display and monitorthe other person’s actions.

If collaboration is the focus it is also important that when the blind user is incontrol, the sighted user should be able to see what is happening and vice-versato support joint operation[7].

2.2 Relevant ResearchMynatt stated in 1997 that “[u]sers must understand the interface in terms of itsspatial system...the visual layout seems to be consistently problematic for blindusers.” and goes on to describe that for a GUI the primary mental model is basedon structural information with a secondary one based on spatial information[6,p.15]. These thoughts are still echoed in the 2008 paper by Stockman and Metatla,where the screen reader AUI is presented as a linear representation of web pages.In other words, the primary mental model is met, but the spatial informationis still missing 11 years later. Most users build their mental model on the logi-cal structure and then try to memorize the spatial presentation (or order of theelements presented)[6]. There is also a lack of using non-speech sound in AUIsas shown in the largest survey on designing for auditory displays, where, whengiven the task of designing a MP3 player with auditory feedback only, circa 27%mentioned using non-speech sounds [3].

There are solutions available to present three-dimensional auditory interfaces,but these require powerful, high-performance systems for quality real time use[1,pp.32-33]. If, for a sighted user, a screen can be considered as a 2 1/2-dimensionalrepresentation than a three-dimensional spatial sound system will not create aone-to-one mapping from the visual to the auditory, requiring an auditory ab-straction of the graphical presentation [6, p.21]. The question then becomes, howshould this auditory abstraction be formed to give a spatial representation? Usingiconic information in GUIs has been positive for sighted users[7], if an auditoryequivalent can be produced and used to show the spatial nature of a user interfaceit should create a decent abstraction[1, p.47]. This is dependent on if the spatialrepresentation provides significant resolution to be useful, but this is somethingthat needs to be tested. There are two main presentation methods for sound,auditory icons and earcons[1, p.7].

Auditory icons, for the most part, mimic how information is presented inGUIs[6, p.25] by being sounds “designed to trigger associations with everydayobjects.”[7] They can be manipulated to show different actions, for example by re-moving the high-frequency energy to symbolize the object having been selected[6,pp.26-27]. A downside to auditory icons are that some functions have no everyday

2.3 Relevant Implementations 7

equivalent and thus no natural sound that can be used[1, p.7] which is, unfor-tunately, the case for this paper. There is no natural sound that would show’bottom-left’. Earcons, on the other hand, use abstract, synthetic tones to presentinformation with sound[1, p.7]. They have built-in structures as to be easily mod-ified, by changing pitch or timbre,[1, p.63] which can be used to model differentaspects of a web page’s structure, including the spatial aspect. For the imple-mentation presented in this paper, earcons are the preferred sound presentationmethod.

2.3 Relevant ImplementationsMany auditory displays have been created over the years, there are three thatare particularly relevant to this work. These are Mercator, JugglingSounds, andSoundtrack.

Mercator is a screen reader solution created at Georgia Tech. The softwareuses auditory icons to identify various objects on the interface, such as a windowbeing represented as the sound of tapping on glass[6, pp.26-27]. Here a hierarchicalmodel of the GUI is used instead of a spatial one. Layout is presented by “mowingthe sound of the edit cursor as it is moved through the text”, but informationabout the layout of the interface is lost with this solution[6, p.42]. While using ahierarchical representation could work for the web, considering nested elements,the layout information lost is the specific information that this paper aims topresent, current spatial position that can help in collaborative situations.

The next auditory display is JugglingSounds, that gives an auditory system tolearn how to juggle. In this solution pitch is directly connected to the height ofthe juggled club[2].

The final display, Soundtrack, is similar to JugglingSounds in that pitch isused to show position. Here, when in a sub-menu, each item receives a toneas well as having its name spoken. When moving down the pitch of the tonesdecrease and when moving up it increases[1, p.49]. It should be mentioned, thatwhen analyzed, the users of Soundtrack counted tones and did not use the changein pitch to determine their position, but this could be specific to the application[1,p.50] and is still an interesting concept.

Chapter 3

Survey

This chapter presents the results of a web-based survey that was sent to web de-velopers and online web development forums. The purpose of the survey is laidout first, after which the results of the survey are shown in three groups: demo-graphics, general information about web development projects, and accessibility.To end the chapter a short set of guidelines based on the results are presented.

3.1 Purpose of SurveyThe purpose of the survey is presented to the participant with the following threegoals:

1. Get the background of the participant, to add weight to their answers.

2. Determine some information about a standard professional web developmentproject.

3. See how accessibility is viewed and tools for accessibility open to a webdeveloper are used.

The purpose of the survey was not to find a “bad guy” or bad method, but todefine web development realistically. In the end these three sets of questions areanalyzed to specify guidelines for the realistic development of web technologies fordisabled persons.

3.2 DemographicsFor the data presented in this chapter there are eight participants. These are splitinto two types of participants: persons that were contacted personally via e-mail(two participants) and persons who answered via a few different Internet forumsfor web developers (the other six). The two groups received the same questionsexcept that the first group were asked for their name and the second their age.

9

10 Survey

The reason for the split is simply that the survey expanded from the original e-mail interview to include web forums to get more answers and a better set of data.Of all eight participants, six of them had more than five years of experience asprofessional web developers, with one person having two to five years experienceand another having one to two years. Two of the users may not be the best sourcesas one is under 18 and the other is between 18 and 22, but still profess to havemore than five years of experience as professional web developers. They both havegiven intelligent and well-thought out answers, so they are included in the results.

The fields in which these participants have carried out web projects are spreadacross a wide spectrum including direct marketing, local authorities, education,publishing, e-commerce, Javascript libraries, politics, business, as well as researchand statistics. The field with most participants was entertainment-based, withthree developing projects for music-based projects and two for gaming. Somenotable projects of the participants were for Manchester United and UniversalMusic.

3.3 General Information AboutWeb DevelopmentProjects

(a) Scripts and Languages (b) Average Length

Figure 3.1. General information regarding web development

Here, in this section, some overlying information about web development projectsis presented in the results. First, it is interesting to know what web programminglanguages and scripts the participants use and how long a project usually takes,both of these are presented in figure 3.1. The first figure (3.1(a)), regarding pro-gramming languages and scripts, shows that HTML/XHTML and Javascript arewidely used (7 of 8 participants) with XML, PHP, and CSS being quite popular(5 of 8). When it comes to project length, see figure 3.1(b), it seems that projects

3.3 General Information About Web Development Projects 11

are time-consuming with 38% of users stating that, on average, projects take morethan a year and a full 75% saying that projects take at least more than threemonths.

The next area explored in the survey is about usability and customers, whetherthere is ever a cost versus usability situation. Participants were encouraged both torate a customer’s view of usability on a scale of 1 to 5, with 1 being “not important”and 5 being “essential”, and to give full answers. Four participants gave a 5, twogave a 4, and two decided it was easier to answer fully. Their thoughts were thatusability is “. . .more important than ‘features”’ and that “. . . cost is usually theprimary force. . . , until [the customer] realise(sic) how unusable cheap is.” Someother notable quotes are: “...over the last 8 years or so I would say that usability hasbecome essential in the customer’s eyes”, “Customers demand sites that are usablefor all, and are willing to pay for this.”, “As far as cost vs. usability goes, usabilitywins out”, and “I pretty much design for usability as the sole requirement. . .myusers are glad for it.”

Figure 3.2. Participant’s test browsers

In the next question, participants were asked about testing. Two users decidedto be very direct and answered simply “yes” and “sure” when asked if they testedfor different browsers and device independence1. When it comes to web browsertesting, the results can be seen in figure 3.2 with five participants choosing tospecify browsers. The last participant stated simply that they tested on “. . . allmajor browsers for windows, mac and linux.” As figure 3.2 shows all participantstest on Internet Explorer, usually multiple versions, and on Firefox by all but

1For some web content or application to be device independent, it should be possible for auser to obtain a functional user experience associated with its web page identifier via any accessmechanism. (DIP-1, Device Independence Principle - 1, http://www.w3.org/TR/di-princ/)

12 Survey

one, who works for a development team that is Internet Explorer-exclusive due tosoftware restrictions, but looking at cross browser solutions. Device independencetesting seems less popular with two specifying that they only look at PC or desktopsolutions. Of the specific answers only one came close to saying they look at this,“Generally someone will look at sites on their phone browsers but this would beinformal.”

The last general question touched on the W3C Recommendations2 influence onprojects. Most participants claim to follow the recommendations, with one goingso far as to call it “gospel”, with reservations for browser-related solutions thatdo not conform. Only one participant did not know what was meant by the W3CRecommendations.

3.4 AccessibilityIn the previous section a question about the influence of the W3C Recommenda-tions on projects was examined and one answer is more specific to accessibilityand is more properly presented here. In the Web Content Accessibility Guidelines(WCAG)3 there are three priority levels that are assigned to checkpoints for webaccessibility. The first priority level must, the second priority level should, andthe third priority level may be addressed to make the web document usable bycertain groups, such as blind users. One participant claimed that all their pagesare AA compliant (fulfill Priority 1 and 2 checkpoints, which are based on thecheckpoints impact on accessibility) also having one case as AAA compliant (ful-filling all Priority 1, 2 and 3). The WCAG are published by the Web AccessibilityInitiative (WAI), which is the subject of the next question concerning its influenceon projects. Six participants say that they take a look at WAI guidelines whenbuilding their pages, mostly without a focus on them, with two stating that theyhave no influence on their projects. Two use checker tools, for example one usesBobby, that validate websites for WAI.

The participant’s web development teams views towards accessibility are pre-sented in figure 3.3, on a scale of 1 for “not important” to 5 for “essential”, withone participant not answering. Here, it can be seen that accessibility is under-prioritized with three answering 1, two 3, and two 4. For those answering 1 itseems that they simply do not think about people with disabilities when theydesign pages. Some traps, outlined in the answers by one user, that show ac-cessibility is not in the forefront during web development are bad color choices,contrasts incorrect mark-up, and overuse of tables. As another participant put it“I may steer away from the most strict rules because they inhibit the project’sdevelopment.” The one person who did not answer with a number gave the answer“some prefer looks over function, others function over looks...”. The next questionstrengthens the idea that accessibility is not a high priority in that it deals withthe design processes that the participants use when working towards accessibility.Three users have no thought of accessibility in the design portion of their projects,

2Documentation with the goal of standardizing Web technology3http://www.w3.org/TR/WAI-WEBCONTENT/

3.4 Accessibility 13

Figure 3.3. Web developments views towards accessibility

three state that they attempt to follow the WAI guidelines in the design, and onlytwo say they specifically design tests for accessibility.

The next two questions concern the testing process. Of the eight participants,two have tested their pages with screen readers (one with JAWS and WindowEyesand one with JAWS) while either having the screen turned off or a blindfold onto see if they could navigate the web page. Both of these users also did some sortof contrast testing to help users with various eye conditions. Of the remaining sixparticipants, four used no testing processes at all, one used Cynthia, a web con-tent accessibility validation solution, and one uses a Visual Studio 2008’s InternetExplorer plug-in to test.

In the style sheet language CSS (specifically W3C Recommendation CSS level2 from 1998), which is used to style web pages, there are functions for aurallyrendering a document known as ACSS4, or aural style sheets, that puts the creationof sound rendered by a web page outside the screen reader software. Only twoparticipants knew that ACSS existed and both claim limited knowledge and havenever implemented projects with them. In general, there seems to be no consensusto the tools that can be used to work towards accessibility. Visual Studio (twoparticipants), screen readers (two, as mentioned previously), blogs/newsgroups(one), web browser-based tools (one who uses both Internet Explorer’s DeveloperToolbar and Mozilla’s accessibility add-ons) and validation tools (one), such asBobby, are seemingly obvious choices, but, as can be seen here, are not widelyused.

This section ends with some closing thoughts from a few participants. Onebelieves that recent accessibility laws and the use of CSS, sensible structuring ofHTML data (use of lists and headings and no nested tables), and meta-data (forexample, ’alt’, ’longdesc’, and ’lang’ attributes) have led to a more structured and

4http://www.w3.org/TR/CSS2/aural.html

14 Survey

computer readable web. Another believes that accessibility is “the difference be-tween a successful project and a failed one with thousands of complaining users.”A final thought is that there should be a compilation list or book that gives pro-gramming examples that “cuts to the chase” unlike some web-based descriptions.

3.5 Guidelines for the Realistic Development ofWeb Technologies for Disabled Persons

Based on the survey, web developers use a multitude of different web languages/scripts(more than half of participants use PHP, XML, and CSS while almost all useHTML/XHTML and Javascript) and are concerned with the usability of theirprojects and this does not become an obstacle with regards to cost. Most of theusers also claim to follow the W3C Recommendations, even regarding them as“gospel”. Despite these positive aspects the participants also only test for the twomajor browsers (Internet Explorer and Mozilla Firefox) and seem to skip testingfor device independence altogether. Knowledge and desire concerning designingand testing web pages for accessibility seems to be lacking, though a majority dosay that take a look at the WAI guidelines, albeit without focus. So given thisinformation, how should accessibility-related web technologies be developed?

Firstly, looking at web developers, they have a lot on their plates. They seemto have no problem looking at guidelines and recommendations, so creating betterand clearer guidelines to help standardize web pages and make them more usableand accessible is desirable. Also, usability is a main goal for developers. Trying tostress that usability and accessibility go hand-in-hand should be a cornerstone inteaching new developers.

In the end, projects take time and developers cannot be expected to carry themajority of the weight. As can be seen by the total lack of knowledge or imple-mentations of ACSS by the participants, even adding functionality to a standardlanguage does not mean it will be used. It falls to software developers of assistivetechnologies.

The following list summarizes a few guidelines for the realistic development ofweb technologies for disabled persons.• Combine the idea of usability and accessibility when presenting the ideas ofstandard web development. The simple action of having validators of webcontent which include, but are not limited to, accessibility-based criteriawould strengthen this concept.

• Design assistive technology-based solutions that are based on standardizedweb coding procedures (such as the W3C Recommendations) and general,well-defined, and widely implemented user interface designing techniques.Think of the assistive software as translator, body language, and inflectionthat gives both the actual text and subtext presented in the user interface.

• Do not expect web developers to add accessibility-specific code to theirprojects, design accessibility-related functions inside the assistive technol-ogy software.

3.5 Guidelines for the Realistic Development of Web Technologies forDisabled Persons 15

• Create an overall set of guidelines for web development that includes webstandardization, structural integrity, and accessibility that includes clear,simple examples to help developers.

Chapter 4

Implementation

Here, in this chapter, the implementation is explained, from the basic concepts forshowing the spatial position using non-speech sound to the two functions that weredesigned to test spatial positioning, current spatial feedback and comparison. Thechapter starts with a short explanation of the implementation goals and method.

4.1 Goals and Method

The goal of the implementation is to expand the JAWS interface with functionsthat provide spatial information to the user when they are using the Web. Onefunction should give the current spatial position to the user and another shouldbe able to compare two different locations. These functions should always beavailable to the user. A secondary goal is to create a solution that can easilybe ported to other screen readers such as Window-Eyes and NVDA as well as forother applications such as Mozilla Firefox or Microsoft Word. The implementationshould work fully for every web page it comes across, but also be written in a waythat it should be easy for developers to expand on the base functionality.

To reach the portability goals, the functions are written in Python as COM1

objects. The functions are user activated, toggled by pressing a series of keys.JAWS and Internet Explorer are the desired implementation environments and,as such, the direct implementation to a screen reader is written in JAWS Scriptin internetexplorer.jss (the Internet Explorer script-file) with no requirements forthe web developer. Both frequency-based and midi instrument-based sounds aretested and these are implemented in the music-specific computer programminglanguage CSound.

17

18 Implementation

Figure 4.1. Graphical concepts of a screen

4.2 Basic ConceptsThe spatial information of a web page has solely been an aspect of the GUI, and notthe AUI, which means that these graphical concepts need to be translated to audi-tory ones. To get a spatial idea and due to the fact that a screen is 2D-presentationonly a top-bottom (y-direction) and left-right (x-direction) orientation need to bepresented. As figure 4.1 shows the top left corner on a screen is coordinate (0,0)and bottom right is (maxx,maxy). The screen has a center, equation 4.1, thatprovides two lines that split the screen top-bottom and left-right.

center = (maxx2 ,maxy

2 ) (4.1)

In JAWS the default cursor is the PC cursor, a visually invisible indicator of thesystem focus. The mouse cursor is, in JAWS terminology, referred to as the JAWScursor and can be accessed by the user at any time, usually to be used to pressbuttons as you would with a mouse. It moves one pixel at a time and is thereforenot a practical navigational tool. Luckily, the different cursors can be routed toeach other. Simply put, in JAWS Script it is possible to navigate using the PCcursor and then move the JAWS cursor, in other words the mouse cursor, to thatpoint. Using this method it is possible for the user to navigate normally and use themouse cursor to show the current position of the user on the screen. The desiredalgorithm can be built based on using the screen’s maximum x- and y-positions, orscreen resolution, (maxx,maxy) as well as the mouse’s x- and y-positions (x, y).This is a simple procedure because the screen resolution and mouse position iseasily extracted using the Windows API.

The question is then how best to present a spatial position with sound. Thepresentation should be easy to understand, have a low cost for the computer, andbe able to be used in a large amount of different functions. For the horizontalposition (left-right) panning seems to be an obvious choice. Panning works in

1Component Object Model, see http://www.microsoft.com/com/default.mspx for more infor-mation

4.2 Basic Concepts 19

a stereo audio system, defining one channel as left and the other as right, andmixes the intensity of the sound played on these two channels giving the effectthat a sound is coming from the left, right, or somewhere between with regardto the user. The vertical position (top-bottom) is a bit more difficult. As wasseen in Chapter 2 earcons are an option to presenting spatial information. Usinga metaphor regarding pitch, objects can be considered “high on a page” (towardsthe top) with a high-pitched sound and “low on a page” (towards the bottom) witha low-pitched sound. Using this idea a two-dimensional spatial representation canbe built by using pitch for vertical position and panning for the horizontal.

Figure 4.2. Scheme for a frequency-based representation

The representational form of the sound is the next aspect to be decided. Pan-ning as a concept would be constant for all implementations, representation ofpitch becomes the important decision. Since frequency can be considered the ob-jective measure if pitch is the closely related subjective measure[11], it makes senseto test a frequency-based representation. Being that humans can hear frequenciesbetween circa 20 and 20000 Hz and that pitch discrimination starts to fail around5 kHz (most instruments have their highest notes below 5 kHz) [11], it makes senseto have 20 Hz represent the lowest part of the screen and 5 kHz the highest partwith the center of the screen at 2510 Hz, (fmax−fmin)+fmin, where f representsthe frequency. This gives a design for the spatial sound generating system, seefigure 4.2. The frequency is translated into sound by using a sine oscillator. Thetwo equations in the figure are expanded below as equation 4.2 which generatesthe desired frequency which is then added to fcenter to stay within the range andequation 4.3 which generates the desired panning within [-1,1] (-1 is farthest left,1 farthest right). The result is an audio output to the left and right channels.

f(y) = (maxy2 − y) ·fmax−fmin

2maxy

2= (maxy2 − y) · fmax − fmin

maxy(4.2)

g(x) =x− maxx2maxx

2= 2x−maxx

maxx(4.3)

This system creates a representation with a high resolution, but the sounds thatplay are lifeless and border line irritating. Also, being that sounds towards the ex-tremes are hard to distinguish[5] the resolution level is much higher than required.

20 Implementation

Figure 4.3. Scheme for a MIDI-based representation

MIDI instruments are a good substitution as they are also frequency-based (inkeeping with the pitch to frequency relationship) with a better sized resolution(128 possible notes) in the correct range (the highest frequency is 4186 Hz andthe lowest 26 Hz[13]) and a warmer sound texture. Midi also provides a rich setof possibilities for increased functionality, such as using different instruments todepict different information and easily applying well know effects such as pitchbend. Even polyphonic sounds can be produced as the notes for different chordforms are easily calculated. The resolution can be further reduced by using thenotes that correspond to the 88 keys of an extended keyboard (notes 21-108)[4]adding one so there is a center note, 64. In other words, notes 20-63 representthe bottom half of the screen, 65-108 the top half with note 64 at the divisionbetween the two creating 88 divisions (notemax − notemin). The MIDI-basedrepresentation as the spatial sound generating system is shown in figure 4.3, whichuses g(x) defined in equation 4.3, but introduces a new f(y) (4.4).

f(y) = −ymaxydivisions

= −y · divisionsmaxy

(4.4)

The system generates a number between 20 and 108 by calculating equation 4.4,adding notemax to make sure the number is within the range, and uses the math-ematical function floor to round down to the nearest integer. This integer cor-responds to a note number which is used to select the correct sound file from anarray of MIDI notes generated from a MIDI instrument (for this implementationthe instrument is a piano). At the end of the system the result is, as before, anaudio output to the left and right channels. This is the spatial sound generatingsystem that is used in the two functions added to the JAWS interface.

4.3 Current Spatial Feedback FunctionThe first desired function is one where the current spatial position is presentedto the user. The system detailed in the previous section provides a spatial soundthat instantly shows the position. In order to strengthen the user’s understandingof the spatial nature of the sound and to make the two functions as structurallysimilar as possible the first step of this function is to expand the feedback from one

4.4 Comparison Function 21

Figure 4.4. Scheme for a current spatial feedback function

played sound to two. The first sound is a reference sound based on the center ofthe screen, in other words note 64 with zero panning. This is followed by playingthe spatial sound based on current cursor position. This is shown in figure 4.4.In this system there is a time delay added to the spatial sound, this is just toshow that this sound should be played a few moments after the reference sound.Practically, being that the sounds are stored as wav-files2 for this implementationand Python code will only play one file at a time, this means that the calls forplaying the sounds need only to be in the correct order.

4.4 Comparison Function

Figure 4.5. Scheme for a compare function

The second function compares the position that the user is currently at withtheir previous position. As with the previous function, two sounds are playedone after the other. In this situation the previous position’s spatial sound can beconsidered the reference sound and is played first followed by the spatial sound of

2wav is an audio file format

22 Implementation

the current position. The system is shown in figure 4.5. This figure shows thatthe reference sound based on the previous position is taken from saved values andthat this is updated every time the system is called by saving the current position,symbolized by the broken connection which closes after the sound is played so thatthe saved values are updated correctly.

Chapter 5

Evaluation

In this chapter the results of the user test-based evaluation of the implementationare presented. This includes a description of a testing session, the demographicsof the participants, and summaries of the objective and subjective results.

5.1 Description of a Testing Session

Figure 5.1. A participantduring a test session

A testing session is split into three different sections:training, task-based testing of added functions, anda post-test interview. Each testing session includesone test leader and one participant. The test leadersits with a computer screen in front of them andpresents each section, takes the participant throughthe tasks/statements, and documents the results. Theparticipant does not have access to a computer screen,instead they have a keyboard and a pair of head-phones which present the screen reader output (seefigure 5.1).

The first section of training is to make sure thatthe subject is comfortable with and completely under-stands the meaning of the added functions and canask any questions that they might have. Here the de-mographical information is also gathered. For blindusers, the training is also to make sure that they get an understanding of the key-board set-up. For sighted users, the training is also to give them an understandingof using a screen reader and also get them used to the presentation method. Thissection lasts for however long the participants feel they need it, sometimes longer ifthe test leader feels that there might be confusion or misunderstanding of a certainconcept. The other two sections will be explored more in depth in later sections,Objective Results and Subjective Results, with analysis of the data in chapter 6.

23

24 Evaluation

5.2 DemographicsFor the testing sections, three demographic questions are asked to see if these haveany effect on the result set. With 10 participants the demographics are as follows:

• There are seven sighted participants and three blind participants.

• When asked if they use their computer daily, weekly, monthly, or never, allten participants answered daily.

• When asked if they use the JAWS Screen Reader daily, weekly, monthly, ornever, four answered daily (all blind participants fell into this group), oneanswered weekly, and five answered never.

5.3 Objective ResultsThe task-based section is designed to objectively answer how effective the functionsare at presenting spatial information and assisting in building a mental model ofa web page. Tasks are designed to test the effectiveness of pitch and panning todetermine vertical and horizontal positioning, instantaneous position recognition,the comparison function, close-lying objects, and to test the mental model createdby the functions. The results from the tests are presented for all, blind, and sightedusers, to see if these factors have any effects.

5.3.1 Effectiveness of left/right and top/bottom recognition

(a) Horizontal (b) Vertical

Figure 5.2. Checking horizontal and vertical positioning separately

The first set of tasks are designed to separate and test the effectiveness ofthe two aspects of the spatial sound, panning to determine horizontal (left-to-right) and pitch to determine vertical (top-to-bottom) positioning. The resultsare presented in figure 5.2. In each task the participant is presented with 5 objects

5.3 Objective Results 25

that are either on the same horizontal line or vertical line and asked to order them,respectively, from left-to-right or top-to-bottom.

As can be see in figure 5.2(a), the results of testing the horizontal aspect showthat determining the left side is easy with every participant answering correctly.The center-to-right side is where incorrect answers appear, with the problem seem-ing to be determining which object is farthest to the right. If only left, center,and right orientation is explored only one participant could not distinguish thedifference between the center object and a right-lying object. Overall, the partic-ipants are correct 88% of the time, with no real difference between sighted andblind users (88.57% vs. 86.67%).

Looking at figure 5.2(b), the vertical results are better with participants an-swering correctly 92% of the time and blind users scoring 100%. Again the partic-ipants are fully correct in one direction, this time in determining the bottom side,with problems occuring on the center-to-top side. Considering only the top, center,and bottom orientation it faired the same as with the horizontal task with onlyone participant having a problem determining center as opposed to top position.

Of the participants that answered incorrectly two did so only for the horizontaltask, one only for the vertical task, and one for both.

5.3.2 Instantaneous position recognition

(a) Bottom Right (b) Center Left

(c) Top Center

Figure 5.3. Answers in three different locations for instantaneous position recognition

The next three tasks are included to test if a user can instantaneously determinetheir position on a web page using the current spatial position function. For thesetasks there is an input box placed in a different location (bottom right, center left,and top center) for three separate pages. The participant is asked to say which

26 Evaluation

coordinate they are positioned at. The first coordinate is the vertical position,with 1 being the top of the page and 9 being the bottom of the page, then thehorizontal position, with 1 being far left and 9 being far right. The web pageis split into a grid based on these coordinates. Each participant is allowed toanswer with a range or multiple answers (for example, 4 or 5 vertically and 7-9horizontally). The answers are presented in figure 5.3 (lines and numbers addedto original web page to display answers) with the total answers in that grid boxpresented first, followed by blind users in parenthesis. The red box highlights thewhole input box, which stretches over two grid boxes, but the sound played isbased on the cursor point which can be viewed in the left of these grid boxes inall three figures. For an answer to be considered exactly correct it needs to be inthis left grid box, but an answer is also considered correct if it is one of the gridbox’s eight nearest neighbors (up-left, up, up-right, left, right, down-left, down,down-right).

Exact 8-Neighbor Total Vertical HorizontalBlind 20% 20% 40% 70% 60%Sighted 3.57% 46.43% 50% 78.57% 60.71%All 7.89% 39.47% 47.37% 76.31% 60.53%

Table 5.1. Correct answers for instantaneous position recognition

Looking at all three figures in 5.3, it can be seen that the answers are quitespread with at most two participants answering with the same coordinate. Abreakdown, in percentages, of the combined answers for these three tasks is shownin table 5.1. This shows that in all but one instance, exactly correct answers,sighted participants are better at determining their position instantaneously. Over-all, though, participants are quite poor in determining their position with theproblem seeming to be due to them understanding one aspect, such as verticalposition, better than another. There is also no discernible learning curve presentwith answers going from 54.55% to 37.50% and then back to 54.55%. Blind par-ticipants were more confident in their answers, with a rate of 1.11 answers perparticipant per question, compared to 1.33 for sighted ones. Task 2, figure 5.3(b),which has the box slightly below center and to the left, had the lowest confidencerate with 1.6 answers per participant.

5.3.3 The comparison functionTo test the comparison function, two tasks are present. Both are designed with 8objects placed around an ’X’ which is in the middle of the page, see figure 5.4. Thefirst task, shown in figure 5.4(a), has the objects placed in the ’cardinal’ directions(up-left, up, up-right, left, right, down-left, down, down-right) and the participantis asked to identify the word that is up and to the left of ’X’. For this task 90% ofthe participants answered correctly, with one sighted participant answering ’feet’which is to the left of ’X’. In the second task, figure 5.4(b) (lines added to originalweb page for clarification purposes), the objects are spread about on the page

5.3 Objective Results 27

(a) Cardinal Directions

(b) Four Boxes

Figure 5.4. Tasks to test the comparison function

and the user is asked to place them in four different boxes: up/left, up/right,down/left, and down/right of ’X’. In both these tasks participants are to use thecomparison function only to determine the orientation of an object with regardsto ’X’. An important note, after the second test session the comparison functionwas changed from playing a reference note followed by the spatial sound for boththe previous and current position to playing the spatial sound for the previousposition followed by the spatial sound for the current position. This change doesnot seem to have changed the data, but was deemed less confusing to the user.

The second comparison task’s results, presented in figure 5.5, has a good show-ing for the comparison with a 91.25% of the objects placed correctly by the par-ticipants with the blind participants answering 100% correct, sighted participantswere 87.50% correct. Four participants had one incorrect placement, one hadthree, and one did not provide one of the objects (the fault here lies with thetest leader missing that one object had not been provided). Some common errorsthat occured are getting the vertical position correct, but not the horizontal andvice-versa with one user getting the horizontal position correct three times onlyto get the vertical one wrong. Only in one instance did a participant get boththe vertical and horizontal position wrong. The words that were closest to the

28 Evaluation

Figure 5.5. Result from four boxes task

’X’ (glass and candy) are also the ones that had most incorrect answers, with twoapiece, two that are close to either the vertical or horizontal center (wallet andbook) each had one incorrect answer. Both of these were due to the person nothearing which side of the closest line they were on.

5.3.4 Closely-positioned objects

Figure 5.6. Task for closely-positioned objects

In figure 5.6(lines and numbers added to original web page to display answers)the next task is shown. These nine objects are closely positioned on a web page andthe task is to determine which word is in the middle of the rest. Each participantis allowed multiple answers (if they think that that it may be one of two or threeanswers). They are also allowed to use both functions. The answers are shown in5.6 with the answers from all participants presented first followed by parenthesisto show blind participants answers.

Out of a total of 12 answers (two sighted participants had multiple answers)two sighted participants identified the middle object correctly. Three sighted par-ticipants had the correct horizontal center and three participants (two sighted, oneblind) had the correct vertical center. The other four answers (two sighted, twoblind) identified the top line as the center. It should be noted that this task took

5.3 Objective Results 29

the longest time for the participants and has the most comments about difficulty.

5.3.5 Mental model

(a) Web Page

(b) Participant Performing Task

Figure 5.7. Realistic test of mental model of the web page

The final task (figure 5.7) of the test session is an attempt to give a simple, butrealistic situation to see how the participant builds a mental model of the web pageusing the two functions. The participant is given a web page, figure 5.7(a) (coloredboxes added to original page for clarification purposes), with four objects: a logo(blue box), an image, a menu (green box), and some text (red box). They arealso given an A4 paper that is the ’screen’ and four pieces of paper that representthese four objects as shown in figure 5.7(b) (text added for clarification). Theparticipant is asked to place the objects on the ’screen’ in their correct positionwith regards to the screen and the other objects. Note that in the original JAWSrepresentation the logo (visually bottom right) is presented first followed by themenu (top right), image (top left), and, finally, the text (bottom left).

To evaluate this task, the relationships (x-y) between the image (I), menu (M),logo (L), and text (T) objects in the participant’s answers are examined. For eachcorrect direction the participant is given one point. For example, if the participanthas the menu to the right of the image they get one point and if they have thetext below and to the left of the logo they get two points. This system is used to

30 Evaluation

generate percentages which are displayed in table 5.2.

I-M I-T I-L M-T M-L T-L TotalPoints 1 1 1 2 1 2 8Blind 66.67% 66.67% 100% 66.67% 100% 66.67% 70%Sighted 71.43% 71.43% 71.43% 85.71% 57.14% 85.71% 76.79%All 70% 70% 80% 80% 70% 80% 76.25%

Table 5.2. Participant’s answers to object relations to other objects

5.4 Subjective ResultsThe post-test interview is to determine the subjective experience and view of thefunctions of the participant. The participant is presented with a statement andasked to answer with one of the following: strongly disagree, disagree, neutral,agree, or strongly agree. Also for each statement the participant is encouraged togive comments if they would like to. When all statements have been presented, theparticipant is encouraged to express any more comments that they have thoughtof during the session.

The data are presented below in tables grouped by statement type coupledwith a description of the statement(s) and any user-based comments. The dataare presented for the total participants with blind participant’s answers withinparenthesis. The answers are organized into SD (Strongly Disagree), D (Disagree),N (Neutral), A (Agree), and SA (Strongly Agree).

The first statements, as shown in table 5.3, are designed to see if the partici-pants felt that the functions are useful. The comments that came from this sectionrevolved around the comparison function and an apparent design flaw. The func-tion, in its current form, only plays the sounds once, the participants expresseda desire for the function to be able to “compare again”. One participant, whoanswered neutral, said that with a compare again-functionality that they wouldhave strongly agreed that they found the comparison function useful.

Function SD D N A SACurrent Position - - - 7(2) 3(1)

Comparison - 1(1) 2(0) 4(0) 3(2)

Table 5.3. Usefulness of function

The next set of statements, shown in table 5.4, are included to see if the basicdesign concept is agreeable to the participants. These are that the tasks wouldbe good in a collaborative environment between sighted and blind persons, thesounds played are irritating, and a reference sound followed by a spatial sound isintuitive and/or easy to understand. The final statement regarding the referencesound had comments about the learning curve associated with understanding this

5.4 Subjective Results 31

concept, this took a while for a few participants to understand even with a trainingsession.

Statement SD D N A SACollaborative Tasks - - 1(0) 7(3) 2(0)Sounds Irritating 3(1) 6(2) 1(0) - -Reference Sound - - 3(1) 5(2) 2(0)

Table 5.4. Basic design concept

In table 5.5 the statements relate the subjective view of the participant con-cerning that it is easy to determine horizontal position with the panning of soundand vertical position with the manipulation of pitch. Comments in this sectionstated that objects that are close together made it difficult to determine differencein horizontal position and that a clearer polarity between the top and bottomvertical position should be investigated.

Statement SD D N A SAHorizontal Panning - 1(1) 1(0) 5(2) 3(0)

Vertical Pitch - - - 5(2) 5(1)

Table 5.5. Simplicity of horizontal and vertical positioning

In the next two statements, table 5.6, addition of similar functions to the twoavailable during the test are presented to see if they are desirable. A commentthat touches on both of these statements is that it is hard to answer if there isnothing to compare it to. The first is that the participant would prefer to havean automatic and constant spatial feedback of the current location when they arenavigating a web page instead of toggling it with a series of buttons. Commentsshowed that this would be desirable if it is a mode, in other words it can be turnedon and off. The other statement was that the replacement of the piano notes usedin these functions with multiple sounds would be a good way to present differenttypes of web-based elements. The only comment here was to be careful not to addtoo many as to increase the complexity.

Statement SD D N A SAAutomatic Feedback 1(0) 5(2) - 4(1) -

Replacement of Sounds - 1(0) 1(0) 7(3) 1(0)

Table 5.6. Addition of functions

In the next table, 5.7, the statements are to give a final say on the functions,simply that a participant would like the functions to be available when they useJAWS to access the Web or in any other programs. This also includes a statementfor a hypothetical spatial overview of a web page. For the hypothetical function

32 Evaluation

one participant would only like to have it as an alternative to the functions thatare already added.

Function SD D N A SACurrent Position for Web - - - 8(1) 2(2)

Comparison for Web - 2(2) 1(0) 7(1) -Current Position for Other Programs - - 1(0) 8(3) 1(0)

Comparison for Other Programs - 1(1) 2(0) 7(2) -Spatial Overview for the Web 1(0) 2(0) - 5(2) 2(1)

Table 5.7. Would like the function to be implemented

The final statement, below in table 5.8, is concerned with whether the partici-pants would like to add more types of functions or design to the current functionsthan presented during the tasks or above statements. They are also asked to givesuggestion to possible additions. Some of the proposed additions are: to be ableto zoom in and out of a page; to move the functions to other applications suchas spreadsheets and flowcharts; to strengthen the panning part of the functionswith different sounds showing horizontal orientation; a spatial alert notification;to connect color with a specific sound or element in sound (pitch, treble, etc.);to help determine position for close-lying objects be able to switch between thefunctions as they are now and having the screen reader say the coordinates; com-parison between more than two objects to check text-alignment; and expand toinformation density, for example using timbre to show if something is a graphic ortext.

SD D N A SACurrent Position for Web - - - 9(3) 1(0)

Table 5.8. Would like more functions

Chapter 6

Results

In this chapter conclusions regarding the paper as it relates the objectives, as wellas the benefits and restrictions of the work is presented. An analysis of each partof the implementation (survey, implementation, evaluation), field of application,and recommendations for further work are also described.

6.1 ConclusionsThere are six objectives for the paper, below are conclusions if the specific objec-tives are completed as well as the overall objective.

The first objective was in regards to conducting a survey to find out currentpractices of web developers. The survey was carried out in a limited capacity withonly eight participants and resulted in a short set of guidelines for realistic webdevelopment for disabled persons. Despite it being limited, the survey’s primarypurpose to gain some insight into some aspects of current practice and providecontext for the development work was fulfilled. This survey found that whileweb developers are adept at programming in multiple languages/scripts, focus onusability, and design based on guidelines and recommendations, that accessibil-ity, device/browser independence is not a priority. The guidelines resulting fromthe survey concern blending together the concepts of usability and accessibility,putting the weight of accessibility on assistive software developers, and creatingtools to help web developers design for accessibility.

Objectives two through four all regard to the same concept, the implemen-tation of functions in the screen reader AUI to present spatial layout with non-speech sounds for JAWS in the Windows OS. Two functions are the result of theimplementation, one for instant spatial feedback and one for comparison, bothprogrammed in Python and implemented for JAWS with JAWS Script. Theseare presented as two MIDI sound files being played one after the other, with thefirst being a reference sound (the center of the screen for instant spatial feedbackand the previous checked point for the comparison function) and the second beingthe current position. The spatial characteristics of the sound are panning to showhorizontal orientation and pitch for vertical orientation. High pitch is equal to

33

34 Results

being high on the page and low pitch low on the page. Position is based on cursorlocation on the screen where the screen resolution creates a grid with point (0,0)in the top left corner.

Objective number five concerns the evaluation of the implementation. Thereare 10 participants for the evaluation, with three blind and seven sighted per-sons. Objectively, determining only horizontal and vertical position proved simpleenough with 88% and 92%, respectively, of the answers being correct. Instan-taneous position recognition, considering an 8-neighbor comparison, faired lesswell with only 47.37% of all participants giving correct answers. The comparisonfunction seemed to fare well with two different task getting the answers 90% and91.25% correct. The final task for closely-positioned objects showed that this isdifficult with only two correct answers out of twelve, with only one blind partici-pant getting a dimension (vertical) correct. The final task concerning building amental model fared decently with 76.25% (70% for only the blind participants) ofthe answers giving correct object spatial relationships.

For the subjective portion of the evaluation, there are five main answers, whichhad an overall positive slant. The instant spatial position function was found usefulby every user and the comparison function by a majority (7 participants, includingall 3 blind participants). All but one sighted participant thought that the functionswould assist in collaborative tasks between sighted and blind users, no one foundthe sounds used irritating, and a majority (7 with 2 of the blind participants)found the use of reference sound intuitive. Vertical positioning using pitch wasfound to be easy to use by all participants and panning for horizontal positioningby a majority (8 including 2 blind participants). All participants would also likemore functions, with the ideas of replacing the sound played to show information(8 for) and giving a spatial overview of a web page (7 for) being popular (all blindparticipants where for these suggestions), but the suggestion of automatic spatialfeedback was less so (6 against including 2 blind participants). The participantswere overwhelmingly for implementing the instant spatial position function forthe Web as well as for other applications, a little less so, but still positive toimplementing the comparison function for the Web and other applications. It isworth noting, on the other hand, that two of three blind participants did not wantto implement the comparison function for the Web.

The final specific objective is this chapter. The overall objective of creatinga proof of concept concerning spatial layout presentation that follows realisticmethods to design solutions for blind users has been presented by the completionof all the above objectives.

6.2 Benefits and RestrictionsThere are three main benefits from this dissertation. Firstly, the survey resultedin a set of guidelines to outline realistic development of web technologies for dis-abled users based on industry-based participants. The second main benefit is thecreation of spatial functions in the implementation that pass are usable and appre-ciated as shown by the objective and subjective results. This can be seen by the

6.3 Analysis 35

results of the mental model task, which showed (76.25% correct) that the functionsgive participants an effective mental model of a web page layout for this level ofcomplexity. This has been a key aspect missing from current screen reader imple-mentations. The implementation also yielded a result that is easily portable toother screen readers, web browsers, and applications as well as being expandableand general enough for future implementations. The third and final main benefitis that the dissertation can be considered a full proof of concept of presentingspatial layout in a screen reader AUI, although in a simple fashion, that follows asmall set of guidelines.

There also a few restrictions on the results of this paper. The survey can beconsidered small with only eight participants and there was a fair share of emptyanswers within. Being that the survey had a majority of free form answers thiscould have hampered its effectiveness in getting answers as participants might havefound this method more arduous. When it comes to the implementation spatialfeedback is presented as two separate sounds, one continuous and evolving soundcould have been better and more intuitive. The instant spatial feedback functionwas not as effective as could be desired (at least for horizontal perception), eventhough it was appreciated. Also, the system requires a very small resolutionconsidering that when looking at close-lying objects a 9x9 resolution was shownto be too high. When it comes to the evaluation there are two main points to bemade. Firstly, out of 10 participants for a system meant to benefit blind users andset in screen reader software primarily experienced by these users, only three wereblind. As can be seen in the results this does not seem to have a major effect on theresults, but with such a skewed ratio of participants and a small number of blindpersons the effect of the demographics on the result does need to be considered.Finally, in the evaluation is the training that is required before using the functions.The concept of pitch and panning to represent vertical and horizontal positioning isnot one that many people have had access to. The training, though the participantdecided when they felt they were ready, was quite short and perhaps not enough.

6.3 Analysis

Looking at the results from the three areas of study (survey, implementation,evaluation) as well as their benefits and restrictions the following can be said ofeach area.

Survey: While small and perhaps not optimally formatted, yielded an interest-ing, consistent set of data that formed the basis to a set of guidelines.

Implementation: Two, admittedly simple, functions are implemented in a waythat fulfills their respective purposes and are general enough that they can bemoved across screen reader software, web browsers, and applications. Also, theconcept is well documented and can be easily expanded and improved.

Evaluation: Showed, both objectively and subjectively, that the implementa-tion is a usable and appreciated solution. The only major problem is the trainingportion which could have been better designed.

36 Results

Overall: The result is a proof of concept that spatial presentation for a screenreader AUI can be created in a general and usable way. The dissertation does notclaim to have the best possible, or even fully implementable, solution, but can beconsidered a good starting point for further research and development.

6.4 Field of ApplicationThe main field of application is quite obvious, create a spatial presentation forscreen readers that can be used by blind users to help them in collaborative situa-tions with sighted users. Even though this was done specifically for the Web, it fitsmost applications. It could even be used for other applications where positionaldata is desirable, for example GPS navigational systems.

6.5 Recommendations for Further WorkThere are multiple areas in which the results from this work could be expanded,improved, or analyzed more deeply:

• Analyze web development standards deeper. For example, create a new,more focused survey that can be distributed more widely to web developersthrough direct contact with web development companies. It would also beinteresting to conduct a study of the code, graphical, and auditory presen-tation of web pages that are considered to have the best GUIs.

• Create more functions based on the concepts shown in the implementation.Expand the functions using different instruments for web-based elements,create a spatial auditory overview of a web page, and/or having the feedbackbe constant during navigation. Improvement of the functions, for exampleby using a continuous change of sound to present spatiality instead of twoseparate tones or strengthening the perception of panning, presented in thisdissertation is also an interesting idea.

• Try lifting out these functions and placing them in an another setting. Suchas a mobile phone, MP3 player, or GPS navigational system.

Bibliography

[1] Stephen A. Brewster. Providing a Structured Method for Integrating Non-Speech Audio Into Human-Computer Interfaces. PhD thesis, University ofYork. Human-Computer Interaction Group, Department of Computer Sci-ence, 1994.

[2] Alberto de Campo, Julian Rohrhuber, Till Bovermann, and ChristopherFrauenberger. Sonification and auditory display. Given through internal chan-nels.

[3] Christopher Frauenberger, Tony Stockman, and Marie-Luce Bourguet. Asurvey on common practice in designing audio in the user interface.

[4] David Miles Huber. The MIDI Manual: A Practical Guide to MIDI in theProject Studio. Focal P, Boston, second edition, 1999.

[5] Tim Kientzle. A Programmer’s Guide to Sound. Addison-Wesley DevelopersP, Reading, Mass, 1998.

[6] Elizabeth D. Mynatt. Transforming graphical interfaces to auditory interfacesfor blind users. Human-Computer Interaction, 12(1):7–45, 1997.

[7] Elizabeth D. Mynatt and Gerhard Weber. Nonvisual presentation of graphicaluser interfaces: Contrasting two approaches. In Human Factors in ComputingSystems, pages 166–172. ACM Press, 1994.

[8] Helen Petrie. Ten years of some access to the web for people with disabilties.Lecture Transcript. http://www.decadeofwebdesign.org/prints/petrie.html,Jan 2005. A Decade of Web Design. Amsterdam. Last checked: 21-08-2009.

[9] Helen Petrie and Omar Kheir. The relationship between accessibility andusability of websites. In CHI ’07: Proceedings of the SIGCHI conference onHuman factors in computing systems, pages 397–406, New York, NY, USA,2007. ACM.

[10] Tony Stockman and Oussama Metatla. The influence of screen-readers onweb cognition. In Proceedings of the Accessible Design in the Digital WorldConference ADDW’08, 2008.

37

38 Bibliography

[11] John Watkinson. The Art of Digital Audio. Focal P, Oxford, third edition,2001.

[12] WebAIM. Survey of preferences of screen readers users. WebPage. http://www.webaim.org/projects/screenreadersurvey, Jan 2009. Lastchecked: 07-04-2009.

[13] Chris Whittmann. Midi note number, frequency table. Web Page.http://tonalsoft.com/pub/news/pitch-bend.aspx, Oct 2005. Last checked:27-08-2009.

[14] Fredrik Winberg. Contextualizing Accessibility: Interaction for Blind Com-puter Users. PhD thesis, KTH Computer Science and Communication, 2008.Stockholm, Sweden.