Part 2
Drive File Stream Example
Google Drive is a web based application for storing and organizing files. It includes potential actions such as reorganizing files, viewing content, and sharing materials with others. It uses a standard system of storing folders and files within higher levels of folders. The concept of folders and files within other folders is generally well known, so screen reader users typically understand the concept before trying Drive for the first time. The design of the user interface helps a user take the organizational concept around which they already have a mental map and modify it to fit the steps necessary to navigate Drive. A key part of usability has to do with how easily a user can make the transition from the mental map they start with, to one that helps navigate any digital content.
Just as with any group of users, blind and low vision users have a wide variety of ability in their use of digital content. Users who have interacted with more kinds of content are more likely to feel familiar with the layout of information, because they have interacted with something similar before. Users who are more fluent with the use of their assistive technology are more likely to be able to create different kinds of maps, because they have access to different ways of navigating and accessing parts of content that the software provides. There are plethora of other factors that impact how a user approaches content, including other kinds of information they conceptualize, how they tend to think in general, and their confidence in imposing their own organization on content. The following examples of the ways two users create a mental map of Drive probably apply to more than one user, but the purpose is to start thinking about what mental maps might look like, not to demonstrate how every blind or low vision person approaches the app.
Content from a Screen Reader User’s Perspective
Here are three examples of how a screen reader user might organize and visualize the content on Drive:
Example 1: Geographical Map
The first way is linear, possibly like an outline. A screen reader user accesses content according to the order it appears in the DOM—the document as a computer understands it, not according to the visual appearance—regardless of where it appears on the screen. If there are headings with the appropriate markup already in the content, it impacts where divisions and groupings appear in the mental map, while helping the map take shape faster. Drive has too few headings, and they are generally not in logical locations, so the hierarchy in the following example comes from what the user accesses most often and/or useful landmarks (not ARIA landmarks). Drive has more ARIA landmarks than headings, but sometimes they are not meaningful, for example having two navigation landmarks with no differentiation in the name.
Note: Heading levels in the following examples do not represent proper hierarchy of content, but instead represent one user’s attention to each part of the content
(Labels of “something” or “stuff” refer to where the user knows there is content, but does not know exactly what the content is off the top of her head).
Something
Search
Stuff
Stuff
Google Account
Stuff
Stuff
Folders
Stuff
Stuff
Stuff
Stuff
Tree View
Stuff
Stuff
Stuff
Stuff
Stuff that occasionally changes and I accidentally wind up down here sometimes. Don’t have great sense of what all is going on down here.
End Example 1
Example 2: Shortcut Keys
The second mental map is based on shortcut keys and keystrokes the user employs to complete tasks or reach information. These are just a couple examples. When a user is familiar with an application, combinations of keystrokes can be useful to expedite tasks. However, time and energy are required to figure out and learn them. The other two examples in this section involve a more linear navigation through the app, as well as a spatial sense of relationship between parts of the app, whereas this second example does not intrinsically contain any spatial relationship. If knowledge of shortcut keys comes without any sense of the organization and division of content segments, it can be difficult to remember the shortcuts and to figure out new parts of the app or to figure out forgotten parts.
Example 2
g+n tab tab tab tab tab… go from box with top level folders to tree view
“C” Arrow Key Down twice to “Upload” Upload a file
“X” Select file Caps lock+Home Go to top of page Control+Caps Lock+”F” type “More” Enter Arrow Key Down to “Download” Download a file
End Example 2
Example 3: Elements List
The third example comes from an elements list. Most screen readers have a way to pull up a list of particular elements that appear in the content. For example, it might show a list of all the links, headings, and form fields. The user can then scan through the list or search the list by first letter to skip more quickly to the target. This is a function of the screen reader, but a developer can contribute to its effectiveness by using proper markup and labeling elements. The following example only specifies the elements the user remembers off the top of her head, she is aware of the others, but does not use them often enough to commit them to memory.
Example 3
Elements List
Window Spots Menu |
Links Menu |
Headings Menu |
Form Controls Menu |
Web Spots Menu |
Landmarks Menu |
|
|
|
|
Stuff Stuff |
|
|
|
|
|
|
New |
|
|
|
|
|
|
Stuff Stuff |
|
|
|
|
|
|
Remove |
|
|
End Example 3
Content from a Screen magnifier User’s Perspective
A screen magnifier user interacts much more with the visual nature of content, so their experience involves different issues from those of a screen reader user, who predominantly interacts with the DOM. Here are three examples of how a screen magnifier user might map Google Drive to help them navigate it:
Example 1: Visual Landmarks
One way a magnifier user might map digital content is with visual landmarks. Visual landmarks give the user a way to quickly scan through the content, locate information, and reorient when the user loses track of content or activity. Visual qualities of text such as size, format, and color can help elements stand out. Images and any other variations that stick out enough for someone to see without having to focus enough to read it can also be helpful. The most important quality is that the visual landmarks are always there and do not move. Any time someone is using something as a landmark, whether it be in digital content or navigating through the mountains, it is important for the landmark to be stationary in order to judge one’s own movement according to it. When someone navigates with a screen magnifier, they can only see a small part of the screen at one time. Sometimes a user can become disoriented, but knows where different parts of the page are with respect to a landmark. If the landmark moves, then it no longer fulfills its purpose.
Drive is good with respect to movement: the spatial relationships between content and features on the website do not change. Drive does, however, lack adequate visual landmarks. The few landmarks that do exist rely on color differentiation, which does not work for all users, particularly those who are colorblind. For many magnifier users, Google Drive is a flat white page with black and gray text and icons grouped in different ways throughout the page. There are no visual or structural cues to indicate that some of the black words are links in a sidebar, others are links or buttons in a top menu bar, and some are file names. With high magnification, a user can only determine where they are within the white field of the Drive page by scrutinizing the black or gray features, and repeatedly scrolling around to see where they are relative to the borders of the page.
One visual feature that does provide landmarks for users who see color are the icons that are used to differentiate file types. A magnifier user who scrolls down a long file list may see a series of gray (folders), green (sheets), or blue icons (docs). Patterns in the order of colored icons can help a magnifier user remember which portion of the list the user is currently viewing, and makes it easier to quickly scroll to a desired file.
Example 2: Continuity of Visual Content
A second mapping issue, for magnifier users, is spatial proximity of related items. The magnifier user only sees a small portion of the screen at one time, so if related content is not contained within the visible part of the screen, the user needs to know – either by convention or clues in the content – to shift to a different part of the screen. Typically, a submit button is just below the end of a form, and the text in an article runs predictably down the center of a page. When content violates these conventions, it can be difficult to find what comes next. Design patterns are conventions people have informally agreed upon by using them repeatedly. Since they appear in many places, a user is likely to have seen them before and already know what to expect and where to look. Frequent disrupters include large graphics, pop-up advertisements or large areas of blank space. These disruptions can cause a user to incorrectly assume that they have reached the end of relevant content.
Most of the links and features in Drive are in fairly predictable locations, and related features are close to each other. This greatly assists with navigation for a magnifier user. One area that might cause trouble, depending on degree of magnification, is the space between columns in the list view. The distance between the columns for “file name” and “file owner” may appear as a vast, white field, and a magnifier user may not know to scroll through this white space to reach the columns for “owner,” “last modified,” and “file size.” Even if a user does find these columns on the right side of the page, there is no way to visually connect the rows in these columns to the rows in the “file name” column.
Example 3:Nesting or Breadcrumbs
A final example of magnifier mapping techniques is “nesting,” or “breadcrumbs.” These remind users how they came to be where they are and how to return to various steps along the way. Examples of this are visual file paths, or menu bars that clearly indicate which portion of a website the user is on. For example, a line in Drive might show a series of folders: “Work/Drafts/Letters/May/”. These navigation aids assist all visual users, but are especially important for magnifier users, who may lack the context of viewing a whole page at one time.
Drive does have a visual file path in the top menu bar, reminding users where they are within a system of nesting files and allowing for easy navigation between levels. The visual design of this file path, however, makes it difficult for magnifier uses to identify it as such (this is a design and landmark issue – see above). Once a user knows where the visual file path is, however, it becomes an essential landmark– a portion of the webpage that a magnifier user can return to whenever needed to re-orient or navigate between files.