Design Rationale Behind the First NavAccess Prototype

In casestudy_n_1, the researchers set out to make website navigation “more effective, efficient and pleasant for blind users.” Their design rationale began with a key observation: most existing accessibility solutions addressed only single web pages. The study states that “solutions that have been provided to improve website navigation for blind users mostly focus on one specific page,” while “little has been done to provide solutions that apply to a website.”

This mattered because blind users often had to develop workarounds tied to familiar pages or routes. As described in casestudy_n_1, participants memorized paths, counted rows and columns, and relied on landmarks such as a remembered phrase before the real content began. These strategies could work on a known site, but they were fragile: if a site changed, “a new ‘orientation phase’ was necessary.” This showed that page-level support was not enough for navigating complex, changing websites.

Why the Researchers Shifted to Website-Level Support

The move to website-level support came from the idea that blind users needed help understanding the overall structure of a site, not just the contents of the current page. According to casestudy_n_1, the prototype was designed around three “focus challenges”:

• providing guidance for blind users
• empowering blind users
• reducing cognitive load

A website-level approach could address these challenges better than isolated page fixes. Instead of forcing users to listen through repeated menus, banners, and irrelevant text on every page, the prototype aimed to reveal how pages and links fit together across the whole site. In this way, users could move more strategically and avoid unnecessary effort.

How the First Prototype Exposed a Site’s Infrastructure

The first NavAccess prototype created what casestudy_n_1 calls a “complete record of the ‘infrastructure’ of the given website.” This means the system captured the site’s structural organization—especially its links and their relationships—so that users could navigate based on the site’s architecture rather than only by reading each page linearly.

This infrastructure information was “communicated to the user interface using XML.” XML served as the format that transferred the structural record from the website model to the interface. Once available in the interface, that information could actively support navigation.

How the Interface Used the XML-Based Structure

As explained in casestudy_n_1, the interface allowed one-handed control through the numeric keypad. Using arrow keys, users could:

• move back and forth through the website’s link structure
• inspect the targets of links
• probe links without actually following them

This was important because it let users preview where navigation paths might lead before committing to them. The prototype therefore exposed not just page content, but the navigational possibilities of the site.

Two Styles of Navigation

The first prototype gave users access to two navigation styles, as described in casestudy_n_1:

• Navigating the site’s structure through the prototype interface — a lower-detail but faster way to move through the website efficiently.
• Navigating within pages — a more detailed way to work with the content and textual environment of links.

This design reflects the researchers’ rationale clearly: users needed both a broad structural overview of the website and access to page-level detail when necessary.

What the First Prototype Revealed About the Design

The prototype tested the idea that “revealing the website’s overall structure would improve website navigation for blind users” (casestudy_n_1). Although later findings showed that the second interface could be confusing, the first prototype was still important because it made the design logic visible. It demonstrated a shift from helping users cope with isolated pages to helping them understand and navigate an entire site through an interface powered by XML representations of the site’s infrastructure.

In short, the first NavAccess prototype was based on the belief that blind users need support at the website level. By modeling a site’s infrastructure and communicating it to the interface through XML, the researchers tried to provide guidance, reduce cognitive load, and give users more control over navigation.