Towards more helpful bus tracker apps for blind transit riders
First Monday

Towards more helpful bus tracker apps for blind transit riders by Rakesh Babu and Paige Fuller



Abstract
Bus trackers aid in travel planning with real-time bus arrival and location information. However, their sight-centered design means they’re inherently challenging for the blind. A clear understanding of their help-seeking situations in interacting with bus trackers is necessary to design appropriate help features as a solution.

We present a qualitative method to study help-seeking situations of blind users in interacting with bus-trackers, and illustrate its application on the use of CTA bus tracker. Think-aloud observation of seven participants generated verbal reports of performing bus-tracking activities. Qualitative analysis explained what, where, and how help-seeking situations arose in learning the interface, in site interaction, determining estimated time of arrival, requesting ETA alerts, and finding bus location. We elaborate results pertinent to key help-seeking situations, the underlying help needs, and design implications for appropriate help features. The paper contributes a feasible qualitative method to study help-seeking situations, as well as valuable insights into the thoughts, actions and perceptions of blind users in real time bus tracking. This represents the first step towards developing the tool to transform the 45 million blind citizens into empowered transit riders. Implications for transit agencies, real time systems designers, and research in travel management, human-computer interaction and cognitive science are discussed.

Contents

1. Introduction
2. Literature review
3. Methods
4. Results
5. Design recommendations
6. Conclusions

 


 

1. Introduction

More than 1,300 public transit agencies with their fleets of buses and other vehicles presently offer urban transportation in major metropolitan areas of 92 countries (International Association of Public Transport, 2014).

Americans took nearly 11 billion transit rides in 2013, and this is expected to increase as public-transit-preferring millennials enter the workforce (TransitCenter, 2014). One section of the global population that needs public transit the most is the 314 million blind and visually impaired (World Health Organization, 2014), for whom driving is not an option.

A common complain of transit riders is related to waiting. The unpleasant experience of a waiting passenger is vividly captured in the following quote:

The wait for the bus is the worst wait. It’s worse than the wait to get to the front of the checkout line at Trader Joe’s — there at least the endgame is within sight. It’s worse than the wait at the doctor’s office, where someone has thoughtfully provided magazines and betta fish and soothing music. It’s worse than the wait for a table at any restaurant, where at least you have some hope of parlaying a free appetizer in exchange for all your patience. The bus, on the other hand, is invisible until it’s right in front of you. It could be a minute away. It could be 20 minutes away. You’re craning your neck around the corner, praying for the first glimpse of that electronic sentinel. YES! — when for all you know, the blasted thing passed two minutes ago. And maybe you’re late. Or it’s sleeting. There’s no one on hand to give reassuring updates or take escalating complaints. And the opportunities for distraction are minimal. (Badger, 2014)

According to a study on perceptions of transit riders (Watkins, et al., 2011), a wait typically feels 50 percent longer than it actually is.

Bus tracking technology offers an exciting solution to this problem, touted to be “the best thing to hit the morning” after the snooze button (Randall, 2014). A bus tracker is a software service providing real time information about bus arrivals and delays. Users can watch the changing location of their buses on a digital map (Goddin, 2013). Its benefits include more efficient trip planning, reduced wait times and increased confidence in public transit (Zhang, et al., 2008). Additionally, it affords scheduling closer connections with lower margins of error (Tang and Thakuriah, 2012). It can be especially handy for commuters in adverse weather conditions. According to a survey, 92 percent of riders reported significantly more satisfaction with public transit on using a bus tracker while fares, service frequencies, and vehicles remained unchanged (Watkins, et al., 2011). These apps serve as tools for rider empowerment (Biagioni, et al., 2011). This, coupled with transportation legislations like MAP-21 (Moving Ahead for Progress in the 21st Century), are driving the adoption of bus trackers across transit agencies (Goddin, 2013). As bus trackers gain significance for transit riders, it is imperative to study their utility for blind citizens.

Blind people comprise an atypical group of technology users with different cognitive and interaction strategies. Prior research (American Foundation for the Blind, 2012; Babu, 2013a and 2013b; Babu, 2014) informs that Web sites and Web-based apps do not offer blind users the kind of help they need to achieve their goals on their sight-centered environments. New and dynamic tools such as bus trackers with complex layout and functionality are expected to aggravate the problem if blind users don’t receive adequate help. The design of suitable help features requires knowledge we currently lack — blind users’ help-seeking situations in digital environment (Xie, et al., 2014). Exploratory research is needed to understand what, where, how and why help-seeking situations arise as blind users interact with bus trackers.

The purpose of this paper is to propose a qualitative method for an accurate, in-depth understanding of blind users’ help-seeking situations in real time bus tracking, and demonstrate its feasibility through exploratory field study with blind riders. Think-aloud observations generated rich verbal evidence of seven participants’ interaction experiences with the Chicago Transit Authority (CTA) bus tracker. Qualitative analysis provided a contextually-situated, experiential understanding of help-seeking situations in learning the interface, browsing the site, determining an estimated time of arrival (ETA), requesting ETA alerts, and tracking bus location. This understanding revealed their help needs that were not supported on CTA bus tracker. We discuss implications of these findings for the design of appropriate help features.

This research contributes a qualitative method for in-depth understanding of the help-seeking situations in using bus trackers. Additionally, it provides insights into the unique experiences and help needs of blind users in real time bus tracking. Findings will interest transit agencies, bus tracker developers, and scholars in HCI, cognitive sciences, information retrieval and travel management. The rest of the paper is organized as follows. We first provide working definitions of key terms and present a brief review of relevant literature. We then explain the proposed qualitative method and discuss its implementation. Then, we discuss the results of the qualitative analysis, followed by a discussion of design implications. We conclude the paper by describing the contributions, implications, limitations and future work.

 

++++++++++

2. Literature review

This section provides working definitions of key terms, including blind user, screen reader, bus tracker and help-seeking situation to contextualize the reader. Subsequently, it summarizes relevant literature on help-seeking situations and blind Web users.

Blind users

The blind comprise an atypical user group that employs unique cognitive and interaction strategies in digital environments (Babu, 2011). In this research, a “blind user” lacks the sight necessary to see information on a computer screen or point-and-click with a mouse. She relies on a screen reader (SR) to interact with computers and smart phones. The SR is a text-to-speech software that identifies text content on the screen and presents this aurally through a synthetic voice (Di Blas, et al., 2004). It offers specialized keyboard shortcuts for a range of operations. Such shortcuts, along with those offered by the operating system, enable the user to operate the computer non-visually (Babu and Singh, 2013). Commonly used SRs in terms of market share are JAWS (50 percent), NVDA (18 percent), and VoiceOver (10 percent) (WebAIM, 2014). Based on an extensive literature review, Babu (2013a) presents an overview of a typical Jaws user’s Web interaction experience as follows:

For the blind, Web interaction is a listening activity. Arriving on a Web site, she typically hears three SR announcements (Babu, 2011):

  1. Title of the Web page;
  2. Composition of the page in terms of interface objects (e.g., “Page has three frames, two headings, 20 links, three tables ...”).
  3. Text information on the page from top left to bottom right.

She may choose to stop the SR from these continuous announcements by pressing the Control key, and instead listen to bits of information using navigational keys such as the Arrows and Tab. The Down Arrow moves focus to next line and prompts the SR to read its content (e.g., blank, plain text, or the label of a link or form control) (Babu, 2011). The Tab key moves focus to the next link or form control, and then announces its label (Buzzi, et al., 2010). Interestingly, the SR presents a link or form control or (e.g., button, checkbox, input field) in a dedicated line. Consequently, the user perceives a single line of text with hyperlinked words to be spread over multiple lines. Three other keyboard shortcuts that blind users commonly employ are E, H, and Insert+F7 (Babu, 2013b). The E key moves focus to the next edit field, producing a click sound and announcing “Type a text.” The H key moves focus to the header of the next page section, prompting the announcement “Heading” followed by the title. The Insert+F7 key combination represents the Links List command, which places all the page links into a column for easier navigation and activation. Numerous other keyboard commands are available for a multitude of operations, the majority of which are rarely used (Leuthold, et al., 2008).

The above simplistic description of Web interaction experience with an SR is intended to help the reader gain a basic understanding of how a blind user may engage with a bus tracker.

Bus tracker

A bus tracker is a Web-based application to conveniently and efficiently track buses operated by public transit agencies. It allows riders to locate a bus, determine its estimated time of arrival (ETA), and sign up for ETA alerts. The two back-end systems at work include the Automatic Vehicle Locater (AVL) and the server (Biagioni, et al., 2011). The AVL is a GPS-based device installed in the bus capable of collecting and transmitting real-time location data. The server processes this AVL data along with data from the routes and buses database to estimate real time bus locations and arrivals (Biagioni, et al., 2011). A Web site or a mobile app furnishes this real-time information for riders. Real time transit information is considered one of the most important factors influencing transit ridership (U.S. Federal Highway Administration, 2004; Litman, 2008; Taylor and Fink, 2003). Riders who do not use bus trackers find public transit services unnecessarily difficult, spending extra time in travel (Thiagarajan, et al., 2010). On the other hand, riders who use these technologies experience shorter wait times and increased confidence on such services (Biagioni, et al., 2011). Additionally, use of these real-time tools significantly increases perceived security of late-night rides, and boosts overall satisfaction with the service (Zhang, et al., 2008). These positive perceptions of riders translates into increased ridership for the transit agency (Tang and Thakuriah, 2012). Consequently, many metropolitan areas around the world have either deployed, or are in the process of deploying bus trackers for the benefit of transit riders (Pu, et al., 2009). To ensure such benefits are reaped effectively, it is imperative that these emergent and complex applications help users accomplish their tasks regardless of abilities and technical skills. Help in this context refers to assistance or clarification regarding the solution, workaround, or remedial measure to negotiate a problem (Xie and Cool, 2009). Our long-term research objective is to develop help mechanisms to address the help-seeking situations blind users face in real-time bus tracking.

Help-seeking situation

According to the information retrieval (IR) literature, a help-seeking situation is characterized by a person engaged in retrieving information from a digital resource, and finds herself needing some sort of help to accomplish a task/goal (Xie and Cool, 2009). According to Xie and colleagues (2014), a help-seeking situation involving a blind user may arise due to a difficulty, a confusion, or a failure to complete a task. Literature on non-visual Web interaction (Babu, 2011; Babu, 2013a) informs that the sight-centered design of Web sites and Web applications presents roadblocks and hurdles for blind users in accomplishing their goals. A roadblock is a situation difficult or impossible to overcome without sight (Babu, 2011). It is navigable primarily with sighted assistance (Babu, 2013a). A hurdle is a situation navigable without sight but after spending extra time and effort (Babu, 2011). It can be reduced or eliminated with proper training (Babu, 2013a). In this paper, a help-seeking situation arises when the user faces a difficulty, confusion, failure, roadblock or hurdle to interact seamlessly with the bus tracker to achieve a goal. It triggers a need for some form of help from the bus-tracker, as opposed to human help, to proceed further.

Understanding help-seeking situations in systems interaction explains the help needs of users (Xie and Cool, 2009). It assists in discovering design errors that interfere with the proper access and use of content and controls (Babu, 2013b; Babu, et al., 2010). It helps designers create more effective help mechanisms for new and complex digital environments (Xie and Cool, 2009). Consequently, the study of help-seeking situations assumes significance for the design of more helpful bus trackers.

Prior research (Xie, et al., 2014; Xie and Cool, 2006; 2009) has focused primarily on help-seeking situations in retrieving information from digital libraries. Xie and Cool (2006) evaluated help features through structured interviews with sighted users. They found that while participants recognized the importance of system help for effective interaction, they were skeptical of the effectiveness of existing help features. Xie and Cool (2009) observed the digital library interactions of sighted participants performing keyword, browse-category, and known-item search. They reported seven broad categories of situations characterized by difficulties in: getting started; identifying relevant collections; browsing for information; constructing search statements; refining and monitoring searches; and, evaluating relevance of results. Xie and colleagues (2014) reported the findings of a pilot study on blind users help-seeking situations in digital libraries. They found that while blind users may face situations similar to their sighted counterparts, some unique situations may arise depending on the digital environment. For instance, digital libraries may present situations characterized by cognitive overload, comprehension problems, and difficulty reasoning. While these findings represent the first step towards understanding the help needs of blind users, it does not explain what situations may arise in real time bus tracking. Our research aims to address this literature gap.

Addressing the literature gap merits an in-depth investigation of the interaction experiences of blind users with bus tracking sites. It will require close examination of their thoughts, perceptions and actions in performing common tasks. This is best achieved through qualitative methods such as field studies, direct observations and open-ended interviews. Babu (2013b) demonstrates the feasibility of field studies with blind users engaged with a travel site. A task-oriented approach allowed examination of tasks and goals of interaction for a contextually-situated understanding of problems in deriving intended systems utility. User-centeredness afforded examination of the needs, abilities, and challenges of blind users in systems interaction, and explained experiences of navigating challenges in performing tasks. Xie and colleagues (2014) employed direct observations to examine blind users’ thoughts, perceptions and actions in interacting with digital library. Their study demonstrates the feasibility of this approach in understanding their help-seeking situations. We believe a synthesis of these two research approaches will be necessary to study the help-seeking situations of blind users in real time bus tracking. The following section describes the method we propose to study blind bus trackers’ help needs. The subsequent section demonstrates the feasibility of deriving intended results.

 

++++++++++

3. Methods

We conducted an exploratory field study with blind users to examine their thoughts, perceptions and actions in interacting with a bus tracker. It generated rich verbal evidence of their experiences in retrieving real-time bus arrival and location information for the Chicago metropolitan area. We employed a qualitative method to analyze this verbal evidence to understand what, where and how help-seeking situations arose. The following describes the participants, material, and procedure of our study.

Participants

Participants included seven individuals with diagnosed blindness (mean age=27 years) residing in the greater Milwaukee area at the time of the study. While three reported no light perception, the other four reported some light perception. All participants reported 10+ years of experience using the Internet with an SR. The participants’ self-efficacy with technology (computers, the Internet and the SR) was varied. Two participants were reportedly above average, three were average, while one was below average. E-mailing, information gathering, and socializing reportedly were the top three reasons for Internet use. They had reportedly used a trip planner like Google Transit at least once to plan bus journeys. However, none had ever used a bus tracker for real-time information.

Material

Materials included a study laptop, an external keyboard, a bus tracking site, and the observation study protocol. The study laptop was operated by Windows 7 OS. It was equipped with the JAWS 14 screen reader, the Audacity recording software, and three Internet browsers — Google Chrome, Mozilla Firefox and Microsoft Internet Explorer. The external keyboard was used to provide participants a standard key layout and clearly separated keys to work with. The text version of the Chicago Transit Authority (CTA) Bus Tracker (http://ctabustracker.com/bustime/wireless/html/home.jsp) was the bus tracking site chosen for the investigation. CTA bus tracker is one of the oldest bus tracking sites, and is used as a case study by other transit agencies planning to offer real-time bus tracking services to their riders. The observation study protocol comprised a MS Word document available on the home screen of the study laptop. It included four sections. The first section described the study objective. The second section explained the think-aloud method. The third section included instruction to spend 30 minutes exploring the bus tracker interface thinking aloud. The purpose was to make participants familiar with the site, and have them practice the think-aloud method. Additionally, it provided us the opportunity to check the quality of the recorded verbalizations. The fourth section included instructions for completing four bus tracking activities:

  1. Finding the ETA of buses running along a specific route in a specific direction at a specific stop;
  2. Finding the stop ID of a bus stop at a specified intersection for a specific route;
  3. Signing up for e-mail notification with ETA information; and,
  4. Determining the real-time location of a bus approaching a specific stop along a specific route.

Procedure

We scheduled one-on-one study session with each participant at a place and time of her convenience. Each session commenced with the participant reviewing the consent form and consenting to participate. She then logged on to the study laptop, examined the keyboard layout and the screen reader version to gain familiarity. She reviewed the Observation Study Protocol and understood the think-aloud method and the instructions. When she was ready to launch the bus tracker, we turned the Audacity recorder on to capture her verbalizations. While thinking aloud, she opened the browser of her choice, navigated to the bus tracker site, and explored its features for the next 30 minutes. At this point, we stopped the audio recording, and saved it with an appropriate name. After ascertaining the quality of this audio recording, we resumed the Audacity recorder. The participant returned to the bus tracker site and followed the instruction to attempt the four activities with concurrent verbalization. At the conclusion, we stopped the Audacity recorder, and saved the audio recording with an appropriate name.

The seven sets of audio recordings collected from participants were distributed among three transcriptionists. Each transcriptionist transcribed an audio recording in its entirety, clearly labelling participant utterances, SR announcements, investigator questions/comments, system sounds, and significant pauses. The transcripts were then distributed among three independent coders responsible for segmentation and coding. Segmentation involved decomposing a transcript into segments that each captured a unit of thought, perception or action. Coding involved categorizing segments as per the coding scheme presented in Xie, et al. (2014) and separating those categorized as difficulties, confusion, failures, roadblocks and hurdles. These five categories of segments comprised evidence of help-seeking situations. For reliability concerns, we considered only those segments similarly categorized by the three coders. By taking into account the adjoining segments, we reconstructed the help-seeking situation faced by the participant. By grouping these situations by task, we presented a contextually-situated depiction of the situation. Analyzing these situations with respect to the goal, we identified the underlying help need. Synthesizing all the results, we tried to explain what, where, and how help-seeking situations arose for participants in interacting with the CTA Bus Tracker, as well as their help needs in real time bus tracking.

 

++++++++++

4. Results

Qualitative analysis of the verbal reports collected from participants yielded very interesting results. It identified a host of help-seeking situations encountered, highlighted the experience endured, and revealed the help needs of blind riders in bus tracking. In Table 1, we provide a snapshot of our results, followed by a detailed description of specific help-seeking situations, grouped by the activities being performed.

4.1. Help-seeking situations in learning the bus tracker interface

Our analysis shows that blind users learning the bus tracker interface may not find it helpful enough. People typically explore a new site to get familiar with available features and functions. Blind users may accomplish this objective either by reading every bit of information with the Arrow keys, or skimming the page using keyboard shortcuts such as H to find section headers, E to find edit boxes, and so on. We observed four help seeking situations as participants explored the CTA bus tracker. In the following, we elaborate on these help-seeking situations.

The first situation is the confusion with last stop information. CTA bus tracker includes a link labelled “Last Stop: X” near the top of the home page, where X represents the name of the stop last looked up. Presumably, the purpose here is to aid bus tracking from a regularly visited stop. However, our participants found this last stop information confusing. The following quote captures evidence of this confusion.

S2: “Last stop.” Well, I don’t know what that means. I don’t know if it’s the last stop visited by the bus, or the last stop on the route. The latter seems more likely. But who knows for sure?

The above quote demonstrates the confusion of S2 on coming across the last stop link. At the core of this confusion was her failure to guess that it referred to the stop last looked up, not that last visited by a bus.

 

Table 1: Snapshot of results.
ActivityHelp-seeking situationsHelp needs
Learning the interfaceConfusion about last stop information.Help understanding and using “Last Stop” link.
Confusion about “Find by Stop Number” feature.Help understanding and using “Find by Stop Number” feature.
Difficulty finding adequate explanation of bus tracking.Help understanding function and use of site.
Difficulty recognizing links in bulleted list.Help identifying link embedded in a bulleted item.
Interacting with the siteRoadblock interacting with pages that become inaudible.Help perceiving content and operating controls veiled by a blank page.
Hurdle in navigating across input fields.Help navigating through input fields with trapping tendencies.
Hurdle in skipping irrelevant content and skim-reading relevant content.Help skimming pages without accessible section headers.
Finding ETA of busesDifficulty selecting route.

Help locating “Choose Route” section.
Help evaluating relevance of routes listed.
Help finding relevant route.

Difficulty selecting stop.

Help evaluating relevance of stops listed.
Help finding relevant stop.

Difficulty retrieving ETA information.

Help locating ETA statements section.
Help discerning ETA information in statements.
Help evaluating relevance of ETA statements.
Help interpreting ETA statement effectively.

Requesting ETA alertsFailure to register for e-mail alerts.

Help agreeing with terms and conditions.
Help selecting appropriate passwords.
Help navigating out of error dialogue box.

Difficulty requesting text alerts.

Help recognizing instruction to make request.
Help understanding relevance to ETA query.
Help effectively interpreting instruction.

Tracking real-time bus location

Failure to trace the map section.
Failure to find description of bus location.

Help retrieving and perceiving real-time bus location information.

 

The second situation is the difficulty finding by stop number. The CTA bus tracker includes a search feature comprising an edit box labelled “Find by Stop Number” and a “Find” button right below the “Last Stop” link on the home page. Presumably, the purpose here is to facilitate tracking buses while waiting at a stop displaying its stop number. However, our participants had difficulty understanding and using this feature effectively. The following quotes capture evidence of this difficulty.

S2a: “Find by stop number”. Well, I do not know what a stop number is. Does that mean route number?

S6: Ok, I went to an Edit Box. I think it wants me to enter a route number.

S1: “Find by Stop number”. I don’t know what that would do. I’m going to skip it for now.

S2b: I don’t think it matters what I type in here. It looks like it would say “bus stop not found.”

S4: I don’t know where to find the number of my stop. Without that number, I won’t be able to use this feature.

S2c: I can’t imagine that every person would know what the bus stop number is that they are talking about.

These remarks demonstrate the confusions of S1, S2, S4, and S6 with the “Find by Stop Number” feature. S2a and S6 demonstrate the difficulties participants faced in understanding what a stop number really meant, wondering if it was the route number. S1 and S2b demonstrate their difficulties in understanding the utility of this feature. S2c and S4 demonstrate their difficulty using this feature without having the stop number at their disposal.

The third situation is difficulty finding adequate explanation of bus tracking. The CTA bus tracker includes a link labelled “What is Bus Tracker?” near the bottom of the home page, apparently to explain bus tracking to new visitors. We observed that our participants found this explanation to be inadequate. The following quote captures evidence of this problem.

S7: <Link what is Bus Tracker?> That would be an interesting link to listen to. So press Enter on that. <Enter. CTA dash what is bus tracker .... Copyright 2014 Chicago.> So it didn’t really tell you much.

This remark demonstrates the failure of S7 to find an adequate description of a bus tracker — its features and functions.

The fourth situation is the confusion with a list of bulleted links. The CTA bus tracker includes bulleted links in the list of routes (on Select Route page), directions (on Select Direction page), and stops (on Select Stop page), apparently to highlight the different selection options. However, we observed that our participants had difficulty recognizing the link in a bulleted list item. The following quote captures evidence of this difficulty.

S5: This says “bullet.” I’m curious, because I don’t know how JAWS reads it. If it were like a combo box or something like that, you can just arrow down to it or use a hot key. <Bullet link. Bullet link westbound>. Oh! The two options have bullets in front of them. They kind of confused me. I could not tell if they were links. It says “bullet” first, instead of saying ”link” first. I’m so used to hearing ”link” first.

These remarks demonstrates the difficulty of S5 in recognizing the embedded link in the bulleted list of directions. The fact is she first heard “bullet” coming across a direction link, and not “link.” Hearing “link” first is as important to the blind as is the blue/purple and underlined formatting to sighted people in recognizing a link. Clearly, “bullet link westbound” is sufficiently different sounding than “link Westbound” for the purpose of non-visual recognition of a link.

Blind users learning the bus tracker interface may face multiple help-seeking situations. In particular, they may get confused with last stop information and “Find by Stop Number” feature while perusing the home page. They may have difficulty finding adequate explanation of bus tracking. They may also face difficulty recognizing a link in a bulleted list of items. Clearly, they need additional help understanding and using “Last Stop” link and “Find by Stop Number” feature, better explanation of bus tracking on the “What is a Bus Tracker” page, and help recognizing links embedded in items of a bulleted list.

4.2. Help-seeking situations in interacting with bus tracker

Our analysis shows that blind users interacting with the bus tracker may run into roadblocks and hurdles. We observed that participants faced one major roadblock and two major hurdles in interacting with the site. In the following, we elaborate on the roadblock and hurdles identified.

The roadblock occurs in interacting with a page whose content and controls suddenly become inaudible. It is characterized by a page abruptly appearing blank to the screen reader. All that one hears in such a situation is “Blank,” since the screen reader is failing to retrieve available information or interact with interface elements. The following quotes capture evidence of this roadblock.

S6: <Select direction. Page has six links>. So I need to go westbound. <Blank. Blank. Blank. Blank. Blank. Blank>. Ok. I’m trying to find the directions. It’s not giving me anything right now. <Blank. Blank. Title is. Select direction dash Internet Explorer. Blank. Blank. Blank. Blank. Blank. Blank. Blank>. That’s strange, it’s not popping up with my direction of travel. Either the Web site is having a problem loading it correctly, or there’s a lot of blank spaces. The latter doesn’t seem too logical. In any case, that’s not going to work.

S2: <List of 34 items. Bullet link 1510 S Michigan. Blank. Blank. Blank. Blank>. Oh! It is not reading it. <Title is. Select stop dash Internet Explorer. Blank. Blank. Blank. Blank. Blank>. Earlier it said “choose your stop,” and then briefly presented a list of, I think numbers and intersections. I do not think that was long enough for me to read it. I decided I would read this line by line. So to do that, I hit my Down arrow, and then I didn’t get anything. Hit it a few times. Did not get anything. And then I hit the Up Arrow with the “Say All” Insert NumPad Down arrow key. Nothing is happening, so now it doesn’t ... the screen reader doesn’t show the bus stop list now. I could go to my jaws cursor. <Route JAWS to virtual PC cursor. Canal and Adams slash Jackson>. And that will read it apparently. <Jackson and Chicago River. Jackson and Dearborn. Jackson and Financial Place>. And so that is using the JAWS cursor. If I go back to the PC cursor ... <Virtual PC cursor. Blank. Blank>. There’s nothing there. I can’t explain why there is nothing there.

These comments demonstrate the difficulties of S2 and S6 in interacting with the bus tracker whose page suddenly appeared blank. S6 had difficulty selecting the direction of travel for ETA determination as the Select Direction page suddenly appeared blank. S2 had difficulty choosing her stop for ETA determination as the Select Stop page turned blank. Although she was able to hear the list of stops ultimately using “Jaws Cursor” (an alternative screen reading mode), but failed to select her stop.

The first of the two hurdles is difficulty navigating across input fields that tend to trap the cursor. It is characterized by the keyboard focus getting stuck inside the field, disregarding common navigational commands (e.g., Arrow Keys). The following quotes capture evidence of this hurdle.

S2: <Find by stop number colon. Edit [Bip]. Blank. Blank. Blank. Blank. Blank. Blank. Blank. Blank>. Hmm. It seems like it’s not able to read anything. Let’s check the page title. <Title is. Select route dash Internet Explorer>. “Select route”. <Blank. Blank. Blank. Escape. [Boop.]>. Oops! I may have been in there. Because I hit Escape, and it sounded like it popped out of something. It seemed like the box had trapped me. What I did was, I ‘escaped’ from there, and I went to the bottom of the page to bypass that box. It seemed like every time I used the Down arrow to get through, I got trapped in the box.

S4: <Find by stop number colon. Edit [Bip.] Blank. Blank>. I’m stuck in the edit box. <Escape>. Um, Escape doesn’t seem to work. Let’s try to tab out of here. <Tab. Find button>.

S6: <Find by stop number colon. Blank. [Bip.] Type a text. Blank>. Ok I went to an edit box. It wants me to enter a stop number. I don’t know what that is. I’m going to find another way of doing this. <Blank. Blank. Escape. Blank. Blank. Blank>. And it doesn’t seem like it’s arrowing out of that box. <Blank>. I am in a stop number edit box. I guess it wants me to enter a bus stop id number. And I can type in something, which I have not done yet. But I want to arrow down past that box. It’s not letting me do. <Blank. Blank>. It doesn’t appear to be anyway. So I’m going to try hitting Escape. <Escape. Blank. Blank>. So that doesn’t do anything either. I can’t go out of that box. So I’m going to shift tab up. <Shift Tab. Link Cermak and Ashland.>

These statements demonstrate the difficulties of S2, S4 and S6 in navigating freely across the “Find by Stop Number” box (using Up and Down Arrows). S4 and S6 were aware of this trap in situ, while S2 realized it on reflection after freedom. Interestingly, the quotes reveal that an alternative navigational command that works in one situation may not work in another.

The second hurdle is difficulty skimming through a page to locate relevant information. It is characterized by the screen reader not recognizing section headers on the page. The following quotes capture evidence of this hurdle.

S4: Okay, on this homepage, first I’m going to explore by using H to see what headings are on the page. <There are no headings on this page>. That was the letter H for headings. I didn’t find any.

S5: I’m on the select route page. Instead of going through every possible route, I want to navigate to another grouping. I’m going to hit H for headings. <There are no headings on this page>. Okay, no headings. I thought it would be by heading. But it is not.

These remarks illustrate how S4 and S5 faced hurdles in skimming information when section headers could not be perceived. While S4 tried skimming for an overview of information presented, S5 tried it to filter out irrelevant information.

Blind users interacting with the bus tracker site are likely to encounter a roadblock in interacting with content and controls that become imperceptible, and hurdles in navigating across input fields and skimming page content without accessible section headers. The roadblock and hurdles represent key help-seeking situations for blind users in interacting with the bus tracker site. They will need additional help in interacting with pages tending to turn blank, in navigating through input fields with trapping tendencies, and in skimming pages without accessible section headers.

4.3. Help-seeking situations in finding estimated time of bus arrival

Our analysis shows that blind users looking for the estimated time of arrival may not find the bus tracker helpful enough. The CTA bus tracker affords ETA determination through a four-step process — route selection, direction selection, stop selection, and ETA information retrieval. We observed help seeking situations in completing all but one step for ETA determination. In the following, we identify the three problematic steps, and elaborate on the help-seeking situations they presented.

Route selection was the first problematic step of ETA determination. The CTA Bus Tracker affords route selection on the home page, titled “Select Route.” The “Choose Route” section displays a bulleted list of 127 route links. Route selection entails locating the “Choose Route” section, browsing through the routes list, identifying a relevant route link, and activating this link. We observed that participants faced three difficulties in route selection. The following quotes capture evidence of these difficulties.

S4: <[Bip.] Find by stop number colon. Type a text. B. Find button>. It’s pretty obvious from the edit box and the button that it wants me to enter a route on this page. I’m gonna enter number 12 <1 2> into the “By stop number” box, and press Enter. <Enter. Page has 139 links. Select route>. I’m arrowing down to find my number 12. Let’s see what the route box returns for me.

S7: <Choose your route colon. Blank. List of one hundred twenty seven items. Bullet link 1 dash Bronzeville slash Union Station ...>. Okay, there are over a hundred something sites here. I can try selecting the museum one to see what happens there. But, I may end up ultimately going to help, because there’s not a lot to choose from here.

S5: I want to select route 126 and see what its name or numbering scheme is. I’m going to get to the list of routes, which is Insert+F7. <Links list dialogue. Links list>. Pressing the Down Arrow. <One dash. Two dash. Three dash King Drive. Four. Five dash. Six dash Jackson Park Express.>. This is taking forever. Let me try pressing the number 1 to navigate to 126. <One. Ten. Eleven dash Lincoln. Twelve dash Roosevelt. 1. 100 dash>. Ok, now pressing Down Arrow to get to 126. <One. One. One. One. One. One. One. 126 dash Jackson. Link 126 dash Jackson>. Found it! That was kind of hard.

These observations note the difficulties of S4, S5 and S7 in completing different aspects of the route selection step. S4 had difficulty locating the “Choose Route” section, getting distracted and misled by the preceding “Find by Stop Number” feature. S7 had difficulty identifying a relevant route, getting bogged down by the numerous options and not seeing familiar names. S5 struggled locating a relevant route, having to deal with all the preceding irrelevant links.

Stop selection was the second problematic step in ETA determination. The CTA bus tracker affords stop selection on the third page after route selection, titled “Select Stop.” The “Choose your Stop” section displays a bulleted list of links that each correspond to a stop on the selected route. Stop selection involves locating this section, identifying a relevant stop from the list, and activating this link. We observed that participants faced two difficulties in stop selection. The following quotes capture evidence of these difficulties.

S5: What I’m going to do, if I can, is type the intersection. For that, I’ll have to find a box. So, the letter E for edit box. <There are no edit boxes on this page>. No boxes. But since no edit box, I can’t type it in.

S2: <Bullet link. Bullet link 2500 W Cermak>. That twenty five hundred west Cermak might be the first bus stop. Or, is it the origination point? But these things are in alphabetical order. That’s another issue. They seem to be in alphabetical order, rather than displayed in geographic order — in order of progression along the route.

These observations point out the difficulties of S2 and S5 in completing different aspects of stop selection. S5 had difficulty locating a relevant stop, failing to perform a quick stop search. S2 had difficulty judging the relevance of stops, failing to understand their relative positions along the route.

ETA information retrieval was the third problematic step in ETA determination. The CTA Bus Tracker displays ETA information on a new page after stop selection. An unmarked section on this page presents a list of ETA statements relevant to buses bound for the selected stop, irrespective of the route selected by the user. The statement takes the form:

Number N to X T min.

Where N is replaced by route number, X by route terminus, and T by time value in an actual statement. Above this ETA statements section is another unmarked section. That section displays current time, current temperature, selected route, selected direction, selected stop, selected stop number, instruction to request ETA text alerts, the “Only show buses for selected route” feature, and service bulletins. Retrieving ETA information entails locating the ETA section, Recognizing ETA statements, identifying relevant ETA statements, and interpreting a relevant statement. We observed that participants faced difficulties in all these aspects of ETA information retrieval. The following remarks capture evidence of these difficulties.

S2: Looking for the arrival time of bus number 12 going eastbound at the intersection of Ogden and Taylor. <Selected stop number colon 14203>. And it’s showing this to me, it’s showing me everything but as far as I can tell, an ETA. <Blank. Text quote CTABUS 14203 quote to 41411 for arrival times>. I’m going to reroute to the jaws cursor, I don’t know why. I’m doing this only because I can’t get any progress the other way.

S3: <Blank. Number 146 to. Separator. Number. Blank. Separator>. I guess it’s just giving me choices. I feel like I’m not doing this right. It seemed like it was giving me locations where if I took the Wacker bus that it would go to ... but, it might just be information about how long it would take to get to these different spots.

S5: <Number 126 to Congress Plaza 24 min>. It says “number 126”. Is that the bus route number? That’s easy to confuse with bus stop number. If they’re using “number” in both cases, it can be confusing.

S4: <Number 12 to 15th slash Indiana 13 min. Blank. Left paren bus. Separator. Blank. Number 12 to 15th slash Indiana 17 min. Left paren bus. Separator. Blank. Number 12 to 15th slash Indiana 22 min>. I have three or four different stops, each with a different time.

S6: The number above the number four here. <Number 3 to 79th 14 min>. The number 3 could be route 3. But if I chose 4, why would it be giving me number three?

S1: <Number 126 to Congress Plaza 24 min>. What is Congress Plaza? Is that another name for bus stop number one? It must be arriving at bus stop number one because I selected that number.

S7: <Number 126 to Congress Plaza 24 min>. I’m not sure if ... this is number 126 to Congress Plaza. It could be either arriving at bus stop number 1 or leaving bus stop number one. I’m not sure.

These impressions describe the difficulties of participants in completing different aspects of ETA information retrieval. S2 had difficulty locating the ETA section, being distracted by different pieces of related information. S3 had difficulty discerning the ETA information captured in the statements. S4, S5 and S6 had difficulty understanding relevance of ETA statements. While S5 was unsure of its relevance to the chosen route, S4 wasn’t sure of its relevance to the chosen stop, and S6 had difficulty filtering out irrelevant routes. S1 and S7 had difficulty interpreting different parts of a relevant ETA statement. While S1 mistook the route terminus Congress Plaza to be the name of her stop, S7 couldn’t tell if 24 minutes represented arrival time or departure time.

Blind users looking for ETA information may not find the bus tracker helpful enough. They may face difficulties in completing the route selection, stop selection, and ETA information retrieval steps of the process. These difficulties represent key help seeking situations for blind users in finding ETA information through the bus tracker. They will need additional help quickly locating “Choose Route” section, evaluating relevance of routes and stops from assigned link labels, and navigating to relevant route and stop links efficiently in query formulation. They will need additional help in quickly locating the ETA statements section, discerning ETA information in statements, identifying ETA statements relevant to chosen routes and stops, and interpreting a relevant ETA statement in full during the information retrieval process.

4.4. Help-seeking situations in requesting ETA alerts

Our analysis shows that blind users interested in receiving ETA alerts will find the bus tracker not helpful enough. Transit agencies issue ETA alerts via e-mail or text message on request. The CTA bus tracker includes directions on requesting e-mail and text alerts separately. We observed that participants could not follow these directions to request ETA alerts in either mode. In the following, we elaborate on the problems they faced in requesting e-mail and text alerts respectively.

Directions on requesting e-mail alerts is available on the ETA page through a link labelled “Would you like to receive CTA Bus Tracker predictions via e-mail?” This link leads a registered user to a request form to receive ETA alerts for the selected route, direction, and stop at the specified time of the day. Users without a bus tracker account are led to a sign up form to first register with CTA. We observe that participants failed to create this account. The following remarks capture evidence of three types of difficulties.

S3: I’m just using the Tab key to register. <Password. Edit. Type a text. Star. Star. Star. Star. Star. Star. Tab. Agree with the. Check box not checked>. What did I agree to? I don’t remember reading anything like that. <Tab. Terms and conditions of use link. Shift-tab. I have read and agree with the. Checkbox not checked>. I probably have to check that too. <Link terms and conditions. I have read and agree with the. Check box not checked>. What check box?

S2: <Password. Edit. Type a text>. Password. Let’s try this again. Six Character password. <Star. Star. Star. Star. Star. Star. Tab. I have read and agreed. Check box not checked. Tab. Space. Check box checked. Terms of use link. Blank. On occasion. Blank. Create account button. Enter. [Ding.] Message from Web page dialog. The password must be at least 6 characters long. Ok button. To activate press spacebar>. It was 6 characters long! I’m at the very end here where the button says “Create account.” I’ve entered my e-mail, name and password, and I continue to get the message “Password must contain six characters.” And my original password contained six characters, one of which was a numeral. That didn’t work. So I then used the same password the second time substituting a letter for that numeral. And it didn’t work again.

S6: So I’m going to go back through all this. <[Ding.] Mess. Back. Back. Enter. Create account dash. Back. [Ding.] Message from Web page dialog. The password must be at least 6 care. Enter. Create account dash Internet explorer>. It won’t let me go back.

These reactions show the difficulties of S2, S3, and S6 in creating a bus tracker account necessary to receive ETA alerts via e-mail. The quote from S3 demonstrates the difficulty in agreeing with the terms and conditions of use. First, she got confused as to what she must agree to on “seeing” the checkbox without the associated link. Then, she had difficulty associating the link to the checkbox. The quote from S2 demonstrates her failure to pick an appropriate password. In fact, all our participants received the same error message stating that passwords must be at least six characters long, even when they complied with this length requirement in password selection. The quote from S6 demonstrates her difficulty navigating away from the error dialogue to the registration form. She kept invoking the Back command (Alt + Left Arrow), expecting the cursor focus to move to the sign-up form from the error dialogue box.

Directions for requesting text alerts using a cell phone are available on the ETA page in the form of a statement formulated in this way:

Text “CTABUS #” to 41411 for arrival times

The # symbol is replaced by an integer in an actual statement, probably encoding the chosen route and stop numbers collectively. We observed that participants could not follow this direction effectively to request text alerts. They had three difficulties understanding the instruction as stated.

The first difficulty is recognizing this instruction itself. The following remark captures evidence of this difficulty.

S1: <Quote. C T A B U S. 14203. To 41411 for arrival times>. Ok, I hear it. And I can’t understand it. What am I supposed to do with those numbers for the arrival time? There’s no link to click on.

This observation indicates how S1 had difficulty recognizing this statement as directions to request ETA alerts via text message. The second difficulty is understanding the relevance of this instruction to one’s ETA query. The following remarks capture evidence of this difficulty.

S2: Looking for the arrival time. <Text quote CTABUS 14203 quote to 41411 for arrival times>. Well this could be it but I’m not sure.

S3: <Text quote CTABUS 1522 quote to 41411 for arrival times>. I think that has something to do with the real time. If we clicked on that, we would find out arrival times for different stops.

S7: <Text quote CTABUS 10565 quote to 41411 for arrival times>. There is no link here. So I would think that’s where they’d put that for arrival times. But there’s no actual link, unless it’s one of those picture links, which JAWS will not recognize.

These observations denote that while S2 had no clue what the statement was communicating, S3 and S7 guessed there might be an embedded link to a page with ETA information. The third difficulty is interpreting the instruction as stated. The following expressions provide evidence of this challenge.

S3: <Text quote CTABUS 1522 quote to 41411 for arrival times>. That doesn’t make sense to me. Unless I’m to write something in there because it’s a text. But it doesn’t sound like a text box. But it’s calling it a text. <Text quote CTABUS. Blank.> Let’s type in a time, and see if it will take it. <No text editing available.> Nope nope nope. It bothers me that that’s a text there but I can’t look at that.

S1: <Text quote CTABUS 69 quote >. I have no idea what that means. <Quote. C. T. A. B. U. S.>. CTA bus 69?

S5: <Text quote CTABUS 100 quote to 41411 for arrival times>. Transfer one bus to another bus? <Text quote CTABUS 100 quote to 41411 for arrival times>. I’m assuming those are the route numbers, I’m not quite sure what that means, not knowing the terminology.

S7: It’s 41411. Unless it says some kind of phone number or ... Would that be a text number, Twitter number? I don’t know.

These reflections demonstrate how S1, S3, S5, and S7 got confused with different aspects of the show. Confusing the word “text” with a text box, S3 construed this to be a label for an edit field. Confusing the word “CTABUS” with some kind of acronym, S1 spent some time and thought interpreting it. Uncertain what the two numbers 100 and 41411 referred to in the instruction, S5 thought it referred to transferring between buses. For S7, the point of confusion was the text number. She wondered if 41411 referred to a phone number, a text number, or a Twitter ID.

Blind users looking for ETA alerts may not find the bus tracker helpful enough. Those interested in receiving the alerts by e-mail may fail to create the needed account. Those who want the alerts via a text message may have difficulty following the directions as stated. The problems represent serious help seeking situations in placing requests for ETA alerts in various modes. Blind users will need additional help in agreeing with terms and conditions, selecting appropriate passwords, and navigating out of error dialogue box during registration necessary to request e-mail alerts. They will need additional help recognizing the instruction, understanding its relevance to the ETA query, and follow the instruction effectively to request text alerts.

4.5. Help-seeking situations in tracking real-time bus location

Our analysis shows that blind users interested in real-time bus location may not find the bus tracker helpful at all. The CTA bus tracker indicates real time bus location graphically using maps on a dedicated page. We observed that our participants could not locate this bus tracker feature with real-time bus location information. While it is a well-known fact that current screen reading technology does not recognize information conveyed by graphical representations such as maps, our analysis revealed that participants could not get anywhere close to this information. The following discussion capture evidence of this problem.

S3: My stop is Cermak and Ashland, and I need to find where the bus is now. I expect the site to say “It’s at Cermak and Bradley” or something. I don’t remember seeing a choice to figure that out presently. <Blank. Link would you like to receive CTA bus tracker prediction via email? Link refresh. Link new stop. Link home>. I don’t think it does. It doesn’t give me a choice to know where it is right now. I don’t see how I can find that real-time bus location, other than its 26 minutes away. Am I missing something?

S6: Trying to locate the bus in real time from my stop. I imagine there would be a link somewhere that says “find current bus location,” or “find current location.” But I am not finding that link anywhere.

S5: <Blank. Blank. List of. Bullet link 2500 W Cermak. Bullet link 25th Street and Mercy Hospital>. Hopefully, this will also give me the map for the route. <Bullet link 4542 W Cermak. Links list dialog. Link list view. 4542 W Cermak>. I’m trying to find the map of the route. But looks like I’ve gone too deep, because I already put the route and the direction. Now if I go with this, it’s going to give me the bus stop number for that intersection. Maybe if I take that one step further, there might be another link that would give me the separate pages? There might be a link there too.

These remarks point to the failures of S3, S5 and S6 in finding real-time bus location information. S3 expected this information on the ETA page for the selected route and stop as a text describing the intersection just traversed by the bus. S6 expected this information on another page accessible from this ETA page via a link labelled “Find Bus Location.” S5 expected the bus tracker to indicate real time bus location on a map accessible via a link. However, he expended a great deal of effort but could not find that link.

Blind users looking for real-time bus location information will be disappointed with the bus tracker. They will neither find this information in text format, nor find the path to the map that could possibly be described to them. This represents a critical help-seeking situation in finding real-time bus location. Blind users will need additional help retrieving and perceiving real-time bus location information.

To sum up our results, we identified multiple help-seeking situations that arose in learning the interface, interacting with the site, determining ETA, requesting for ETA alerts, and finding real-time bus location. Five things that characterized a situation include confusion, difficulty, failure, roadblock and hurdle. We tried to explain the what, where and how questions of each situation. Based on this understanding, we explicated the underlying help needs to highlight the inadequacies of existing help features. It is noteworthy that while the reported situations were experienced by multiple participants, quotes included as supportive evidence came from a participant who articulated the situation clearly.

 

++++++++++

5. Design recommendations

The qualitative analysis identified multiple help seeking situations in interacting with a bus tracker non-visually, and described what blind users are likely to experience. These help seeking situations are manifestations of help needs in completing common bus tracking tasks non-visually. They point to shortcomings in interface design to support the special needs of blind users. In the following, we elaborate on these design shortcomings, and present design recommendations to potentially avoid the identified help seeking situations. Our recommendations related to each help-seeking situation are summarized in Table 2.

 

Table 2: Snapshot of design recommendations.
Help-seeking situationsHelp needsDesign recommendations
Confusion about last stop information.Help understanding and using “Last Stop” link.State information in more conversational terms.
Confusion about “Find by Stop Number” feature.Help understanding and using “Find by Stop Number” feature.

Move below “Choose Route” section.
Include instruction on use and utility.

Difficulty finding adequate explanation of bus tracking.Help understanding function and use of site.

Include detailed description of bus tracking features and functions on “What is a Bus-Tracker” page.
Provide guidance on performing common tasks on “Help” page.

Difficulty recognizing links in bulleted list.Help identifying link embedded in a bulleted item.Do not describe bullets in the route list.
Roadblock interacting with pages that become inaudible.Help perceiving content and operating controls veiled by a blank page.Include instructions for how to cope with this situation.
Hurdle in navigating across input fields.Help navigating through input fields with trapping tendencies.Announce exit strategies.
Hurdle in skipping irrelevant content and skim-reading relevant content.Help skimming pages without accessible section headers.Create page sections. Label sections with titles at appropriate heading levels.
Difficulty selecting route.

Help locating “Choose Route” section.
Help evaluating relevance of routes listed.
Help finding relevant route.

Provide (a) “Find by Route Number or Name” feature near the top of the “Select Route” page; followed by (b) Level 2 Heading titled “Choose your Route”; followed by list of route links including (c) names of prominent streets and landmarks along the route in a LongDesc attribute
Difficulty selecting stop.

Help evaluating relevance of stops listed.
Help finding relevant stop.

Provide (a) “Find by Intersecting Streets” search feature near the top of the “Select Stop” page; followed by (b) Level 2 Heading titled “Choose your Stop”; followed by (c) “Show Stops in Geographic Order” sorting control; followed by (d) the list of stop links.
Difficulty retrieving ETA information.

Help locating ETA statements section.
Help discerning ETA information in statements.
Help evaluating relevance of ETA statements.
Help interpreting ETA statement effectively.

Provide (a) Level 2 Heading titled “Estimated Time of Arrival of Buses Serving your Stop” below the “Selected Stop Number” statement on the “ETA” page; followed by (b) Level 3 Heading titled “ETA of Buses on Selected Route”; followed by (c) list of ETA statements pertinent to chosen route in (d) grammatically correct sentences; followed by (e) Level 3 Heading titled ETA of Other Routes with the remaining ETA statements in correct grammar.
Failure to register for e-mail alerts.Help selecting appropriate passwords.

Provide (a) directives on choosing an appropriate password before the password fields; followed by (b) a link labelled “Terms & Conditions of Use; followed by (c) checkbox labelled “I Agree.”

Provide context-sensitive help explaining how to dismiss an error dialogue box and return to the registration form.

Difficulty requesting text alerts.

Help recognizing instruction to make request.

Help understanding relevance to ETA query.

Help effectively interpreting instruction.

Provide (a) link labelled “Want to receive SMS with ETA alerts?” below all ETA statements of chosen route; and (b) its target page with directions articulated using correct grammar and in conversational terms.
Failure to trace the map section. Failure to find description of bus location.Help retrieving and perceiving real-time bus location information.Follow ETA statements on the ETA page with a link labelled “Want to track where this bus is at present?” This link should open a page that describes real-time bus location in terms of the intersection just crossed, the distance to be covered, and the number of stops remaining before arriving at the selected stop.

 

Help-seeking situations in learning the bus tracker interface are manifestations of the special needs of novices trying to learn site features and functions. These situations reflect the limitations of existing help features in explaining the meanings, contexts and utilities of design elements to blind users. Specifically, the confusion due to “Last Stop” information indicates inadequate help clarifying its reference to the stop last tracked by the user, not that traversed by a bus. Perhaps it would be more helpful to state this in conversational terms like “Last stop you tracked”. The confusion due to the “Find by Stop Number” feature indicates inadequate help in understanding how to use it, and what will the outcome be. Since this feature is useful primarily when one is able to read the stop number flashed on a sign post at the physical bus stop, it would be helpful to move this below the “Choose Route” section, with instruction on its use and explain its utility. The difficulty finding adequate explanation of bus tracking indicates help pages did not explain different bus tracking features and functions effectively. It would be more helpful if the “What is a Bus Tracker?” page provided detailed description of key site features and functions, while the “Help” page provided step-by-step guidance on completing common bus tracking tasks and necessary keyboard operations. The confusion due to list of bulleted links indicates inadequate help identifying a link with a preceding bullet. Since bullets are useful primarily to grab visual attention, it would be more helpful to not describe these in the route list. This will ensure the screen reader first announces “link” followed by the route label while navigating through the list.

Help-seeking situations in interacting with the bus tracker site are manifestations of generic help needs of screen reader users. These situations reflect the limitations of existing help features in aiding non-visual interaction. Specifically, the roadblock due to interacting with pages that become inaudible indicates inadequate help in troubleshooting screen-reading glitches. Coding errors may cause glitches whereby interface elements become invisible to the screen reader. It would require a help feature that explains how to cope with such glitches, such as refreshing the page, routing Jaws to virtual PC cursor, etc. The hurdle in navigating across input fields indicates inadequate help in overcoming keyboard traps. It would be helpful to announce exit strategies, including appropriate key commands (e.g., Tab, Escape, etc.) when negotiating a keyboard trap. The hurdle in skipping irrelevant content and skim-reading relevant information indicates inadequate help in recognizing different sections of a page, and quickly locating a relevant section. It would help if every page is organized into sections, each section under a descriptive title, and each title assigned a heading at appropriate level.

Help-seeking situations in finding ETA information are manifestations of help needs in querying the bus tracker and retrieving the requested information non-visually. These situations reflect the limitations of existing help features in guiding blind users accomplish specific aspects of query formulation and information retrieval tasks. Specifically, help-seeking situations in the route selection step of query building reflect the limitations of existing help in arriving at the “Choose Route” section, evaluating relevance of routes, and navigating to a relevant route. It would be helpful to provide (a) a “Find by Route Number or Name” feature near the top of the “Select Route” page; followed by (b) Level 2 Heading titled “Choose your Route”; followed by list of route links including (c) names of prominent streets and landmarks along the route in a LongDesc attribute. Help-seeking situations in stop selection while query building reflect the limitations of existing help in evaluating relevance of stops and locating a relevant stop. It would be helpful to provide (a) “Find by Intersecting Streets” search feature near the top of the “Select Stop” page; followed by (b) Level 2 Heading titled “Choose your Stop”; followed by (c) a “Show Stops in Geographic Order” sorting control; followed by (d) the list of stop links. Help-seeking situations in retrieving ETA information reflect the limitations of existing help in arriving at ETA information section, recognizing statements with ETA information, identifying relevant ETA statements, and parsing key elements of a relevant statement. It would be helpful to provide (a) Level 2 Heading titled “Estimated Time of Arrival of Buses Serving your Stop” below the “Selected Stop Number” statement on the “ETA” page; followed by (b) Level 3 Heading titled “ETA of Buses on Selected Route”; followed by (c) a list of ETA statements pertinent to chosen route in (d) grammatically correct sentences, like “the first route 126 bus going towards Congress Plaza will arrive at your stop in 24 minutes”; followed by (e) Level 3 Heading titled ETA of Other Routes with the remaining ETA statements in correct grammar.

Help-seeking situations in requesting ETA alerts are manifestations of help needs in following directions to receive text alerts and e-mail notifications non-visually. These situations reflect limitations of existing help features in guiding blind users accomplish specific aspects of placing requests for text and e-mail alerts. Specifically, help-seeking situations in following directions to request for e-mail notifications reflects limitations of existing help in agreeing with terms and conditions of use, creating a valid password, and returning from error dialogue box to Web page during the registration process. It would be helpful to provide (a) directives on choosing an appropriate password before the password fields; followed by (b) a link labelled “Terms & Conditions of Use”; followed by (c) checkbox labelled “I Agree”; and (c) context-sensitive help explaining how to dismiss an error dialogue box and return to the registration form. Help-seeking situations in following directions to request text alerts reflects limitations of existing help in recognizing a statement with this direction, its relevance in the context of ETA information sought, and parsing its important elements. It would be helpful to provide (a) link labelled “Want to receive SMS with ETA alerts?” Below all ETA statements of chosen route; and (b) its target page with directions articulated using correct grammar and in conversational terms, like “Send text message to CTA at 41411” with the code “CTABUS 100” for SMS alerts with arrival times of buses on selected route and at selected stop.”

Help-seeking situations in finding real time bus location are manifestations of help needs in tracking the movement of a bus on a Web page non-visually. These situations reflect the limitations of existing help features in guiding blind users accomplish specific aspects of tracking bus location. Specifically, failure to trace the map section reflect limitations of existing help in recognizing the path to the section that contains real-time bus location information. Since this requires first selecting a route, direction and stop, perhaps it would be helpful to follow an ETA statement on the ETA page with a link labelled “Want to track where this bus is at present?” Failure to find description of real-time bus location reflect limitations of existing help in retrieving information about the current location of an approaching bus on a specific route vis-à-vis a specific stop. Perhaps it would be helpful if the link “Want to track where this bus is at present?” opened a page that describes real-time bus location in terms of the intersection just crossed, the distance to be covered, and the number of stops remaining before arriving at the selected stop.

 

++++++++++

6. Conclusions

This research was motivated by the belief that millions of blind riders cannot realize the espoused benefits of real-time bus tracking without adequate help. Developing help mechanisms appropriate for this population in effective interaction with bus trackers is hampered by a knowledge gap about their unique help-seeking situations and help needs. Synthesizing research approaches to study travel site usability (Babu, 2013) and help-seeking situations in information retrieval (Xie and Cool, 2009), this paper presents a qualitative method to examine blind users’ help-seeking situations in real-time bus tracking. The feasibility of this method is demonstrated through results of an exploratory field study with seven blind participants. Think-aloud observations generated rich verbal evidence of performing common bus tracking activities. Qualitative analysis identified possible help-seeking situations and help needs in non-visual interaction with bus trackers.

Results provided a contextually-situated, experiential understanding of blind users’ potential difficulties in learning the interface, interacting with the site, determining ETA of buses, requesting ETA alerts, and finding real-time bus locations. These situations are manifestations of the special needs in bus tracking without sight, and point to inadequacies in existing help mechanisms for blind users. These inadequacies are discussed along with remedial measures to design more helpful bus trackers for the blind.

The qualitative method proposed here may be feasibly used to better understand four under-studied domains. One domain is generic online tasks. Our method can afford studying the help-seeking situations and help needs of blind users in performing other bus tracking activities, retrieving other types of real-time information, and retrieving other types of online information. The second domain is technology validation. For instance, we may test the efficacy of existing help features and help mechanisms for non-visual interaction. The third domain is training. We may employ the method to discover the workarounds and coping strategies employed by blind expert users to inform the design of more powerful help mechanisms and user tutorials. The fourth domain is problem-solving. For example, we may study how blind users problem-solve a help-seeking situation compared to sighted users.

To the best of our knowledge, this study is the first attempt to investigate the help-seeking situations that blind users face in tracking the estimated arrival times and real-time locations of mass transit vehicles. Results of this preliminary investigation may interest multiple audiences. Public transit agencies may find it useful to know what aspects of real-time bus tracking are potentially challenging for blind riders, and thereby require special help features for real-time information. Scholars will find our qualitative method useful in developing a knowledgebase of help-seeking situations and help needs of blind Web users. Researchers in the cognitive sciences and human computer interaction may obtain a glimpse of how the blind think, act and perceive when faced with a help-seeking situation. This knowledge may be useful to test the efficacy of existing help systems and screen-reading technology. Developers and designers get some ideas about avoidable design choices in building real-time tracking tools for blind users. There are some limitations the reader should be aware of. The sample consisted of seven blind citizens of Wisconsin. Only the mobile/text-only version of CTA bus tracker was examined. Therefore, the results may not be generalized across the board. We are conducting a wider scale investigation involving a larger sample with diverse skillsets, other task contexts, over other public transit tracking sites/apps, using PCs and smart phones. The outcome will be a comprehensive knowledgebase about blind users’ help-seeking situations, help needs, and desired help features for tracking public transit vehicles on the Web. Subsequently, we will develop principles for the design of help features and help systems using experimental designs and prototypes. End of article

 

About the authors

Rakesh Babu is an assistant professor in the School of Information Studies at the University of Wisconsin-Milwaukee. He is blind and has strong motivation to undertake and promote research topics relevant to the empowerment of the blind in the information society. His research expertise includes help systems, Web accessibility and usability, human-centered computing, cognitive models, online education, social computing, travel and tourism management, and verbal protocol analysis. He has multiple prior and on-going externally-funded research projects sponsored by the National Science Foundation, European Research Council, and Research Council of Norway. His research appears in multiple peer-reviewed journals and conference proceedings. He is a regular reviewer for multiple journals and international conferences.
E-mail: babu [at] uwm [dot] edu

Paige Fuller is an adjunct instructor at the University of Wisconsin-Milwaukee.
E-mail: pfuller [at] uwm [dot] edu

 

References

Rakesh Babu, 2013a. “Developing more accurate competence models for improved e-learning for the blind,” Journal of Information Science & Technology, volume 9, number 2, at http://pascal.iseg.utl.pt/ojs/index.php/jist/article/view/139, accessed 25 September 2014.

Rakesh Babu, 2013b. “Understanding challenges in non-visual Interaction with travel sites: An exploratory field study with blind users,” First Monday, volume 18, number 12, at http://firstmonday.org/article/view/4808/3801, accessed 25 September 2014.
doi: http://dx.doi.org/10.5210/fm.v18i12.4808, accessed 19 May 2015.

Rakesh Babu, 2011. “Developing an understanding of the accessibility and usability problems blind students face in Web-enhanced instruction environments,” doctoral dissertation, University of North Carolina at Greensboro, at http://libres.uncg.edu/ir/uncg/f/Babu_uncg_0154D_10785.pdf, accessed 19 May 2015.

Rakesh Babu and Rahul Singh, 2013. “Enhancing learning management systems utility for blind students: A task-oriented, user-centered, multi-method evaluation technique,” Journal of Information Technology and Education: Research, volume 12, at http://www.jite.org/documents/Vol12/JITEv12ResearchBabu001-032.pdf, accessed 25 September 2014.

Rakesh Babu, Rahul Singh, and Jai Ganesh, 2010. “Understanding blind users’ Web accessibility and usability problems,” AIS Transactions on Human-Computer Interaction, volume 2, number 3, pp. 73–94.

Emily Badger, 2014. “How to make waiting for the bus feel much, much shorter,” CityLab (22 January), at http://www.citylab.com/commute/2014/01/why-technology-forever-changing-psychology-waiting-bus/8158/, accessed 25 September 2014.

James Biagioni, Tomas Gerlich, Timothy Merrifield, and Jakob Eriksson, 2011. “EasyTracker: Automatic transit tracking, mapping, and arrival time prediction using smartphones,” SenSys ’11: Proceedings of the Ninth ACM Conference on Embedded Networked Sensor Systems, pp. 68–81.
doi: http://dx.doi.org/10.1145/2070942.2070950, accessed 19 May 2015.

M.C. Buzzi, M. Buzzi, B. Leporini, and F. Akhter, 2010. “Is Facebook really ‘open’ to all?” 2010 IEEE International Symposium on Technology and Society (ISTAS), pp. 327–336.
doi: http://dx.doi.org/10.1109/ISTAS.2010.5514621, accessed 19 May 2015.

Nicoletta Di Blas, Paolo Paolini, and Marco Speroni, 2004. “Usable accessibility to the Web for blind users,” Proceedings of the Eighth ERCIM Workshop: User Interfaces for All, at http://www.ui4all.gr/workshop2004/files/ui4all_proceedings/adjunct/accessibility/109.pdf, accessed 19 May 2015.

Paul Goddin, 2013. “Data Palooza helps USDOT plan for our transportation future,” Mobility Lab (14 May), at http://mobilitylab.org/2013/05/14/data-palooza-helps-usdot-plan-for-our-transportation-future/, accessed 25 September 2014.

International Association of Public Transport, 2014. “History — More than 125 years advancing public transport,” at http://www.uitp.org/history, accessed 25 September 2014.

Stefan Leuthold, Javier A. Bargas-Avila, and Klaus Opwis, 2008. “Beyond Web content accessibility guidelines: Design of enhanced text user interfaces for blind Internet users,” International Journal of Human-Computer Studies, volume 66, number 4, pp. 257–270.
doi: http://dx.doi.org/10.1016/j.ijhcs.2007.10.006, accessed 19 May 2015.

Todd Litman, 2008. “Valuing transit service quality improvements: Considering comfort and convenience in transport project evaluation,” Journal of Public Transportation, volume 11, number 2, pp. 43–63, and at http://www.nctr.usf.edu/jpt/pdf/JPT11-2Litman.pdf, accessed 19 May 2015.

Wenjing Pu, Jie Lin, and Liang Long, 2009. “Real-time estimation of urban street segment travel time using buses as speed probes,” Transportation Research Record, volume 2129, number 1, pp. 81–89.
doi: http://dx.doi.org/10.3141/2129-10, accessed 19 May 2015.

Eric Randall, 2014. “Here’s to you, MBTA bus-tracking apps,” Boston Daily (22 January), at http://www.bostonmagazine.com/news/blog/2014/01/22/heres-bus-tracking-app/, accessed 19 May 2015.

Lei Tang and Piyushimita (Vonu) Thakuriah, 2012. “Ridership effects of real-time bus information system: A case study in the City of Chicago,” Transportation Research, Part C: Emerging Technologies, volume 22, pp. 146–161.
doi: http://dx.doi.org/10.1016/j.trc.2012.01.001, accessed 19 May 2015.

Brian D. Taylor and Camille N.Y. Fink, 2003. “The factors influencing transit ridership: A review and analysis of the ridership literature,” UCLA Department of Urban Planning, Working Paper, at http://www.uctc.net/papers/681.pdf, accessed 19 May 2015.

Arvind Thiagarajan, James Biagioni, Tomas Gerlich, and Jakob Eriksson, 2010. “Cooperative transit tracking using smart-phones,” SenSys ’10: Proceedings of the Eighth ACM Conference on Embedded Networked Sensor Systems, pp. 85–98.
doi: http://dx.doi.org/10.1145/1869983.1869993, accessed 19 May 2015.

TransitCenter, 2014. “Who’s on board 2014: Mobility attitudes survey,” at http://transitcenter.org/wp-content/uploads/2014/08/WhosOnBoard2014-ForWeb.pdf, accessed 25 September 2014.

U.S. Federal Highway Administration, 2004. “Traffic congestion and reliability: Linking solutions to problems” (19 July), at http://ops.fhwa.dot.gov/congestion_report_04/congestion_report.pdf, accessed 25 September 2014.

Kari Edison Watkins, Brian Ferris, Alan Borning, G. Scott Rutherford, and David Layton, 2011. “Where is my bus? Impact of mobile real-time information on the perceived and actual wait time of transit riders,” Transportation Research, Part A: Policy and Practice, volume 45, number 8, pp. 839–848.
doi: http://dx.doi.org/10.1016/j.tra.2011.06.010, accessed 19 May 2015.

WebAIM, 2014. “Screen reader user survey #5 Results,” at http://webaim.org/projects/screenreadersurvey5/, accessed 25 September 2014.

World Health Organization, 2014. “Visual impairment and blindness,” at http://www.who.int/mediacentre/factsheets/fs282/en/, accessed 25 September 2014.

Iris Xie and Colleen Cool, 2009. “Understanding help seeking within the context of searching digital libraries,” Journal of the American Society for Information Science and Technology, volume 60, number 3, pp. 477–494.
doi: http://dx.doi.org/10.1002/asi.20988, accessed 19 May 2015.

Iris Xie and Colleen Cool, 2006. “Toward a better understanding of help seeking behavior: An evaluation of help mechanisms in two IR systems,” Proceedings of the American Society for Information Science and Technology, volume 43, number 1, pp. 1–16.
doi: http://dx.doi.org/10.1002/meet.14504301203, accessed 19 May 2015.

Iris Xie, Rakesh Babu, Wooseob Jeong, Soohyung Joo, and Paige Fuller, 2014. “Blind users searching digital libraries: Help-seeking situations at the cognitive level,” iConference 2014 Proceedings, pp. 853–857.
doi: http://dx.doi.org/10.9776/14272, accessed 19 May 2015.

Feng Zhang, Qing Shen, and Kelly J. Clifton, 2008. “Examination of traveler responses to real-time information about bus arrivals using panel data,” Transportation Research Record, volume 2082, number 1, pp. 107–115.
doi: http://dx.doi.org/10.3141/2082-13, accessed 19 May 2015.

 


Editorial history

Received 29 September 2014; accepted 8 April 2015.


Creative Commons License
“Towards more helpful apps for blind transit riders” by Rakesh Babu and Paige Fuller is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Towards more helpful bus tracker apps for blind transit riders
by Rakesh Babu and Paige Fuller.
First Monday, Volume 20, Number 6 - 1 June 2015
http://www.firstmonday.dk/ojs/index.php/fm/article/view/5536/4576
doi: http://dx.doi.org/10.5210/fm.v20i6.5536





A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2017. ISSN 1396-0466.