[Accessibility] Two more AT-SPI discussion points

Peter Korn Peter.Korn at Sun.COM
Wed Jun 1 23:40:50 PDT 2005

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


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".
> regards
> - Bill
> Olaf Schmidt wrote:
> >Hi!
> >
> >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
> >AT-SPI.
> >
> >Olaf
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Accessibility mailing list
> >Accessibility at mail.freestandards.org
> >http://mail.freestandards.org/mailman/listinfo/accessibility
> >
> >
> _______________________________________________
> Accessibility mailing list
> Accessibility at mail.freestandards.org
> http://mail.freestandards.org/mailman/listinfo/accessibility

NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.

More information about the Accessibility mailing list