Fluent Essays

Business Use Case Study You have been assigned to one of four case studies as described in the syllabus. The files to the case studies are attached to this assignment by clicking the links. The assignment is due at 11:59pm on Sunday EST. The instructions are as follows: · The assignment is worth 50 points.  · This is an individual deliverable.  The assignment requires a 4-6 page review, not including cover page, abstract, and a reference page, of the business use case you have been assigned. · Use Case 3 -  Download Answer the following questions: · 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 Users Hans Hillen and Dr. Vanessa Evers, University of Amsterdam Abstract 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. Prototype description 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 following them. 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 were added: — 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 prototype. 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. Participant 6 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 supermarkets 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 considered useful. 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 page. 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 successfully. 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. Ongoing research 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.