– casestudy_n_1.pdf

FIND A SOLUTION AT Academic Writers Bay

Website Navigation for BlindUsers

Hans Hillen and Dr. Vanessa Evers, University of Amsterdam

AbstractIn this case study Mr. Hillen and Dr. Evers focus on the problems that blind people can encounterwhen they try to navigate a website. Having investigated these problems they propose some possiblesolutions which are embedded in a prototype, NavAccess, that was developed and evaluated toaddress three types of issues that the authors refer to as ‘‘focus challenges’’. These are: providingguidance for blind users; empowering blind users; and reducing cognitive load.

Research goal and approachThe goal of this research was to create a prototype, known as NavAccess, that would make navigationof websites more effective, efficient and pleasant for blind users.

So far, the solutions that have been provided to improve website navigation for blind usersmostly focus on one specific page. Little has been done to provide solutions that apply to a websiteas a whole. The goal of this research was to provide such a solution. In order to achieve this goal aprototype, NavAccess, was developed and then evaluated during user sessions with blind participants.

Prototype descriptionThe prototype used for this study consisted of a server-based agent that crawled through all pageswithin a given website, followed each link it encountered (but only those pointing to a page withinthe current site domain) and collected information about these links and the pages they led to.

As a primary resource, previous studies were used in which the development and evaluation ofsimilar web navigation improvement tools for blind Internet users were described. Secondly, the UserAgent Accessibility Guidelines (UAAG) 1.0, developed by the W3C Web Accessibility Initiative,

Interaction Design: Beyond human-computer interaction Sharp, Rogers and Preece 2007 John Wiley #038; Sons, Ltd ISBN-13: 978-0-470-01866-8

2 Website Navigation for Blind Users

were used as a baseline for the interface accessibility requirements. The Web Content AccessibilityGuidelines (WCAG) 1.0 were also observed, although the actual content of the NavAccess tool waslimited to simple strings of text.

Finally, news groups frequently used by blind Internet users were observed, as well as accessibilityweb forums such as http://www.accessifyforum.com/. With these guidelines, the firstprototype was developed.

The result was a complete record of the ‘infrastructure’ of the given website, which was thencommunicated to the user interface using XML. This information was then available at the interfaceto help the user navigate the site (see Figure 1 for exle), which could be done using only onehand, through buttons on a numeric keypad. Using the arrow keys the user could move back andforth through the website’s link structure, probing the targets of encountered links without actuallyfollowing them.

Figure 1 Screenshot of NavAccess prototype Interface

This approach resulted in the user having access to two different styles of navigation:

1. Navigating the site’s structure through the prototype’s interface. This form of navigation has alow level of detail but allows the user to move around the website in a fast and efficient manner,making it possible to have a ‘macro level overview’ of the website as a whole.

Testing the two different navigation styles 3

2. Navigating a specific page through the standard browser interface. When a page of interest wasencountered in the prototype macro level overview, the user would be able to switch to the mainbrowser and access the page. This form of navigation is slower than the first navigation style butit offers a higher level of detail, allowing a more detailed analysis of the specific page.

As addition to the main NavAccess functionality described above, several peripheral functionswere added:

— Because the target pages had already been parsed on the prototype’s server, the user could requestaudio ‘preview information’ about the content of the page the link lead to, whether a link wasworking, whether it resulted in leaving the current domain, whether it was a different protocolthan HTTP (such as FTP or mailto), or whether it was pointing to a file that was not a web page(such as an image or a PDF file). Another exle of preview information is the use of ‘link titlealternatives’ which the user could request to hear the actual title of the target page rather thanthe actual link phrase, which can be context dependent or even graphical.

— For each link the system checked how many times the link occurred on the site compared tothe total number of pages within the website. If a link occurred on more than 80 percent ofthe pages, it would be identified as a ‘main link’, and made available through separate interfacecontrols. This way the user would always have important links such as ‘home’ available, regardlessof whether such a link was present and focused on the currently selected page.

— Context dependent links such as ‘click ‘‘here’’ to visit our website’, (where the actual link phraseis only ‘‘here’’) are difficult to understand when viewed in a different environment (e.g. a screenreader’s link list). The prototype allowed users to extract the textual environment of a link.

The best way to examine the efficacy of this approach was through user testing these twodifferent styles of navigation.

Testing the two different navigation stylesUser sessions were conducted with ten blind participants to test the navigation styles. Each sessionconsisted of the following phases:

1. A semi-structured interview, in which the participants were asked about the way their impairmentinfluenced their daily lives, the role the Internet played in their daily lives and the problems theyexperienced when accessing websites.

2. An observation session, where participants were asked to visit a website they frequently visitand carry out tasks tasks they normally carry out on this website while being observed by the

4 Website Navigation for Blind Users

experimenter. This way, more knowledge could be obtained about which problems blind Internetusers encounter, and the ways in which they work around these problems, before they tested theprototype.

3. Finally, the participants were asked to explore a website (www.danbrown.com) using theNavaccess prototype, and think aloud while doing so.

The blind participants were given an introduction to the system, in which the main functionalitiesof the NavAccess interface were described and explained. After the introduction, the participantswere allowed five minutes to freely explore the interface. During this phase, the experimenter readout the main functions and key combinations whenever requested, as a help option would. Thisapproach was chosen because the actual NavAccess help content had not been implemented yetin this early prototype, and also to collect feedback about how often users needed to refer to thehelp when using the system. After this ‘try-out’ phase, the site model of an earlier website accessedby NavAccess (http://www.danbrown.com) was loaded into NavAccess as a datasource. Theparticipants were asked to navigate the structure of this site model using the NavAccess controls.Initially, this second phase required the participants to perform specific tasks in this website structure(e.g. ‘‘navigate to the page where you can order the book ‘the Da Vinci Code’’ ’). However, a pilotwith two users made it clear that structured tasks were too cumbersome. Because blind users have toremember the controls, do not have constant visual feedback of options available and it takes timeto learn, the decision was made to observe the participants’ experience of using the NavAccess maincontrols and functions while freely navigating the Dan Brown website. The instructions that theywere give were: ‘please explore this website while using NavAccess’.

In phase three the participants were asked to carry out a task they are familiar with on the Internetwhile using the NavAccess interface. The participant was asked to think out loud. Participants chosetheir own website and set their own task. Data collected by the researchers included: the age of theparticipant, visual capabilities of the participant, the accessibility aids used by the participant, Internetand computer experience, how the participant had learned to use the Internet, what he/she uses theinternet for, the website accessed in the session, the nature of the task, the duration of the task, thethink aloud protocol, and the user log of the session.

Because of the small number of participants in this study, the evaluation results were qualitativedata. An exle of results for a participant is as follows.

Participant 6Profile: A 55-year-old male who had been completely blind for 33 years. He used JAWS software asa Windows screen reader. The participant had learned to use the Internet in a DOS environment,mostly for activities such as email and visiting ‘De Digitale Stad’ (the digital city Amsterdam, DDS), avirtual community where people can navigate through a virtual representation of a city, communicate

Testing the two different navigation styles 5

with other citizens and add local content. The participant mentioned that this community was idealfor a blind person because every visitor had to use their imagination, thereby removing the differencebetween blind and sighted users. The participant mentioned that he does not try to find out how apage’s layout is designed, unless this information is necessary to reach a certain location on a page.In this case the participant asks for help from a sighted person. The participant also mentioned thathe encourages the use of frames (whereas frames are often mentioned as an accessibility obstacle)because they allowed him to skip inaccessible content. An exle of a task completed in this partof the evaluation is:

Website: http://www.albert.nl, an online store which delivers groceries for major Dutchsupermarkets

Task description: Find out how much it costs to have groceries delivered next Tuesday, 5pm.Duration of task: approx. 15 minutesUser actions and system responses: When the participant starts his task, his email client application,

which was already running, remains selected. The participant listens through some of the contentbefore realizing this and switches to the browser application. The participant has learned the necessarysteps needed to login into the site by heart, and knows that the login form on the site’s homepagedoes not work with his assistive technology (the input fields can be selected but are not describedby the screen reader). The participant accidentally presses enter while a link was selected, and endsup on an unfamiliar page. To undo this error, he uses the browser’s back-function to return to thestarting page. However, the location he returns to cannot be read correctly by his screen reader. Atthis point, the participant starts over by re-entering the site’s URL in the address field.

Because the login form on the starting page does not function correctly, the participant has totake a detour which he has discovered during an earlier visit. After following the link to ‘special deals’he selects one of the products which are currently offered at a low price. This action generally placesthe product in the participant’s shopping basket, but since he is not logged in yet he is rerouted to alogin page containing a form, which can be read by assistive technology. By doing a page search forthe term ‘password’ the form is found immediately and the participant can enter his login data.

After being logged in, the participant follows a link labeled ‘delivery times’. On this page, thedelivery times are displayed as a table, with days of the current week in columns, and the delivery hoursin rows. Each cell contains the cost to have groceries delivered at that specific day and time. Whilethe participant describes the table, the researcher notices that the participant’s mental visualization ofthe table has the dimensions switched: the days in rows and the hours in columns. The participantlistens through the table using the down arrow key. It is difficult to remember which value belongsto which row and column combination, also because some cells are empty. When the participanthas identified the delivery cost for the day and time specified, it turns out he is mistaken by one daybecause he thought the table started at a different day. Since he used this incorrect information tonavigate the table (counting the number of days starting from the first), he ended up at the wrong day.

6 Website Navigation for Blind Users

Types of navigation: The participant navigated a predefined route during the task. By knowingwhich obstacles to avoid (the inaccessible login form) the participant took a detour to arrive at hisdestination, and by memorizing necessary steps (such as counting rows and columns) the participantknew exactly how to navigate within his predefined path. This approach is only possible whenone has a lot of experience with a specific website, and will most likely fail when a website’scontent or structure is updated over time. The participant mentioned that when this happened anew ‘orientation phase’ was necessary.

Pictures taken during user sessions

Findings from the prototype user evaluationThe main idea behind the prototype was that revealing the website’s overall structure would improvewebsite navigation for blind users. However, the results showed that having a second interface wasconfusing for the participants. Furthermore, the participants were not interested in building a mentalmodel of the site as a whole. The reason for this was that they wanted to focus on ‘one page at atime’. In other words, providing an alternative ‘view’ of the website led to increasing, rather thandecreasing cognitive overload as the researchers intended.

Using sounds to provide preview information was also distracting, as participants already had touse the auditory channel to interpret the screen reader’s speech. The preview information itself wasconsidered useful.

However, the participants’ feedback on each specific key point of the NavAccess showed thatthey did consider the prototype’s peripheral functions (main link identification, preview information,context extraction) to be an improvement on their navigation experience, if implemented correctly.Therefore it was decided to start the development of a second prototype, which was based on theseperipheral functions and embedded within the browser’s main navigation interface. Offering analternative interface to show the overall structure of the website did not improve website navigationfor blind users.

Discussion of the findings 7

Discussion of the findingsAll participants performed specific navigation actions that required knowledge about the website’sstructure and functioning that was obtained earlier. These actions allowed participants to skip content,circumvent accessibility obstacles, or create alternative navigation paths. When asked about theseactions, each participant indicated that usually, an initial phase is required to familiarize oneself witha website, in order to navigate it in an effective, efficient and comfortable manner. Therefore itseems that successful website navigation largely depends on whether or not the user is successfulin exploring the website during an initial ‘learning phase’. In this learning phase, the user attemptsto locate useful landmarks on the website, which can then be used in subsequent visits to thesite for more efficient and effective navigation. For exle, during the observation sessions oneparticipant visited a website where a person’s address can be found based on last name and city.The page containing search results was tedious to navigate through because the participant had tolisten through a lot of irrelevant content such as menus, banners and additional lines before gettingthe search results. So instead of having to listen through all of this information on each visit, oneparticipant remembered that the actual search results always started after the words ‘search in thiscity’s surroundings’, because this link happened to be located just before the results. This servedas a landmark that could be used on future visits to jump directly to the relevant location on thepage.

When navigating websites without the NavAccess prototype, all participants used techniques tofilter out irrelevant information (as illustrated by the exle above). These techniques involvedskipping content (e.g. using heading navigation or by performing an in-page search based on amemorized key string), which allowed them to only deal with the site content that was relevant forthe current task. This suggests that a learning phase can be used by blind users to create alternativenavigation paths, which allow them to only deal with the site content needed for the task at hand.When the relevant steps have been memorized, all other information can be discarded, keepingcognitive load to a minimum.

To be able to deal with excessive quantities of page content, blind users will try to filterinformation. Users of screenreader software generally use the link list (a list containing all presentlinks on the page), or heading navigation to quickly gain an impression of the page structure.

Based on the results mentioned above, three focus areas have been identified that identifyrelevant topics for designing website navigation systems for blind users. Since the prototype’s dualmode interface was experienced as confusing during the user evaluations, it is recommended thatall solutions suggested in these focus areas should be embedded in the main browsing interface, asopposed to separate navigation modes.

8 Website Navigation for Blind Users

Focus area 1: providing guidanceIn real life, one can assist a blind person by offering to help guide him or her, or describing what aroom looks like, what can be found in the room, and what can be done in the room.

The same can be done virtually. Often, however, the blind user is forced to listen through half apage of information before being able to determine whether it is relevant. A solution is needed thatwill provide the user with summary information about the current website as well as the current webpage. Also, what the user can do on the page needs to be mentioned, as well as the steps required tocomplete the possible actions.

Based on the success of the ‘link title alternatives’ function of the NavAccess prototype, it isrecommended that the user is provided with optional preview information about link targets. Thisinformation can help the user determine whether a specific navigation path section (e.g. following alink) is worth pursuing.

Focus area 2: empowering usersThe current research has shown that blind Internet users are very resourceful in dealing with complexsites. They identify landmarks that can be used to skip to relevant content, and are able to determinewhich steps are necessary to reach a certain goal. Rather than providing guidance through a website’sstructure, solutions are needed that act as additional tools which empower users to navigate moresuccessfully.

Focus area 3: reducing cognitive overloadAll participants made use of techniques that reduced cognitive overload, whether it was the use oflink or heading lists, skip links or memorized landmarks. A major problem for blind Internet users ishaving to deal with an overload of information, of which a relatively large part is not relevant to theuser’s goals. Such an overload reduces the user’s effectiveness (the user will lose track and becomedisoriented) and efficiency (navigation is time consuming and tedious to perform). While sightedusers can ignore information by scanning, blind users must rely on different techniques to filter outthe relevant from the irrelevant content. Navigation tools are therefore needed to help reduce theamount of information that the user has to read through.

Ongoing researchThe requirements for the second version of the NavAccess prototype, which was built from theground up as a Mozilla Firefox extension, were based on the feedback that resulted from the userevaluation sessions of the first prototype. The participant observation sessions offered a wealth of

Ongoing research 9

information about the type of functionality that was needed and the interaction design issues thatneeded to be addressed, as well as insight into the type of assistance that is needed to navigatewebsites. At the start, Evers and Hillen assumed that offering a correct mental model of the overallstructure of the site by audio would offer the same benefits as sighted users have when they have anidea of what the site is and what the main functions/content areas of the site are. However, in thestudy it became clear that blind users need to be supported in their way-finding which happens stepby step rather than from a macro level to a micro level.

A tool that addresses solutions for each focus area has been created in the form of a MozillaFirefox extension, called ‘NavAccess’. Mozilla is a suitable platform for user agent accessibilitysolutions because its code is open source and platform independent. This makes the Mozilla platforma good environment for a continuously evolving project which allows anybody who is interested tocontribute to its development.

The first completed module of the NavAccess tool is a link-list. Link-lists play an integral part innavigation within large and complex pages. However, the major screen readers that provide such listsonly include a limited functionality in them, making them less effective than they could be. Like thelink-lists of major screen readers, NavAccess allows the lists to be filtered by their visited/unvisitedstatus, and to be sorted alphabetically or in tab order. After having selected a link in the list, theuser can either move to it on the page where it occurs, or follow the link to its target. For longlists the user can perform a ‘first letter search’, allowing the user to jump to the first link startingwith that letter. Besides this basic interface, which has already been implemented in other screenreaders, NavAccess also includes additional functions that will reduce cognitive overload. First of all,the list can be filtered by removing duplicate occurrences in either the link’s title or target address.If the goal of the user is to find out which locations are reachable from the current page, it wouldbe pointless to have multiple links in the list pointing to the same target. Removing such duplicatesmakes sure that each link in the list is unique.

In addition to the duplicates filter, the user can cut down on the list length by using anincremental search filter to reduce cognitive overload. This function allows more advanced searchesthan the first letter search, because it will result in the links that contain the search query rather thanjust those that start with it. Each time the user adds a letter to the search query an update is givenstating the number of links resulting from the search action. A second, ‘negative search’ textbox ispresent to allow the users to specify the text that should not be present in the resulting links. Theincremental searches can be made case sensitive, and can be applied to either the link’s title or thelink’s target address. Finally, like the first prototype, this version of NavAccess allows the user torequest the textual context of the link so that the user will not have to close the list in order todiscover the meaning of a context dependent link.

By using these options in combination with the other existing filter options (visited/unvisited,remove duplicates), the user can shrink lists containing hundreds of links to just a handful (Figure 2).

10 Website Navigation for Blind Users

Figure 2 NavAccess second prototype screenshot (Mozilla Firefox Extension)

For further information about this project, please visit the full case study on the book websitehttp://www.id-book.com which provides more detail about this research and the researcherswho are doing the work. Through their work and others like them, tools to improve access to onlineinformation are being developed.

Order from Academic Writers Bay
Best Custom Essay Writing Services


Why Choose Us?

  • non-plagiarized Papers
  • 24/7 /365 Service Available
  • Affordable Prices
  • Any Paper, Urgency, and Subject
  • Will complete your papers in 6 hours
  • On-time Delivery
  • Money-back and Privacy guarantees
  • Unlimited Amendments upon request
  • Satisfaction guarantee

How It Works

  • Click on the “Place Your Order” tab at the top menu or “Order Now” icon at the bottom and a new page will appear with an order form to be filled.
  • Fill in your paper’s requirements in the "PAPER DETAILS" section.
  • Fill in your paper’s academic level, deadline, and the required number of pages from the drop-down menus.
  • Click “CREATE ACCOUNT ; SIGN IN” to enter your registration details and get an account with us for record-keeping and then, click on “PROCEED TO CHECKOUT” at the bottom of the page.
  • From there, the payment sections will show, follow the guided payment process and your order will be available for our writing team to work on it.

About AcademicWritersBay.com

AcademicWritersBay.comnbsp;is an easy-to-use and reliable service that is ready to assist you with your papers 24/7/ 365days a year. 99% of our customers are happy with their papers. Our team is efficient and will always tackle your essay needs comprehensively assuring you of excellent results. Feel free to ask them anything concerning your essay demands or Order.

AcademicWritersBay.com is a private company that offers academic support and assistance to students at all levels. Our mission is to provide proficient andnbsp;high quality academic servicesnbsp;to our highly esteemed clients. AcademicWritersBay.com is equipped with competent andnbsp;proficient writersnbsp;to tackle all types of your academic needs, and provide you with excellent results. Most of our writers are holders ofnbsp;master's degreesnbsp;ornbsp;PhDs, which is an surety of excellent results to our clients. We provide assistance to students all over the world.
We provide high quality term papers, research papers, essays, proposals, theses and many others. Atnbsp;AcademicWritersBay.com, you can be sure ofnbsp;excellent gradesnbsp;in your assignments and final exams.

error: Content is protected !!