Section 3: What did we do

Research setup

Prototype description

The prototype used for this study consisted of a server-based agent which crawled through all pages within a given website, followed each link it encountered (pointing to a page within the current site domain) and collected information about these links and the pages they lead to.

The result was a complete 'infrastructure' of the given website, which was then fed as XML to the user's interface. The interface that users used to navigate through this overall treestructure could be operated using only one hand, through buttons on the right numeric keypad.

Using the arrow keys the user could move back and forth the website's link structure, probing the targets of encountered links without actually following them. Because the target pages had already been parsed on the prototype's server, the user could request audio 'preview information' about where each link was leading, whether a link was working, whether it meant 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).

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 currently selected.

This approach caused the user to have access to two different types 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.
  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 has a higher level of detail, allowing a 'micro analysis' of the specific page.


Findings regarding blind navigation

Successful site navigation largely depends on whether or not the user is successful in exploring the website during an initial 'learning phase'. During 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 even arriving at the actual search results. So instead of having to listen through all this information on each visit, the particpant had memorized 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 way the participant had created a landmark that could be used on future visits (using the browser's 'find' function) to jump directly to the relevant location on the page.

In this learning phase, blind users create alternative navigation paths, so that they only have to deal with the site content relevant to the task they want to perform. All other information can then be discarded, so that the cognitive load will be kept 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 will use the link list (a list containing all present links on the page), or use heading navigation to quickly scan the page structure.

Based on the results mentioned above, three focus areas have been specified which will be discussed. These focus areas are broad topic areas of website navigation issues for blind users.

Focus areas

Focus area 1: providing guidance

In real life, one can take a blind person by the hand to guide him or her, 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 the blind user is forced to listen through half a page 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 can be done on the page should be mentioned, as well as the steps required to complete the possible actions.

Recommendations for focus area 1

The user must be provided preview information of link targets. On a basic level, blind user navigation consists of a sequence of steps, through which the user explores a virtual environment. If the step taken seems to be correct, the user will continue from this point, if not, the user will backtrack to the previous point. In complex website structures this trial and error approach can be tedious and time consuming, especially when the user is forced to try out certain steps due to a lack of or unclear description of a specific link’s target. Providing preview information will assist the user in deciding whether the link is worth following or not.

The user should have access to the main architecture of the website. In order to provide a limited form of overview on a website, the user should have access to the main categories in which a site’s structure is divided. This overview knowledge can be useful to point the user in the right direction (i.e. the right ‘section’ of a website), and allows the user to directly jump from one site category to the next. This main structure can be based on link statistics analysis (i.e. calculating which pages are linked to most often from other pages within the site), but should also include further advanced analysis of the content and structure of a website. For instance, certain pages which contain peripheral information such as disclaimers are generally linked relatively often in a website, but should not be identified as a main category. The site categories should be accessible separately from the main site’s interface, providing a separate site menu list which does not necessarily have to represent the categorization intended by the web designer. A link list would be a suitable interface to the main information architecture, accessible either through a shortcut or embedded in the existing link list interface provided by the user’s screen reader.

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 should act as additional tools which empower users to navigate more successfully.

Recommendations for focus area 2

The user should have more ‘undo’ power. It is easy for a blind person to become lost or disoriented while trying to form a path to a specific goal. Either the most recent steps chosen prove to be incorrect (forcing the user to backtrack several steps), or the user loses track on his or her current location within the site and specific page (causing the user to lose the path). Even when the browser’s back function is used it does not always mean the user is automatically returned to the last known position on that previous page. Users should be provided with more functionality that allows them to explore possible paths while minimizing the risk of becoming lost.

The user should with external memory to store gained knowledge gained during a learning phase. When a user discovers how a specific task (for instance logging into a site, or looking up a certain item in a database) is performed during a learning phase, this task can still be tedious to repeat during succeeding visits. An example is a task which spans multiple complex pages, containing landmarks that are not easy to remember. The agent should be aware of this process, and allow the user to store the gained knowledge during this learning phase. This way, the user will no longer be forced to memorize relevant landmarks.

Focus area 3: reducing cognitive overload

A major problem regarding website navigation by blind Internet users is having to deal with an overflow of information, of which a relatively large part is not relevant to the user’s goals. Such an overload can cause both problems regarding the effectiveness (the user will lose track and become disoriented) and efficiency (navigation is time consuming and tedious to perform) of user navigation. While sighted users can ignore information by scanning, blind users must rely on different techniques to filter out the relevant from the irrelevant content. A navigation tool should therefore aid the user in reducing the amount of information which has to be read through.

Recommendations for focus area 3

Large pages are difficult to navigate due to cognitive overloading. The user should be provided with the means to have this content shrink to a more manageable size, in order to be able to work with it.

Providing context information about currently selected link. Navigating through the use of link lists causes a link to be isolated from its context, and can consequently be more difficult to interpret. Links which contain the same title but occur in different sentences will sound as duplicates in a link list, even though they have different targets. By parsing a document’s source code and determining whether the link is surrounded by textual content, the agent can attempt to determine a logical starting and end point by which the context should be bounded, such as the use of periods and capital letters to identify sentences.

Links should be categorized based on relevance, type, or subject category. A large set of links can be easier to navigate through when grouped into more manageable categories. Ideally, these categories are created through clustering methods which extract significant keywords for each page within a site, allowing the agent to group the links on a page based on similarities between their target page’s keyword descriptions. However for this approach to be effective it is necessary for these categories to actually make sense, which cannot be guaranteed using an automated approach on diverse material found on WWW sites. Another useful categorization would be based on which links are relevant to the user’s goal, as interpreted by the agent. For this to work the agent must posses a correct understanding of what the user is looking for, as well as an understanding of what the link targets are about. A third approach to link categorization is by their function within the website’s structure. Some links are part of the website’s main information architecture, while other links lead to more peripheral information (such as site configuration or disclaimers).

When visiting a page, the agent should allow the user to directly skip to relevant content. Most websites consist of pages which have a navigation section (usually a menu of some sort) and page specific content. The navigation generally remains consistent up to certain extent during site navigation, while the page related content (which in essence ‘is’ the page) is what the user is looking for (either in order to decide which step to take next, or because the page content contains the user’s final goal). The user agent should be able to recognize which code belongs to the navigation content and which code belongs to the page related content, allowing the user to directly jump to the relevant part of the page.

The NavAccess Project: current developments

For this research, the development of a tool that bundles solutions for each focus area has been initiated in the form of a Mozilla Firefox extension, still under the name ‘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 of navigation within large and complex pages. However, the major screen readers that provide such lists only include a limited functionality to them, making them less effective than they could be. Like the link lists of major screen readers, NavAccess allows the list 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 currently already has 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 pointing to the same target be present in the list. Removing such duplicates makes each link in the list is unique. Next to the duplicates filter, the user can cut down on the list length by using an incremental search filter (as described in the ‘reducing cognitive overload’ focus area). 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 be applied to either the link’s title or the link’s target address. Finally, like the first NavAccess prototype, the link list 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. Using these options in combination with the existing other filter options (visited/unvisited, remove duplicates), the user can shrink lists containing hundreds of links to just a handful.