Hc A6 The assignment requires a 5 page review, not including cover page, abstract, and a reference page, of the business use case you have been assigned.
Hc A6 The assignment requires a 5 page review, not including cover page, abstract, and a reference page, of the business use case you have been assigned.
Summarize the case study
Identify the study method used and why it was appropriate
Explore some of the qualitative or quantitative methods gathered.
Answer these two additional questions:
How would you conduct the study any differently?
Given the nature in the advance of technology, how do you foresee technology changing the way studies such as these are conducted in the future? Website Navigation for Blind
Hans Hillen and Dr. Vanessa Evers, University of Amsterdam
In this case study Mr. Hillen and Dr. Evers focus on the problems that blind people can encounter
when they try to navigate a website. Having investigated these problems they propose some possible
solutions which are embedded in a prototype, NavAccess, that was developed and evaluated to
address three types of issues that the authors refer to as ‘‘focus challenges’’. These are: providing
guidance for blind users; empowering blind users; and reducing cognitive load.
Research goal and approach
The goal of this research was to create a prototype, known as NavAccess, that would make navigation
of websites more effective, efficient and pleasant for blind users.
So far, the solutions that have been provided to improve website navigation for blind users
mostly focus on one specific page. Little has been done to provide solutions that apply to a website
as a whole. The goal of this research was to provide such a solution. In order to achieve this goal a
prototype, NavAccess, was developed and then evaluated during user sessions with blind participants.
The prototype used for this study consisted of a server-based agent that crawled through all pages
within a given website, followed each link it encountered (but only those pointing to a page within
the 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 of
similar web navigation improvement tools for blind Internet users were described. Secondly, the User
Agent 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 & 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 Accessibility
Guidelines (WCAG) 1.0 were also observed, although the actual content of the NavAccess tool was
limited to simple strings of text.
Finally, news groups frequently used by blind Internet users were observed, as well as accessibility
web forums such as http://www.accessifyforum.com/. With these guidelines, the first
prototype was developed.
The result was a complete record of the ‘infrastructure’ of the given website, which was then
communicated to the user interface using XML. This information was then available at the interface
to help the user navigate the site (see Figure 1 for example), which could be done using only one
hand, through buttons on a numeric keypad. Using the arrow keys the user could move back and
forth through the website’s link structure, probing the targets of encountered links without actually
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 a
low 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 was
encountered in the prototype macro level overview, the user would be able to switch to the main
browser and access the page. This form of navigation is slower than the first navigation style but
it 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 functions
— Because the target pages had already been parsed on the prototype’s server, the user could request
audio ‘preview information’ about the content of the page the link lead to, whether a link was
working, whether it resulted in leaving the current domain, whether it was a different protocol
than 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 example of preview information is the use of ‘link title
alternatives’ which the user could request to hear the actual title of the target page rather than
the 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 to
the total number of pages within the website. If a link occurred on more than 80 percent of
the pages, it would be identified as a ‘main link’, and made available through separate interface
controls. This way the user would always have important links such as ‘home’ available, regardless
of 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 phrase
is only ‘‘here’’) are difficult to understand when viewed in a different environment (e.g. a screen
reader’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 two
different styles of navigation.
Testing the two different navigation styles
User sessions were conducted with ten blind participants to test the navigation styles. Each session
consisted of the following phases:
1. A semi-structured interview, in which the participants were asked about the way their impairment
influenced their daily lives, the role the Internet played in their daily lives and the problems they
experienced when accessing websites.
2. An observation session, where participants were asked to visit a website they frequently visit
and 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 Internet
users encounter, and the ways in which they work around these problems, before they tested the
3. Finally, the participants were asked to explore a website (www.danbrown.com) using the
Navaccess prototype, and think aloud while doing so.
The blind participants were given an introduction to the system, in which the main functionalities
of the NavAccess interface were described and explained. After the introduction, the participants
were allowed five minutes to freely explore the interface. During this phase, the experimenter read
out the main functions and key combinations whenever requested, as a help option would. This
approach was chosen because the actual NavAccess help content had not been implemented yet
in this early prototype, and also to collect feedback about how often users needed to refer to the
help when using the system. After this ‘try-out’ phase, the site model of an earlier website accessed
by NavAccess (http://www.danbrown.com) was loaded into NavAccess as a datasource. The
participants 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 pilot
with two users made it clear that structured tasks were too cumbersome. Because blind users have to
remember the controls, do not have constant visual feedback of options available and it takes time
to learn, the decision was made to observe the participants’ experience of using the NavAccess main
controls and functions while freely navigating the Dan Brown website. The instructions that they
were 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 Internet
while using the NavAccess interface. The participant was asked to think out loud. Participants chose
their own website and set their own task. Data collected by the researchers included: the age of the
participant, visual capabilities of the participant, the accessibility aids used by the participant, Internet
and computer experience, how the participant had learned to use the Internet, what he/she uses the
internet for, the website accessed in the session, the nature of the task, the duration of the task, the
think aloud protocol, and the user log of the session.
Because of the small number of participants in this study, the evaluation results were qualitative
data. An example of results for a participant is as follows.
Profile: A 55-year-old male who had been completely blind for 33 years. He used JAWS software as
a 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), a
virtual 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 ideal
for a blind person because every visitor had to use their imagination, thereby removing the difference
between blind and sighted users. The participant mentioned that he does not try to find out how a
page’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 that
he encourages the use of frames (whereas frames are often mentioned as an accessibility obstacle)
because they allowed him to skip inaccessible content. An example of a task completed in this part
of the evaluation is:
Website: http://www.albert.nl, an online store which delivers groceries for major Dutch
Task description: Find out how much it costs to have groceries delivered next Tuesday, 5pm.
Duration of task: approx. 15 minutes
User 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 content
before realizing this and switches to the browser application. The participant has learned the necessary
steps needed to login into the site by heart, and knows that the login form on the site’s homepage
does not work with his assistive technology (the input fields can be selected but are not described
by the screen reader). The participant accidentally presses enter while a link was selected, and ends
up on an unfamiliar page. To undo this error, he uses the browser’s back-function to return to the
starting page. However, the location he returns to cannot be read correctly by his screen reader. At
this 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 to
take 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 places
the product in the participant’s shopping basket, but since he is not logged in yet he is rerouted to a
login page containing a form, which can be read by assistive technology. By doing a page search for
the 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, the
delivery times are displayed as a table, with days of the current week in columns, and the delivery hours
in rows. Each cell contains the cost to have groceries delivered at that specific day and time. While
the participant describes the table, the researcher notices that the participant’s mental visualization of
the table has the dimensions switched: the days in rows and the hours in columns. The participant
listens through the table using the down arrow key. It is difficult to remember which value belongs
to which row and column combination, also because some cells are empty. When the participant
has identified the delivery cost for the day and time specified, it turns out he is mistaken by one day
because he thought the table started at a different day. Since he used this incorrect information to
navigate 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 knowing
which obstacles to avoid (the inaccessible login form) the participant took a detour to arrive at his
destination, and by memorizing necessary steps (such as counting rows and columns) the participant
knew exactly how to navigate within his predefined path. This approach is only possible when
one has a lot of experience with a specific website, and will most likely fail when a website’s
content or structure is updated over time. The participant mentioned that when this happened a
new ‘orientation phase’ was necessary.
Pictures taken during user sessions
Findings from the prototype user evaluation
The main idea behind the prototype was that revealing the website’s overall structure would improve
website navigation for blind users. However, the results showed that having a second interface was
confusing for the participants. Furthermore, the participants were not interested in building a mental
model of the site as a whole. The reason for this was that they wanted to focus on ‘one page at a
time’. In other words, providing an alternative ‘view’ of the website led to increasing, rather than
decreasing cognitive overload as the researchers intended.
Using sounds to provide preview information was also distracting, as participants already had to
use the auditory channel to interpret the screen reader’s speech. The preview information itself was
However, the participants’ feedback on each specific key point of the NavAccess showed that
they 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 these
peripheral functions and embedded within the browser’s main navigation interface. Offering an
alternative interface to show the overall structure of the website did not improve website navigation
for blind users.
Discussion of the findings 7
Discussion of the findings
All participants performed specific navigation actions that required knowledge about the website’s
structure and functioning that was obtained earlier. These actions allowed participants to skip content,
circumvent accessibility obstacles, or create alternative navigation paths. When asked about these
actions, each participant indicated that usually, an initial phase is required to familiarize oneself with
a website, in order to navigate it in an effective, efficient and comfortable manner. Therefore it
seems that successful website navigation largely depends on whether or not the user is successful
in exploring the website during an initial ‘learning phase’. In this learning phase, the user attempts
to locate useful landmarks on the website, which can then be used in subsequent visits to the
site for more efficient and effective navigation. For example, during the observation sessions one
participant 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 to
listen through a lot of irrelevant content such as menus, banners and additional lines before getting
the search results. So instead of having to listen through all of this information on each visit, one
participant remembered that the actual search results always started after the words ‘search in this
city’s surroundings’, because this link happened to be located just before the results. This served
as a landmark that could be used on future visits to jump directly to the relevant location on the
When navigating websites without the NavAccess prototype, all participants used techniques to
filter out irrelevant information (as illustrated by the example above). These techniques involved
skipping content (e.g. using heading navigation or by performing an in-page search based on a
memorized key string), which allowed them to only deal with the site content that was relevant for
the current task. This suggests that a learning phase can be used by blind users to create alternative
navigation 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, keeping
cognitive load to a minimum.
To be able to deal with excessive quantities of page content, blind users will try to filter
information. Users of screenreader software generally use the link list (a list containing all present
links 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 identify
relevant topics for designing website navigation systems for blind users. Since the prototype’s dual
mode interface was experienced as confusing during the user evaluations, it is recommended that
all solutions suggested in these focus areas should be embedded in the main browsing interface, as
opposed to separate navigation modes.
8 Website Navigation for Blind Users
Focus area 1: providing guidance
In real life, one can assist a blind person by offering to help guide him or her, or describing what a
room 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 a
page of information before being able to determine whether it is relevant. A solution is needed that
will provide the user with summary information about the current website as well as the current web
page. Also, what the user can do on the page needs to be mentioned, as well as the steps required to
complete the possible actions.
Based on the success of the ‘link title alternatives’ function of the NavAccess prototype, it is
recommended that the user is provided with optional preview information about link targets. This
information can help the user determine whether a specific navigation path section (e.g. following a
link) is worth pursuing.
Focus area 2: empowering users
The current research has shown that blind Internet users are very resourceful in dealing with complex
sites. They identify landmarks that can be used to skip to relevant content, and are able to determine
which steps are necessary to reach a certain goal. Rather than providing guidance through a website’s
structure, solutions are needed that act as additional tools which empower users to navigate more
Focus area 3: reducing cognitive overload
All participants made use of techniques that reduced cognitive overload, whether it was the use of
link or heading lists, skip links or memorized landmarks. A major problem for blind Internet users is
having to deal with an overload of information, of which a relatively large part is not relevant to the
user’s goals. Such an overload reduces the user’s effectiveness (the user will lose track and become
disoriented) and efficiency (navigation is time consuming and tedious to perform). While sighted
users can ignore information by scanning, blind users must rely on different techniques to filter out
the relevant from the irrelevant content. Navigation tools are therefore needed to help reduce the
amount of information that the user has to read through.
The requirements for the second version of the NavAccess prototype, which was built from the
ground up as a Mozilla Firefox extension, were based on the feedback that resulted from the user
evaluation 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 that
needed to be addressed, as well as insight into the type of assistance that is needed to navigate
websites. At the start, Evers and Hillen assumed that offering a correct mental model of the overall
structure of the site by audio would offer the same benefits as sighted users have when they have an
idea of what the site is and what the main functions/content areas of the site are. However, in the
study it became clear that blind users need to be supported in their way-finding which happens step
by 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 Mozilla
Firefox extension, called ‘NavAccess’. Mozilla is a suitable platform for user agent accessibility
solutions because its code is open source and platform independent. This makes the Mozilla platform
a good environment for a continuously evolving project which allows anybody who is interested to
contribute to its development.
The first completed module of the NavAccess tool is a link-list. Link-lists play an integral part in
navigation within large and complex pages. However, the major screen readers that provide such lists
only include a limited functionality in them, making them less effective than they could be. Like the
link-lists of major screen readers, NavAccess allows the lists to be filtered by their visited/unvisited
status, and to be sorted alphabetically or in tab order. After having selected a link in the list, the
user can either move to it on the page where it occurs, or follow the link to its target. For long
lists the user can perform a ‘first letter search’, allowing the user to jump to the first link starting
with that letter. Besides this basic interface, which has already been implemented in other screen
readers, 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 would
be pointless to have multiple links in the list pointing to the same target. Removing such duplicates
makes 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 an
incremental search filter to reduce cognitive overload. This function allows more advanced searches
than the first letter search, because it will result in the links that contain the search query rather than
just those that start with it. Each time the user adds a letter to the search query an update is given
stating the number of links resulting from the search action. A second, ‘negative search’ textbox is
present to allow the users to specify the text that should not be present in the resulting links. The
incremental searches can be made case sensitive, and can be applied to either the link’s title or the
link’s target address. Finally, like the first prototype, this version of NavAccess allows the user to
request the textual context of the link so that the user will not have to close the list in order to
discover 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 website
http://www.id-book.com which provides more detail about this research and the researchers
who are doing the work. Through their work and others like them, tools to improve access to online
information are being developed.