Open Radar

 
26-Oct-2009 07:57 PM Emanuele Vulcano:
VoiceOver on Mac OS X has the ability to present controls "grouped" into "containers" as a single entity. On Mac OS X, the user has to "start interacting" with a container in order to use the controls contained therein. This allows the control lists to be kept brief and the user to be quickly brought up-to-speed on the contents of the screen.

On VoiceOver for iPhone OS, this capability is missing. Therefore:
• The user loses context. For example, navigation bars with a back item are presented as "*previous screen name*, button" followed by "*current screen name*, button". Nowhere the non-sighted user is informed that he's interacting with a structured control (a navigation bar). This prevents the user from easily understanding common control structures and forming a mental map for navigation.
• The "Speak all from this point" and "Speak all from the beginning" commands (two finger swipe down or up, resp.) present ridiculous amounts of controls in some situations. Notably, the keyboard is never announced as "keyboard" anywhere, but instead key-by-key by both commands ("Q", "W", "E", "R", "T"...). The user is often forced to deduce that a keyboard came up and stop the key-by-key litany with the "Stop" command (two-finger tap).

Adding this capability in some form would solve both these problems. A proposal for addition would be as follows:

• When quickly moving the finger on the screen so as to have VoiceOver read its contents, VoiceOver announces containers and not contents where this makes sense. For example, if the user moves a finger onscreen on a screen with a navigation bar, the VO voice announces "Navigation bar with two buttons" rather than its components, possibly with the hint "Hold your finger here to use" or similar.
• When the user pauses the finger over a composite control while reading its contents, it "starts interacting" with it.
• "Select next" and "Select previous" (flick right and left resp.) commands only present containers rather than their content until the user starts interacting with the control. For example, flicking right after the last control has been reached just before 
the keyboard will announce "Keyboard" rather than "Q". Double tapping lets the user "start interacting" normally with the controls in the container.

While interacting with a control, the user can use the "Select next" and "previous" commands to use the components of that control as usual until the user stops interacting.

A good way to have the user stop interacting would be contextual (eg the user moves the VoiceOver cursor away from the container and a certain timer elapses, or the user starts interacting with another container). It might also be advantageous to present this hierarchy of containers in a limited fashion, for example by only presenting the "innermost" container of the hierarchy, so as not to require multiple "start interaction" commands.


26-Oct-2009 08:09 PM Emanuele Vulcano:
Some controls, such as search fields, already present a similar behavior in iPhone OS by constraining the list of controls the user can interact with using the "Select next" and "Select previous" commands; in the search fields' case, the two command move between the clear button and the actual text field in an endless loop, thus having the search field act as some sort of container for both. The user can escape this loop by scanning the screen using the finger. This is similar to the proposed "start"/"end interacting" commands above.