Evaluation Findings: What Worked and What Did Not

According to casestudy_n_1, the prototype evaluation showed mixed results. The original idea behind NavAccess was that exposing the overall structure of a website would help blind users navigate more effectively. However, the testing showed that this central idea did not work as expected in practice.

Main result: the second interface was confusing

The evaluation reported that “having a second interface was confusing for the participants” (casestudy_n_1). NavAccess added an extra layer of interaction on top of the website itself. Users could move through the site structure using the prototype interface and probe link targets without following them. Although this was designed to support faster, broader navigation, it also meant users had to manage two systems at once:

• the website and browser they were already using, and
• the new NavAccess interface with its own controls and logic.

This extra layer increased complexity rather than reducing it. The source also notes that blind users do not have constant visual feedback about available options and need time to learn controls, which helps explain why the second interface became burdensome instead of helpful (casestudy_n_1).

Why users were not interested in building a whole-site mental model

casestudy_n_1 explains that participants were “not interested in building a mental model” of the website’s full structure. Instead of trying to understand an entire site as a complete map, users focused on reaching the specific information or function they needed.

The study shows that blind users already use practical strategies to deal with complex websites. These include filtering out irrelevant material, skipping repetitive content, using headings, performing in-page searches, and relying on remembered landmarks. For example, one participant used a familiar phrase located just before search results as a landmark to jump directly to the useful section of the page (casestudy_n_1).

This suggests that users did not see much value in learning the structure of a whole site when their actual goal was more immediate:

• find the relevant part of the current page,
• judge whether a path is worth following, and
• complete a task efficiently.

In other words, participants preferred local orientation and task-focused shortcuts over constructing a broad structural model of the website.

What showed value in the evaluation

Although the structure-revealing interface was not successful, some functions were clearly useful. The most important positive finding in casestudy_n_1 was the success of the “link title alternatives” feature, which provided optional preview information about link targets.

This function was valuable because it let users estimate where a link would lead before deciding to follow it. The case study recommends providing preview information about link targets because it helps users decide “whether a specific navigation path section ... is worth pursuing” (casestudy_n_1).

Other useful directions identified in the source include:

• summary information about the current website and current page,
• clear information about what actions are possible on the page, and
• support for skipping irrelevant content and shrinking large link sets to manageable choices.

These features matched how participants actually worked: they wanted help filtering, previewing, and targeting relevant content rather than exploring site-wide structure.

Overall assessment

The evaluation in casestudy_n_1 shows that the less successful part of the prototype was its attempt to present the whole website structure through a separate interface. This was confusing and did not fit users’ goals. The more successful part was support for focused decision-making during navigation, especially link target previews. The main lesson is that tools for blind web users should emphasize task-oriented guidance, local context, and efficient filtering instead of expecting users to build a complete mental map of an entire site.