[Accessibility] Two more AT-SPI discussion points

Bill Haneman Bill.Haneman at Sun.COM
Wed Jun 1 10:56:28 PDT 2005

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

More information about the Accessibility mailing list