Re: Orca a couple questions


There's an infrastructure for Linux known as the assistive technology service provider interface (AT-SPI). It provides support so external agents (i.e., assistive technologies) can connect to GUI applications and interact with the GUI hierarchy of the application. Also included is the ability to intercept (and possibly consume) input device events.

Screen readers such as Orca use the AT-SPI to gather and observe information about the desktop and applications, and then make policy decisions about what/how/when to present information.

Hope this helps,


S James S Stapleton wrote:
I'm still looking at it, and I had read things a few weeks ago, that suggested orca might be beta quality still, however I want to get some more information (and make a suggestion if it's not already been implemented/made), partially because I know my mom needs a screen reader (she's blind and stuck with Windows/JAWS, that latter of which is really $2000 pre-alpha software in my experience), and some day I may need a screen reader myself... Darn genetics, and I'd rather have my BSD system available to me.

So, without further adieu, I'll make my suggestion:
Is there an open network-reader protocol that is being made or has already been made, designed to take some of the development hassle off of the screen reader developers and provide a simple mechanism for software developers?

This protocol would include:
(1) A Berkley server port to initially connect to or a way to find the port to connect to (the latter would be a search path in both windows and *nix systems). The server port would then spawn a normal port for actuall connetion, allowing it to handle multiple connections and hence multiple UI interfaces at once. (2) A communication protocol to help support both text signaling _and_ emphasis/inflection. XML or HTML would be good for this, and due to it's flexibility, I'd probably say XML. At minimum size, emphasis/italics, underline, and bold/strong should be recognized by the server (and it may choose to handle them or ignore them as it's programmers or developers determine adequate).

The server requirements would include:
(1) All required formatting must be accepted by the server, and either handled in a regular manner. This manner can be a specified alteration in tone/volume/speed/etc relative to normal, or to ignore the formatting and speak as normal. It may not include replacing it with silence. (2) Ignore all unknown tags, and treat their enclosed contents as unformatted. (3) [Optional] A basic HTML reading functionality wouldn't be a bad idea here (4) The user must be able to tell the server it cannot speak to anyone but localhost. The server is not required to be able tos peak to non-localhost systems. Default should be to not speak to non-localhost systems. (5) The server should handle a set of UI element tags, for which the user can specify how the server will treat the tag when it sees it (including: altering the voice inside the tag, stating custom text as the tag is opened and closed, and using unique tag identifiers in the custom text, if provided.)

The client requirements would include:
(1) Required customizable hotkeys for the following:
-- Reread window title or console title
-- Reread current printed screen
-- Reread current UI element (or prompt and currently enntered command line)
-- Reread prompt only (UIs may interperet this how they wish)
-- Reread current entered text (i.e. command line in console, text fields in UI)
-- Read word of cursor (if applicable)
-- Read line of cursor (if applicable)
-- Read paragraph/section of cursor (if applicable)
-- If in menu, state if menu is horizontle, vertical, or grid
-- State type of currently selected UI element
-- Close application - default is [alt]+[f4] or [shift]+[esc]
-- Shift keyboard focus to next next menu element out
-- Open/close current menu
-- activate (effectively left click) - default is [space] or [enter]
-- move to next focusable element/last focusable element - default is [tab]/[shift]+[tab] (2) If any predefined commands override the existing commands, the application should determien this and warn the user if possible, allowing him or her to select which has precidence.
(3) Turn on listing a UI element before and/or after reading the contents.
-- The user should always be able to alter inflection of the UI element's contents and/or callout -- [Optional] a UI element tag can surround it's contents in the communication stream, allowing the server to handle this (more standardized output between UIs, less work for the dev)

Finally, as a group, determine standard/substandards for the protocols and requirements for keybindings. For example, a full implementation of the above might qualify as "orcanet basic" compliant, but with the addendum of row, column, and cell related keybindings and speach requests, it might also be "orcanet basic" and "orcanet spreadsheet" compliant.

Thank you,
-Jim Stapleton

  S James S Stapleton
  Office of Information Technology
  The Ohio State University
  Room 315 KRC, 1121 Kinnear Road
Orca-list mailing list
Orca-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]