[Accessibility] minutes: Open A11y Weekly Telecon 2010-09-07 [draft]

Gregory J. Rosmaita oedipus at hicom.net
Wed Sep 8 08:03:50 PDT 2010


minutes from the 7 September 2010 Open Accessibility Workgroup 
teleconference can be accessed as hypertext at:


and as plain text following my signature -- as usual, please log
any errors, corrections, misattributions, clarifications, and the
like by replying-to this announcement on-list...

note that the bulk of the 7 September 2010 meeting was dedicated to 
discussion of the ISO documentation on AT-SPI -- in particular, 
section 3.x -- the hypertext version of the minutes includes the graphics
discussed during the 2010-09-07 telecon for ease of reference

please note that janina plans to review a section of the document per
week (starting on 14 September 2010 with section 4 -- 
http://rednote.net/iso.html#x1-370004) -- and continuing with 1 
section per week through review of section 9

in advance of the 14 September 2010 meeting, i have populated the
minutes template for that meeting to contain the text to be 
discussed in blockquotes, thereby making it easier for Open A11y
members to review the material being discussed in context -- the
URL for the 14 September 2010 meeting can be found at:


a preliminary agenda for the 14 September 2010 meeting can be found




Open A11y Working Group Conference Call (7 September 2010)

Preliminary Items


    * Janina Sajka (JS/chair)
         + Pete Brunet(PB)
         + Joanmarie Diggs (JD)
         + Mike Gorse (MG)
         + Chris Hofstadter (CH)
         + Gregory J. Rosmaita (GJR/scribe)
         + Jeremy Whiting (JW)
              o regrets: Brian Cragun

For Reference

* Agenda for 7 September 2010 Open A11y Call

Approval of Past Minutes

* Minutes from 10 August 2010 Open A11y Call

* Minutes from 3 August 2010 Open A11y Call

* Minutes from 27 July 2010 Open A11y Call

* Minutes from 20 July 2010 Open A11y Call


Meeting Minutes

Topic 1: Documenting the AT-SPI Environment for ISO

    * Draft Information Technology User interfaces Interoperability with
      assistive technology Part 4: Linux / UNIX graphical environments
      accessibility API [http://rednote.net/iso.html]

  JS: plan to review a section a week at Open Accessibility meetings for
  sections 4 through 9 discussing one topic per week

  JS: frontmatter pro forma; bibliography; glossary will contain
  definitions of terms only if in prose of document; have to see if ISO
  has official definition of Linux or Unix (what is difference between
  the 2 according to ISO)

  JS: would like to start today by reviewing Section 3.2 "Architecture"

    The GNOME Accessibility Architecture provided on most Linux and
    Unix graphical desktops--the only accessibility architecture
    available for Linux and Unix graphical desktops--distinguishes
    between AT-SPI aware applications, assistive technologies and an
    accessibility broker.

    Communications between applications and assistive technologies (AT)
    is achieved using AT-SPI, which facilitates communications with
    AT-SPI aware applications on the one hand, and with AT on the

  PB: comment: are applications aware of AT-SPI? thought were aware of
  ATK or GTK

  JS: true

  MG: bunch of layers --

  JS: application not aware of AT-SPI specifically

  MG: a screen reader is, but a "mainstream" app generally isn't --
  theoretically it could, but layers over ATK often done by toolkit
  rather than application itself

  JS: ATK-aware

  PB: accessibility just below the layer?

  JS: will check with other documents on this

  PB: focus above the layer -- i think ATK when i think architecture,
  but might want to expand on other aspects of other layers -- such as
  TrollTech did

    AT-SPI aware applications are applications that offer information
    about their user interface via the AT-SPI protocol. This can be
    achieved in several ways: GNOME applications get AT-SPI support for
    free: The GTK+ toolkit they are based on optionally loads GAIL,
    which bridges between the GNOME widgets and ATK. A second library
    is used in order to bridge between ATK and AT-SPI. Mozilla does not
    use GTK+ but implements the ATK api directly within the
    application. Java applications may use the Java Accessibility
    Framework which directly bridges to AT-SPI. In the context of
    AT-SPI applications are often called servers.

  PB: missing something here about TrollTech architecture

  JW: yes, but not complete -- mention?

  JS: if architectural direction set, ok to mention

  JW: agree

  JS: can you email me a sentence or 2 to strengthen?

  JD: open access functions -- what is up-and-coming; don't know if want
  to mention everything

  JS: uno is mentioned elsewhere, but can import to this section --
  currently or about to be supported

  MG: reword comment for Java -- JavaAccessBridge works that way but
  being replaced by the JTK wrapper

  JS: add uno and add JTK

  JS: JD, please provide info about WebKit

  PB: atk to java

  MG: java ATK wrapper http://git.gnome.org/browse/java-atk-wrapper/

    In order for an application to be accessible on the Linux/Unix
    graphical Desktop, it needs to provide information about its user
    interface using ATK. If the application is written using GNOME's
    GTK+, all of the standard widgets provide the needed information to
    ATK and therefore the application will by default be accessible.
    For applications that do not use GTK+ for their user interface,
    additional work needs to be done to make them accessible.

  JW: does every other toolkit go through ATK to get to AT-SPI

  MG: yes, except for QTspi

  JS: will note that QT will be exception;

  MG: GTK apps being accessible is only true insofar as custom widgets
  aren't used; if custom widgets used may have to implement classes

  JS: will add note about custom widgets requirements; trying to avoid
  mentioning specific apps, save on AT side

    Assistive technologies are applications that are interested in
    requesting information about the user interfaces of AT-SPI aware
    applications. A screen reader (like GNOME's Orca) needs to know
    what to speak, braille, or magnify. An on-screen keyboard (like
    GNOME's Caribou) needs to send keyboard and mouse events to the
    application. In the context of AT-SPI, assistive technologies are
    often called clients because they consume and interact with
    application UI information.

  JW: another place where need to change AT-SPI aware to ATK-aware

  JS: yes

    The accessibility broker is a daemon that coordinates communication
    between AT-SPI aware applications and assistive technologies. Each
    AT-SPI aware application registers with the broker in order to
    offer its information. Assistive technologies may add event
    listeners to the broker, so that they get informed when
    accessibility related information in any application changes.

  JW: another place where need to change AT-SPI aware to ATK-aware

  JS: yes

Discussion of Illustrations and Their Descriptors

    * Figure 1: The GNOME Accessibility Architecture

    * Figure 2: Any toolkit can implement accessibility support. This
      figure illustrates the GNOME architecture as currently supported
      by Java/Swing, GTK+, UNO, and XUL. (atspi.png)

    * How GAD works:

    * D-Bus image:

    * CORBA image: 

  JS: image questions: think they are similar, but one simplified, one
  detailed so can find connections -- one from Gunnar Schmidt of KDE

  PB: not the same

  JS: think useful to have simple and then more detailed view

  PB: does this actually add anything?

  JW: i've seen a good illustration on gnome site -- has Java and
  OpenOffice and GTK; no legend for colors

  PB: PNG seems to be sub-set of JPG file

  JW: JPG file over-complex

  JW: image from
  w-it-works.html.en seems clearer

  JS: more inclined to include more graphics and then have group remove

  PB: [compares graphics] - any using ASR?

  PB: voice control path

  JS: discussion on what to do to create that on gnu-accessibility list,
  but don;t know of an app using this architecture

  JW: bonobo deprecation page images better diagrams -- reviewed these
  with WillWalker

  PB: what is JAW? Java Access Bridge for Windows?

  JW: yes

  JW: note CORBA based image and D-Bus based image

  PB: like more detailed

  JS: inclined to use both -- a simple one and a more detailed one that
  shows how toolkits interface; want to show the center/middle of the

  CH: hourglass is a wonderful metaphor

  PB: funnel of stuff above and funnel of stuff below

  PB: AT-SPI and ORB -- is ORB gone?

  JS: should not have ORB -- since bonobo deprecated and moving to d-bus

  JS: AT-SPI jpg is almost good enough -- needs to have ORB removed

  JS: D-BUS jpg is preferred by group?

  PB: like the most detailed one, GAPArchitecture3.jpg

  GNOME Accessibility Architecture

  PB: question marks for OpenOffice stream

  JW: uno access glue

  PB: firefox section -- is it accurate

  JD: thought is nsI

  JD: personally think GAPArchitecture3.jpg is too complicated

  JS: 2 graphics, then, would make a lot of sense

  JW: contrast issues with GAPArchitecture3.jpg -- colors chose
  difficult for anyone with less than perfect vision -- light purples
  light green light pink

  JW: red squiggly lines from spell checker need to be removed

  JD: switched to UIbuilder

  PB: changes in tools layer needed

  JS: set graphics aside; could Pete and Jeremy collaborate on improving

Topic 2: Bringing QT and KDE Expertise to Open Accessibility

  JW: there is a QT AT-SPI Bridge -- QAccessible -- every QT app has
  through AT-SPI interface; worked november 2009 before changed
  drastically; trying to get to work again; effort to get students in
  Toronto moving on this along with mentors on KDE site;

  JW: as far as QAccessible itself goes, have been told works well on
  windows and mac (with carbon)

  JW: bridge between 2 need some help from MG on testing; application
  testing tool or use acceciser? acceciser gives alot of errors if
  running QCalculator

  MG: could be 1 approach; to work with Orca, first test with acceciser
  -- if you email me, i will try and help as i can

  JW: getting same errors with QT calculator

  MG: acceciser gives you tracebacks

  JW: running acceciser

  JW: how to test on application side would help me understand what i am

  MG: don't know offhand if good documentation on that -- will have to
  check documentation work previously done

  JD: i can use acceciser in my sleep, so if want assistance, let me

  CH: group in India would be able to write code if coached correctly

  JS: good technical documentation invaluable; if can find people to
  mentor (JD, for example) while these people get going

  GJR: points PB to GNOME's Accerciser Tutorials

  JS: in terms of acceciser -- is more weighted for testing AT apps, or
  equally useful for the non-AT layer (skinny part of hourglass)

  MG: it exposes information correctly and monitor events -- if using
  Orca, use acceciser to find out what AT is exposing

  JS: so this is the skinny part of the hourglass?

  JD: don't use to access information, but another app like orca in that
  is consumer of AT-SPI

  JS: have wanted to ingetrate KDE and QT into our work for years;

  CH: GNU resources might be available

Wrap Up

Identify Dates and Topics for September 2010 Meetings

  JS: next week review section 4 of ISO document

    * meeting adjourned 1602h UTC
    * next Open A11y conference call: 2010-09-14

Retrieved from
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility/attachments/20100908/7f261375/attachment-0001.htm 

More information about the Accessibility mailing list