Google Web Apps, when accessed via the browser interface, are displayed in a dynamic HTML environment. For Screen reader users this creates a bit of a tricky environment to navigate.
A Bit of Background
Screen readers were designed to leverage HTML information from web browsers to make navigating static web pages easier to navigate and interact with. In an effort to make sure this post doesn't get to techy, but gets the point across that one needs to understand what browse mode is and when/how to enable/disable it, I'll say that screen reader manufactures created a virtual buffer in which the HTML information is placed so that the text-to-speech software can treat it much like a text document. The buffer allows the user to move among the elements, including text, in a more meaningful way. The keys on the keyboard become "quick navigation" hot keys, so-to-speak. A good example would be that the letter H becomes a quick navigation key to move to/among headings, if they are written into the HTML code, for a web page. Sometimes though, letters need to be letters, so that information can be input into the web page, right? So, that buffer has to be a feature that can be turned on and off. Screen reader manufactures have made this feature pretty intuitive, and many screen reader users don't think much about it when their computer makes different pitched popping sounds at them. It is just second nature, one just knows, that when there is a higher pitched "pop" noise then letters will be entered in a field on the web page, and when a lower pitched "pop sound" is heard letters will equal these quick navigation functions...
Google Web App Interfaces are not static web pages however; they are made up of some traditional, static, HTML elements, and some newer dynamic HTML elements. Screen reader users must now learn when, and how, to toggle that browse mode, or virtual view, on and off.
Jargon Jumble
Those familiar with the JAWS screen reader may be familiar with the term "forms mode". Forms mode is turned on to allow for text entry, or interaction with controls, in forms on web pages. By turning forms mode on the screen readers virtual view is temporarily suspended. When accessing Google Web App Interfaces in Fire Fox, as suggested, the edit fields are not recognized as traditional edit fields, and the forms mode is not automatically enabled for text entry. The hot key to toggle the virtual view on and off is MODIFIER + Z. This is different than using the NUM PAD PLUS (+) to turn forms mode off, or SPACE BAR/ENTER to turn forms mode on if it does not automatically enable when an edit field is encountered.
For those familiar with the Window Eyes and NVDA screen readers the term "browse mode" is used to refer to the virtualization of the HTML content. When browse mode is on the alphanumeric keys of the keyboard will perform an action related to moving around the virtual environment. When browse mode is disabled keyboard commands apply directly to the edit field or control in focus on the web page. Window Eyes and NVDA screen readers both automatically disable browse mode when a new Google Web App Interface page loads in Firefox. There may, however, be times that it is necesary to enable browse mode to accomplish a task, like activating a link in the Google bar. Window Eyes users press CONTROL + SHIFT + A, and NVDA users press MODIFIER + SPACE BAR to toggle browse mode on and off.
NVDA users may also be familiar with the term "focus mode". This term is similar in use to the term "forms mode" when discussing the JAWS screen reader. Focus mode is the mode in which key commands impact the edit fields or controls on the web page directly. When focus mode is on browse mode is off and vice-versa.
Working In Google Web App interfaces
The Google Web App Interfaces contain a variety of dynamic controls. Google developers have created keystrokes for navigating among and activating the different dynamic controls. For example, in Google Drive, to open the settings menu, the hotkey is the letter T. When browse mode is turned on, while using a screen reader however, T = Tables, and the screen reader attempts to locate an HTML table, rather than move to and open the settings menu of the page. The key sequence G, then N, when a screen readers browse mode is enabled would tell the screen reader to move to the first graphic, then move to the next HTML element that does not have a tag. When the browse mode is disabled however the sequence G, then N would move the focus to the list of different views available to display items in drive.
The existing Google Web App interface documentation, for accessibility using screen readers, does not always make note of the state of the users browse mode. When reviewing hotkey lists I've frequently found that pressing the keys listed in the documentation results in my losing my place on the web page, and feeling frustrated. Understanding that the state of browse mode is an important thing to track has vastly improved my Google Web App experience, and made trouble shooting these disorienting experiences a breeze.
The conflict between screen reader keystrokes for accomplishing tasks while working with static web pages and the hotkeys built into the Google Web App interfaces may have unexpected consequences for users. When a keystroke does not result in the desired action it may be because of the state of the virtual view, or browse mode, of the given screen reader. without a solid understanding of these differences it would be difficult to troubleshoot problems, and make using Google Web Apps a less than stellar experience, and it doesn't have to be. Armed with this knowledge/understanding go forth and explore.
