Re: Accessible Terminal

Marc Mulcahy wrote:
> Hi all,
> An initial stab at the libzvt accessibility support is done 

Great news!

> with the
> following rather important issues outstanding:
> 1. There is no role for the Accessible terminal.  How about adding

Sounds right.
> 2. There is no efficient way to implement getRunAttributes in the
> terminal.  Unless there are objections, I'll just implement runs of one
> character a piece as per Java accessibility.

Ah, since we're not doing this elsewhere in GTK+ I would prefer if we
could maintain internal consistency within GTK.  If we can do
1-character runs, we should be able to build a wrapper that concatenates
them while the attributes remain invariant.  I know, it might not be
efficient, but we can check the timing later.
> 3. The ZvtTerm widget doesn't emit a signal when the selection
> changes.  Should it, and if so, I assume the signal handler in
> ZvtAccessible would emit the "selection" property change.

I don't see how we can implement AtkText with selection changes (as per
AtkText spec) without this.
> 4. The ZvtTerm widget emits a signal for text added, but as far as I can
> tell, the signal doesn't contain information about where the text was
> written to the screen.  Is it acceptable to emit a "text changed" signal
> and leave it up to the AT to figure out the details of the change?

Probably not, since if we listen to "detail" text change signals we will
miss this generic signal.
> 5. Screen readers which read text from terminals often need to do the
> following task which isn't very well suppported, if at all, by AtkText:
>         a. New text is received and prepared to be written to the screen.
>         b. The screen reader examines the proposed location of the new text, and
> grabs the text
>                 currently in that location on the screen.
>         c. If the text is the same but the attributes show it is switching from
> highlighted to normal,
>                 nothing is spoken.
>         d. Otherwise, the text is spoken.
> How can we do this with AtkText?

One way is for the AT to maintain a local mirror of the buffer when role
is ATK_ROLE_TERMINAL.  I expect most AT will want a local cache of the
terminal buffer anyhow... thus it will be easy to check changes to see
if they are attribute-only.

Possibly a better solution, though one that involved more work, is to
have the GAIL implementation catch these sorts of changes and expose
them as attribute change events rather than text change events... not
sure we have a signal for that yet or not, but we could put the
start/end run over which attributes are modified into the "detail"
fields of the attributes-changed signal.

> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org

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