[Accessibility] Two more AT-SPI discussion points

Bill Haneman Bill.Haneman at Sun.COM
Thu Jun 2 01:56:54 PDT 2005

Peter Korn wrote:

>Hi Bill,
>I think locale is reasonably applied to every at-spi object.  It is
>already in AccessibleContext in the Java Accessibility API, which is
Yes, but Java itself has the notion of per-object locale, which our 
native toolkits do not.  There simply is no such thing as a per-widget 
locale in gtk+ or, as far as I know, Qt.

I also don't think this is a win from a cost/benefit viewpoint, as I 
pointed out below.


>Peter Korn
>Sun Accessibility team
>Bill Haneman wrote:
>>Hi Olaf:
>>Language information does accompany textual information from at-spi, in
>>the form of text attribution, at least where it differs from the host
>>application's locale.  AccessibleApplication now has a getLocale method
>>which can be used to get the locale of the host application.   In almost
>>all cases (see below), I think this is the most effective solution.
>>At present, I don't know of any applications where textual information
>>(labels, names, description, etc.) from widgets that aren't explicitly
>>'Text' widgets doesn't match the application's locale, unless there are
>>missing translations.  Without better support in our
>>internationalization framework itself, it may not be possible to
>>identify these cases reliably; that is, we may not be able to tag text
>>as "en_US" or "C" in cases where there is a missing translation.
>>I think the cases we know about where multi-locale text occurs by
>>design, as opposed to by accident, are 'content' cases.  In this case, I
>>believe that the AccessibleText interface will be implemented, and
>>therefore lang/locale will be text attributes.
>>For some kinds of content this could get interesting - for instance if a
>>user views a German web page from a user agent in the en_GB locale, and
>>the alt-text for images is only available in German, what do we do
>>then?  It may be that in these cases, we need a 'locale' attribute for
>>the name/description/image-description properties.  I am not sure
>>whether that is reason enough to add this to all AccessibleObjects or
>>not - the current model has the advantage that the assistive technology
>>does not need to interrogate each object for its locale before
>>presenting name or description, so adding this could have disadvantages
>>as well.  A reasonable compromise might be to add this information only
>>for AccessibleImage, which seems to be the primary use case where a
>>"non-textual" content element needs to expose a 'lang' or 'locale'.
>>Your second question is interesting; at-spi allows for the 'actual'
>>document to be obtained from the StreamableContent interface, in theory,
>>possibly in more than one mime-type.  However, because the semantics of
>>"document" versus "user agent" are actually not clearly defined
>>anywhere, we didn't define such an interface.  In practice, users (both
>>sighted and blind, users of assistive technology and otherwise) must
>>learn from experience what is "document view" and what is "interface".
>>It's relatively easy to figure this out when viewing a static web page,
>>but since many documents now include interactive elements, forms, or
>>even "fake" popup windows (think about web advertisements!), the
>>distinction can get unclear.  One approach to solving this issue is to
>>either make the user agent responsible for figuring this out (as in
>>self-voicing applications, which is similar I think to what you are
>>doing with Konqueror), another is to provide application-specific "read
>>everything" scripts in the assistive technoloty (which is the way orca
>>handles this).  This may be a use case where an AccessibleDocument
>>interface, or at least some kind of tag or attribute on a container
>>object, could be useful, in order for a user agent to tell the assistive
>>technology "the content view subtree starts here".
>>- Bill
>>Olaf Schmidt wrote:
>>>After Cathy's lists seems to have been completely discussed last week,
>>>I have two other discussion points about AT-SPI. Both are related to ktts,
>>>the speech synthesis framework we have in KDE.
>>>ktts can automatically select a correct voice for a given language when
>>>reading out a text, so it is important to know which language a text is
>>>in. This information is provided by Qt4 Accessibility framework. If I
>>>recall correctly, then there are some cases where it is impossible to
>>>forward this information to the assisistive technologies when using
>>>AT-SPI. We already discussed this at the Unix Accessibility Forum which
>>>we hosted during the KDE Conference last summer. Peter and Bill said that
>>>AT-SPI could be extended to include language information everywhere. Has
>>>this been done in the meantime?
>>>My second question is whether AT-SPI allows to get the complete document
>>>from an application, and only the document (without other user interface
>>>elements). I ask this because ktts allows the user to navigate through
>>>longer text that is being read out, using different voices for headings,
>>>links, etc. We have integrated this with our web browser, editor and PDF
>>>reader. Note that ktts is not meant as a screen reader or as some other
>>>assistive technology for accessibng another application. It is a separate
>>>application useful for partially sighted people and offers its own user
>>>interface. Nevertheless, it would be great if it could benefit from
>>>Accessibility mailing list
>>>Accessibility at mail.freestandards.org
>>Accessibility mailing list
>>Accessibility at mail.freestandards.org

More information about the Accessibility mailing list