- Availability at All Times
- Failure Resiliency
- Seamless Interaction with Traditional Keyboard Navigation Methods
- Seamless Interaction with Other Assistive Technologies
- Consistent Style
- Customizable Behavior Per Application ("Scripting")
- Support for Script Writers
- Customizable Gestures
- Acceptable Response Time
- Configurable Presentation and Interaction
- Ability of Non-focused Windows to Present Information
- Documentation and Tutorials
Based upon discussions with end users as well as the tasks and ideas from the personas. Orca must supply at least the following end-user features:
Availability at All Times
Orca will often be the only vehicle by which many users will be able to access the system. As such, it must be available at all times, including at system login, screen-saver screens and system administration screens requiring root access.
Orca must also be available after the system returns from "standby" or "sleep" mode. Finally, in the event the user's choice of speech synthesis engine becomes unavailable (e.g., expired license), Orca must attempt to find and use an alternative synthesis engine.
In the event that Orca fails or a component of the system that Orca depends upon fails, the system should be able to heal (and perhaps restart) itself appropriately.
Seamless Interaction with Traditional Keyboard Navigation Methods
Orca must allow users to navigate through the desktop and applications on the desktop using the system keyboard navigation gestures (e.g., Alt+Tab to select the next window). In other words, Orca must not interfere with traditional keyboard navigation.
Seamless Interaction with Other Assistive Technologies
It is not uncommon for users to simultaneously use other assistive technologies, such as the AccessX features of XKB, to access their displays. As such, Orca must be able to co-exist (i.e., not interfere) with other assistive technologies in use by the user.
It is expected that access to applications will be driven primarily via customized "scripts," with a fallback ("default") script to be used in the absence of a customized script. While each script can provide dramatically different access to an application, it is expected that scripts will provide users with a consistent style to access applications. To help with this consistent style, Orca will provide a style guide, a well-documented "default" script, and several application scripts that demonstrate and promote this style.
Customizable Behavior Per Application ("Scripting")
It is expected that the default behavior will provide reasonable access to all applications that use the AT-SPI. However, to provide dramatically improved access, Orca must be able to provide customized behavior for individual applications.
For example, one can envision a script for an e-mail application that can provide prioritized access to one's inbox. Another example may be that the script provides keyboard access to select and copy displayed text to the system clipboard in the event the application doesn't support this (e.g., the only way to select text in a terminal window is to use a mouse - a script might create new keybindings to allow a user to do this from the keyboard).
Support for Script Writers
Orca will provide tools and utilities to help the script writer. These utilities not only include a library of useful methods to use from scripts, but also runtime tools to help the script writer analyze the system in action.
While Orca will provide a default set of well known keyboard gestures and braille gestures, users must be able to override these gestures and extend them with gestures of their own choosing.
The user interface for defining these gestures must be easy to use.
Acceptable Response Time
Orca must not degrade the perceptible performance of the system. That is, user should be able to detect any decrease is responsiveness of the desktop when the Orca is being used. In addition, a user's interaction with Orca should appear as crisp and as lively as normal interaction with the display via traditional interfaces (e.g., the keyboard).
Acceptable performance of the speech synthesis output is very important. Orca must be able to provide speech synthesis that meets or exceeds the following performance metrics:
Time to First Sound - The time between when a speech synthesizer gets a request to speak and when the synthesizer actually starts speaking must be minimal (e.g., less than 30ms).
Time to Cancel - Orca must be able to cancel speech synthesis in progress, and the time to cancel must be minimal (e.g., less than 30ms). Furthermore, the time between when a cancel is issued and the time the next utterance is to be spoken must be minimal (e.g., less than 30ms).
All updates to the braille display should occur within 50ms of the time the update command was issued.
The magnifier should offer smooth performance and show no visible lag.
Performance Scope It is understandable that much of the response time may be due to factors outside the control of Orca (e.g., Bonobo and the underlying speech engine). As such, the primary responsibility of Orca and each application script is to process AT-SPI and keyboard events as quickly as possible.
Configurable Presentation and Interaction
Different users have different capabilities (e.g., some may be able to hear some synthesis voices better than others; some may use braille while others do not) and desires (e.g., some may prefer faster speaking rates). As such, the general manner and means by which Orca presents information to the user must be configurable by the end user. Users must also be able to change configuration settings while Orca is running, including the ability to turn presentation modes (i.e., speech, braille, magnification) on or off without the need to restart Orca.
Ability of Non-focused Windows to Present Information
Orca must allow for the presentation of information of objects that do not have keyboard focus. While the presentation will typically be information on objects that the user has requested interest in, it may also come from custom scripts that have decided it is important for them to present something. Examples of such information include announcing the status of a progress bar, announcing the subject/sender of incoming e-mail, etc
Documentation and Tutorials
Although it is a reasonable goal that Orca should attempt to achieve, users cannot be expected to be able set up and use Orca without documentation. Like other systems, such as JAWS, Orca must provide documentation and tutorials on the installation, configuration and use of Orca. This documentation must come in form(s) that are accessible to people who need to use the screen reader (e.g., accessible text and audio).