Re: A few outstanding issues with ATK API

[Peter Korn <peter korn sun com>]

Hi Bill,

> There are a few issues, some along the lines of "do we really need
> this", that Owen raised to do with ATK.
> 
> (1)
> 
> atk_editable_text_set_attributes(AtkText *text,
>                                  gint start,
>                                  gint end,
>                                  PangoAttrList *attributes);
> 
> OK, Java AccessibleText has this feature.  We know PangoAttrList is
> not supported by all the widgets that implement AtkEditableTextIface,
> so there would have to be some transcoding/adapting of attributes.
> That's messy but feasible.
> 
> Not every editable text widget supports attributes at this time.  No
> problem, if attributes are not supported there is no case for setting
> them ;-)
> 
> Pango attributes are maybe the wrong choice.  GtkTextBuffer seems to
> use things called TextTags, if I understand it correctly.
> 
> My gut feeling is that this will be implementable on GtkTextView (via
> the GtkTextBuffer) but Owen asked (in effect) the question "shouldn't
> this be done via the application UI?".
> 
> So:  how do ATs use this feature in Java today (if they do), or
> how/when do they use similar functionality in other environments?

I don't believe any AT for the Java platform is using this yet.  The main
argument for this functionality is for voice control & dictation (and other
non-traditional input devices; for example a sophisticated Braille terminal with
keyboard entry via a chording Braille display).  The problem of forcing folks to
do this through the application is that each app potentially does it
differently, and that makes voice control/Braille/etc. much more cumbersome. 
Since in many cases it's the same widget/few widgets, it'd be nice if the
programatic interface to them were the same.  This also has benefits for
scripting interfaces, etc.

> (2)
> 
> AtkImage question...
> 
> There is at the moment a atk_imate_get_storage_type(...) method.  At
> the moment it seems to indicate the internal storage type (GtkObject
> type) of the image data.  I am not sure that is important... however I
> can see a use for "image format" info here, for instance in an
> AtkObject container that has HTML content in it, an image in the page
> would have an AtkImage implementor that had actions on it (save image,
> etc., right?) and a user might want to have content-type information
> about that image.  If the user agent doesn't expose this in an
> accessible way via UI elements, then it would be good to provide this
> info for AtkImage instances.  Just a thought.  Otherwise it's not
> clear to me that this method is needed.
> 
> I think the overall issue of how AtkImage would work in a web browser
> is worth thinking about a little.

Interesting points.  Since in many cases images typically come from *somewhere*
(files, URLs, etc.), it's a valid question whether that information should be
exposed.

> (4)
> 
> Should we move get_caret_offset from AtkText to AtkEditableText?  In
> other words, will we ever want immutable text objects with carets?
> (of course not insertion carets :-)

Potentially yes.  This has more to do with how screen readers are traditionally
implemented, and their typical user-interface.  But I think that the benefits of
user-consistency make make this worthwhile.

Today blind users typically interact with text a line at a time.  While it
perhaps make more sense to interact a word, sentence, and paragraph at a time
instead, we'll certainly have a lot of users who are used to doing it the old
way (where you had to move the cursor to review), and those users will expect to
have their screen readers read to them a line at a time as the down/up arrow
through text (and a word at a time with CTRL-left/right arrow, etc.).  If
read-only text still maintains a caret internally (which may never be
displayed), and that caret gets updated with arrow movement (and PgUp, PgDn,
etc.), then text navigation will be simple and consistent for screen reader
users, whether that text is editable or not.

By the way, this happens to work today in Java with the Swing JTextComponent. 
When the read-only flag is set, keyboard/caret response still works, caret
events are fired, and screen readers get and read the text, in
letter/word/line/etc. increments.  From what I've seen, blind screen reader
users of Java applications really like this behavior.  Mind you, their screen
reader doesn't support word/sentence/paragraph increments, so they/we don't have
anything to compare it to...

Cheers,

Peter Korn
Sun Accessibility team