Orca a couple questions

["S James S Stapleton" <stapleton 41 osu edu>]

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
-----