Re: Orca a couple questions

[Willie Walker <William Walker Sun COM>]

Hi:

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,

Will

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
>   (614)-[24]7-6925
> ----- 
>
> _______________________________________________
> Orca-list mailing list
> Orca-list gnome org
> http://mail.gnome.org/mailman/listinfo/orca-list