Re: [g-a-devel] AccessibleTerminal Interface ?

[Peter Korn <Peter Korn Sun COM>]

Hi Samuel,


> For now, Terminal widgets use the AccessibleText Interface to provide
> their content. However line breaks make things hard, both in the
> widget's code and the screen reader. I both wrote Brltty's atspi screen
> driver and had a look how libvte provide the AccessibleText interface;
> and what I wrote and read seemed quite uselessly tricky to my mind.
>
> And it will be as much tricky for every xterm-like program. I had a
> look at a lot of them, they usually consider a terminal as an matrix of
> char, or as an array of variable-length lines of chars (so as to cope
> with double-width caracters for instance). BTW, I am not aware of any
> tty that would be capable to split and join lines (see man 5 termcap).
>
> So I guess things would be a *lot* simpler for everybody with a
> line-oriented AccessibleTerminal interface. The interface could even be
> as simple as something like:
>
> long AccessibleTerminal_getLineCount(AccessibleTerminal *obj);
> long AccessibleTerminal_getCaretLine(AccessibleTerminal *obj);
> AccessibleText *AccessibleTerminal_getLineText(AccessibleTerminal *obj, long int line);
> SPIBoolean AccessibleTerminal_addSelection(AccessibleTerminal *obj, long int startLine, long int startOffset, long int endLine, long int endOffset);
>
> and remaining selection and extents functions, and add-line,
> remove-line, caret-moved and selection-changed events.
>
> Maybe this could be discussed on irc some time?

Thanks for suggesting this - ancillary interfaces like this are explicitly how 
we imagined growing the accessibility architecture.

At first blush, I'm not entirely convinced we need AccessibleTerminal.  My 
biases against it are:

 1. Unlike things like hypertext/HTML, the terminal is not something you tend
    to see embedded in other things and used throughout the desktop.  It is,
    of course, a critical application that must be accessible, and so there
    may be enough of an arguement to have a specialized interface for it.

 2. Without a *lot* of work, a GUI/API-based screen reader like Gnopernicus
    will never be as powerful for the console/terminal as something like
    BrlTTY.  We've seen this in the Windows world, where JAWS for Windows
    (for example) isn't as powerful as JAWS for DOS when interacting with
    DOS apps.

 3. At least today, we don't have significant issues/challenges with GOK
    or any other (read "none") AT using the terminal - only Gnopernicus, where
    we have a very powerful alternative in, among others, BrlTTY.

So given these points, my initial inclination would be to focus energies on 
other fires rather than AccessibleTerminal.

But... I'm keen to have at least the initial conversation!  I'm very prepared 
to be demonstrated wrong!

> BTW, having only insert and remove events is most often _not_ efficient
> for terminals: having a replace event would be much useful to avoid
> spurious refresh.

This seems like a good API addition to consider for AccessibleText, or at 
least AccessibleEditableText.  Especially in the terminal case, and also 
gnome-calculator.


Regards,

Peter Korn
Sun Accessibility team