SKIP TO MAIN CONTENT HOME SECTION 1 SECTION 2 SECTION 3 SECTION 4
About this section
This section provides abasic description of ourresearch. Besides theproblems which havebeen discussed in section1, we wanted to get abetter understanding ofthe problems related toblind website navigationand possible solutions forthese problems. Aprototype was developedand evaluated, and three‘challenge focus areas’were specified.
Blind navigation
To understand how blind users navigate, it is interesting tounderstand the way blind people travel in general. Somecharacteristics of this form of travel are:
Navigation is divided into a large number of smallsteps, each of a low level of complexity. After each stepthere is a phase of reorientation.
When traveling, most blind people will 'probe' theenvironment in the direction they are moving. This way,relevant landmarks which lie ahead can be detectedand anticipated. Such landmarks can be either cues(landmarks aiding travel, such as a skip link pointing tothe start of a page's main content) or obstacles(landmarks inhibiting travel, such as an inaccessiblemultimedia object). A successful journey is one wherecues can be maximized and obstacles minimized.
Research methodology
The goal of this research was to create a prototype that would make navigation of websitesmore 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 awebsite as a whole. The goal of this research was to provide such a solution.
A prototype was developed and evaluated during user sessions with blind participants.
Prototype description
The prototype used for this study consisted of a server-based agent which crawled throughall pages within a given website, followed each link it encountered (pointing to a pagewithin the current site domain) and collected information about these links and the pagesthey lead to.
The result was a complete 'infrastructure' of the given website, which was then fed as XMLto the user's interface. The interface that users used to navigate through this overalltreestructure could be operated using only one hand, through buttons on the right numerickeypad.
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 targetpages 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
Section 3: What did we do
Research setup
What did we do http://www.id-book.com/preece/whatdidwedo.html
1 of 6 3/24/2022, 12:52 AM
as an image or a PDF file).
For each link the system checked how many times the link occurred on the site comparedto the total number of pages within the website. If a link occurred on more than 80 percentof the pages, it would be identified as a 'main link', and made available through separateinterface 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 navigationhas a low level of detail but allows the user to move around the website in a fast andefficient manner, making it possible to have a 'macro level overview' of the website as awhole.
2. Navigating a specific page through the standard browser interface. When a page ofinterest was encountered in the prototype macro level overview, the user would be ableto switch to the main browser and access the page. This form of navigation is slowerthan the first navigation style but has a higher level of detail, allowing a 'micro analysis'of the specific page.
User sessions set up
User sessions were conducted with ten blind participants,each session consisting of the following phases:
1. A semi – structured interview, in which the participantswere asked about the way their impairment influencedtheir daily lives, the role the Internet played in theirdaily lives and the problems they have in accessingwebsites.
2. An observation session, where participants were askedto show a website they frequently visit and show thetasks they normally carry out on this website whilebeing observed by the experimenter. This way, moreknowledge could be obtained about which problemsblind Internet users encounter, and the ways in whichthey work arount these problems.
3. Finally, the participants were asked to navigate a site'sstructure using the prototype, and to give their opinionon several of its key features.
Pictures taken duringuser sessions
Findings regarding prototype
The main idea behind the prototype was that offering an the website's overall structurewould improve website navigation for blind users. However, the results showed that havinga second interface was confusing for the participants. Second, the participants were notinterested in building a mental model of the site as a whole. The reason for this was thatthey already needed to focus on the 'one page at a time' issues. In other words, providing asecond 'view' of the website led to cognitive overload.
Using sounds to provide preview information was also considered distractive, asparticipants already had to use the auditory channel to interpret the screen reader'sspeech. The preview information itself was considered useful.
Other ‘peripheral’ functionality, such as the identification of main links or the ‘one-hand’interface’ was considered to be useful as well.
Findings
What did we do http://www.id-book.com/preece/whatdidwedo.html
2 of 6 3/24/2022, 12:52 AM
To conclude: Offering a separate interface to a website’s overall structure does not improvewebsite navigation for blind users.
Findings regarding blind navigation
Successful site navigation largely depends on whether or not the user is successful inexploring the website during an initial 'learning phase'. During this learning phase the userattempts to locate useful landmarks on the website, which can then be used in subsequentvisits to the site for more efficient and effective navigation. For example, during theobservation sessions one participant visited a website where a person's address can befound based on last name and city. The page containing search results was tedious tonavigate through because the participant had to listen through a lot of irrelevant contentsuch as menus, banners and additional lines before even arriving at the actual searchresults. So instead of having to listen through all this information on each visit, theparticpant 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 theresults. 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 onlyhave to deal with the site content relevant to the task they want to perform. All otherinformation 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 filterinformation. Users of screenreader software will use the link list (a list containing all presentlinks 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 willbe discussed. These focus areas are broad topic areas of website navigation issues forblind users.
Focus area 1: providing guidance
In real life, one can take a blind person by the hand to guide him or her, 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 the blind user is forced to listen through half a pagebefore being able to determine whether it is relevant. A solution is needed that will providethe user with summary information about the current website as well as the current webpage. Also, what can be done on the page should be mentioned, as well as the stepsrequired 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 usernavigation consists of a sequence of steps, through which the user explores a virtualenvironment. If the step taken seems to be correct, the user will continue from this point, ifnot, the user will backtrack to the previous point. In complex website structures this trialand error approach can be tedious and time consuming, especially when the user is forcedto 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 worthfollowing or not.
The user should have access to the main architecture of the website. In order to provide alimited form of overview on a website, the user should have access to the main categoriesin which a site’s structure is divided. This overview knowledge can be useful to point the
Focus areas
What did we do http://www.id-book.com/preece/whatdidwedo.html
3 of 6 3/24/2022, 12:52 AM
user in the right direction (i.e. the right ‘section’ of a website), and allows the user to directlyjump from one site category to the next. This main structure can be based on link statisticsanalysis (i.e. calculating which pages are linked to most often from other pages within thesite), but should also include further advanced analysis of the content and structure of awebsite. For instance, certain pages which contain peripheral information such asdisclaimers are generally linked relatively often in a website, but should not be identified asa main category. The site categories should be accessible separately from the main site’sinterface, providing a separate site menu list which does not necessarily have to representthe categorization intended by the web designer. A link list would be a suitable interface tothe main information architecture, accessible either through a shortcut or embedded in theexisting 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 dealingwith 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 thanproviding guidance through a website's structure, solutions should act as additional toolswhich 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 ordisoriented while trying to form a path to a specific goal. Either the most recent stepschosen prove to be incorrect (forcing the user to backtrack several steps), or the user losestrack on his or her current location within the site and specific page (causing the user tolose the path). Even when the browser’s back function is used it does not always mean theuser is automatically returned to the last known position on that previous page. Usersshould be provided with more functionality that allows them to explore possible paths whileminimizing the risk of becoming lost.
The user should with external memory to store gained knowledge gained during a learningphase. When a user discovers how a specific task (for instance logging into a site, orlooking up a certain item in a database) is performed during a learning phase, this task canstill be tedious to repeat during succeeding visits. An example is a task which spansmultiple complex pages, containing landmarks that are not easy to remember. The agentshould be aware of this process, and allow the user to store the gained knowledge duringthis learning phase. This way, the user will no longer be forced to memorize relevantlandmarks.
Focus area 3: reducing cognitive overload
A major problem regarding website navigation by blind Internet users is having to deal withan overflow of information, of which a relatively large part is not relevant to the user’sgoals. Such an overload can cause both problems regarding the effectiveness (the user willlose track and become disoriented) and efficiency (navigation is time consuming andtedious to perform) of user navigation. While sighted users can ignore information byscanning, blind users must rely on different techniques to filter out the relevant from theirrelevant content. A navigation tool should therefore aid the user in reducing the amount ofinformation which has to be read through.
Recommendations for focus area 3
Large pages are difficult to navigate due to cognitive overloading. The user should beprovided with the means to have this content shrink to a more manageable size, in order tobe able to work with it.
Providing context information about currently selected link. Navigating through the use oflink lists causes a link to be isolated from its context, and can consequently be moredifficult to interpret. Links which contain the same title but occur in different sentences willsound as duplicates in a link list, even though they have different targets. By parsing a
What did we do http://www.id-book.com/preece/whatdidwedo.html
4 of 6 3/24/2022, 12:52 AM
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 contextshould 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 oflinks can be easier to navigate through when grouped into more manageable categories.Ideally, these categories are created through clustering methods which extract significantkeywords for each page within a site, allowing the agent to group the links on a page basedon similarities between their target page’s keyword descriptions. However for this approachto be effective it is necessary for these categories to actually make sense, which cannot beguaranteed 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’sgoal, as interpreted by the agent. For this to work the agent must posses a correctunderstanding of what the user is looking for, as well as an understanding of what the linktargets are about. A third approach to link categorization is by their function within thewebsite’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 ordisclaimers).
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 somesort) and page specific content. The navigation generally remains consistent up to certainextent during site navigation, while the page related content (which in essence ‘is’ thepage) is what the user is looking for (either in order to decide which step to take next, orbecause the page content contains the user’s final goal). The user agent should be able torecognize which code belongs to the navigation content and which code belongs to thepage 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 hasbeen 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 opensource and platform independent. This makes the Mozilla platform a good environment fora continuously evolving project which allows anybody who is interested to contribute to itsdevelopment.
The first completed module of the NavAccess tool is a link list. Link lists play an integralpart of navigation within large and complex pages. However, the major screen readers thatprovide such lists only include a limited functionality to them, making them less effectivethan they could be. Like the link lists of major screen readers, NavAccess allows the list tobe 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 itoccurs, or follow the link to its target. For long lists the user can perform a ‘first lettersearch’, allowing the user to jump to the first link starting with that letter. Besides this basicinterface, 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 targetaddress. If the goal of the user is to find out which locations are reachable from the currentpage, it would be pointless to have multiple links pointing to the same target be present inthe list. Removing such duplicates makes each link in the list is unique. Next to theduplicates filter, the user can cut down on the list length by using an incremental searchfilter (as described in the ‘reducing cognitive overload’ focus area). This function allowsmore advanced searches than the first letter search, because it will result in the links thatcontain the search query rather than just those that start with it. Each time the user adds aletter to the search query an update is given stating the number of links resulting from thesearch action. A second, ‘negative search’ textbox is present to allow the users to specifythe text that should not be present in the resulting links. The incremental searches can bemade 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 textualcontext of the link so that the user will not have to close the list in order to discover themeaning of a context dependent link. Using these options in combination with the existing
What did we do http://www.id-book.com/preece/whatdidwedo.html
5 of 6 3/24/2022, 12:52 AM
other filter options (visited/unvisited, remove duplicates), the user can shrink listscontaining hundreds of links to just a handful.
What did we do http://www.id-book.com/preece/whatdidwedo.html
6 of 6 3/24/2022, 12:52 AM