[Accessibility] Conference transcripts for Tuesday and Wed. AM

Doug Beattie dbb at beatties.us
Wed Feb 16 09:43:43 PST 2005


In ascii format for those that don't read word.doc files.

On Wed, Feb 16, 2005 at 09:29:51AM -0800, john goldthwaite wrote:
>  
>  This is a rough transcript of the Tuesday and
> Wednesday morning sessions of the conference.  
> 
> 
> 		

Honolulu Accessibility Conference Wednesday, January 26, 2005  - morning session

Bill Haneman
Will Walker - speech, Sun
Mark Mulcahy - gnome speech, pda for blind
George Kraft - IBM
Gunnar Schmidt - KDE Access
Olaf Schmidt - KDE Access
Hararld Fernengel- Trolltech
Peter Korn
Marco Gambra - Suse, screen reader
Ed Price 
John Goldthwaite
Doug Beatty
Saban Tibo - braill
Sebastian  Hinderer
Sebastian Thibault
Jonathan Blanford, red hat
Al Gilman, W3C WAI
Larry Weiss, IBM accessibility
Hynek Hanke  Braillecom
Tomas Cerha	
Milan Zamazal
Jan Buchal Braillecom
Frank 
Stewart

Kirk Reiser, Toronto
? , Australia 

http://accessibility.freestandards.org/a11yweb/presentations/haneman-20050125-atspi/AccessibleDesktop.html

Bill Haneman - AT/SPI  

Overview of an Accessible Desktop

    *
      Applications:
          o Meet functional criteria
          o Export/expose information programmatically
          o Give notifications
          o Allow programmatic interaction 
    *
      Desktop:
          o Provides location and registration services for a11y
          o Provides access to device events and platform I/O
          o Provides communication infrastructure 
    *
      Assistive Technologies:
          o Mediate and adapt the user experience
                + Mediate -> must be listening
                + Adapt -> must proactively manipulate interfaces

Applications have responsibilities
Desktop provides services
AT provide functions
Applications have to export information programmatically

Long-term goal

    *
      All applications on the desktop are accessible
    *
      Requires:
          o Apps must all meet functional criteria
          o Apps must all export a functionally consistent a11y ABI
          o AT must have all the platform services/access that it needs
                + e.g. Keyboard snooping, display hooks, input devices 
          o Must be possible to write an AT to a known interface (SPI)
          o Awareness and testing!

The Role of AT-SPI

    *
      AT-SPI provides:
          o Service model
          o Device event requests and notification
          o Application event notifications
          o Programmatic access to application user interfaces
          o Simplifies or eliminates AT-maintained off screen model 
    *
      AT-SPI gives AT a uniform interface within a highly heterogeneous desktop
          o Makes it possible to write one AT that gives unified access to GNOME, KDE, Mozilla, Java, OpenOffice
          o Allows AT to concentrate on improving user effectiveness
                + Simplifies logic in application-specific enhancements


AT-SPI Architecture
* 'Registry':
o Central registry of apps which implement a11y API 
o Central agent handles service event requests and notification 
* Actual implementation details may vary 
o Dispatches of application events 
* AT-SPI 'Accessible' and interfaces:
o Programmatic access to application user interfaces 
* UI structure 
* Content 
* Visual representation and attributes 


Desktop needs to provide location and registration services so that AT can find application and register for services,  provide notification of device events and I/O, provide communications infrastructure

AT - mediate, must listen to events
Adapt - must proactively manipulate interface

Long term goal- all applications are accessible
Requires: all apps meet functional criteria, apps must export functionality consistent with AT ABI
- At must have access to services it needs, keyboard snooping, display hooks, input device
- Must be able to write an AT to a known interface SPI
- Awareness among programmers of services needed, testing

The application functional comes after we have a functional consistent ABI - don't have to speak the same ABI as long as they can be mapped onto the ABI.  We want them to export their information in a know format and we can deal with problems through bridging.

In Linux there are multiple toolkits, heterogeneous desktop
AT-SPI provides the service model, provides device event notifications, provides application event notifications, programmatic access to application user interfaces
Simplifies or eliminates need for AT maintained off screen model.

AT can maintain an OSM but it can do so with less effort without snooping on features in the desktop 

AT-SPI is broader and more general than MSAA.  MSAA doesn't quite provide enough information about what is going on in the screen.  AT-SPI gives AT a uniform interface within a highly heterogeneous desktop.  Makes it possible to write one AT that gives unified access to GNOME, KDE, Mozilla, JAVA and OpenOffice
Allows the AT concentrate on improving user effectiveness.  Events from AT-SPI still requires complex logic but it makes it more tractable.

Registry daemon
- central registry of application which implement AT SPI
- Central agent handles service event request and notification (still talk directly to application using structures provided by registry)
- Dispatches of application events

AT-SPI 
UI structure - current there is a one-to-one correspondence between AT-spi and UI objects,  this is not required by the architecture, the application could provide an alternate interface for the AT device and simplify

It is not possible to register a specific listener for an object, all go through the registry.  In Java API, you have to setup a listener for each object you want to monitor(Java has utilities to set up these listeners).  AT-SPI requires you to go through the registry.

Doesn't give you direct access to the document model, it gives access to a view of the document.

Protocol and ABI
* Protocol 
o RPC on objects 
o CORBA-based 
o IP or sockets transport 
o Network-transparent 
* ABI

o Based on BonoboUnknown (trivial IDL) 
o Multiple language bindings exist 
o C bindings most common, ugliest 
o Java and Python bindings are far superior 


Remote procedure call model- objects you can sent call to
AT lives in its own process space so everything is done via interprocess communication.
Use IP or sockets transport
CORBA based
Network transparent

Life span of a CORBA object reference is unlimited.  In reality the IPC may go away at some point.   Can talk to an accessible app as long as it is running.

ABI
Based on Bonobo Unknown - simple IDL
Multiple Language binds for the ABI: Java, C, Python
Java and Python bindings are easier to use than C bindings.  They don't expose the CORBA architecture.  The C binding expose the CORBA, doesn't handle exception.

Performance- haven't done comparison on relative performance of these binds.  Think that Python bindings maybe better but maybe inherent efficiency of Python.

Desired Characteristics
* Protocol 
o Object-oriented 
o Extensible 
o RPC 
o Network-transparent 
o Standards-based 
o performant 
* ABI
o Multiple language bindings 
o Readily available to managed runtimes 
o Based on existing model/ABI 
o Supports interface query 
o Controlled dependencies 


Desired characteristics of Protocol
- needs to be object-oriented
- needs to be extensible, be able add interfaces
- support RPC
- Network transparent
- Standards based
- Performant


-Multiple language bindings
-Readily available to managed runtimes
-Based on an existing model/ ABI - base on something that is widely used
( don't create a new one and therefore a new dependency)
-Supports interface query

Will- provisions for handling failure?
CORBA doesn't do that very well, Orbit does.  We've avoided tying to Orbit.

Existing Clients and Implementors
* Clients
o Dasher (C++, custom toolkit) 
o GOK (C, GNOME) 
o Gnopernicus (C, GNOME) 
o Orca (Python, none) 
* Implementors
o GNOME 
o Java (via java-access-bridge for at-spi) 
o Mozilla (ATK) 
o OpenOffice (java-access-bridge, UNO-a11y) 
o Adobe Reader (ATK) 
o KDE (QtAccessible->ATK) [WIP] 
Current clients
-Dasher(C++, )
GOK (C., GNOME)
Gnopernicus (C, Gnome)
Orca (Python, no toolkit

Implementers:
Gnome
JAVA- via bridge
OpenOffice via java-Access-bridge and UNO
Adobe Reader (ATK)
KDE ( QtAccessible to ATK bridge)
Harald - also writing a Qt to AT-SPI bridge 

ATK - from application standpoint you don't want to see all the client server detail. ATK maps to AT-SPI, uses easy to use in process calls so you don't have to do all the RPC 
Thin wrapper  

Client Bindings
* C:
o C Corba bindings, defined by the CORBA spec 
o Cspi candy-coating 
* Not designed to be normative interface 
* Implementation requires standard C bindings for ORB 
* Cspi could be bundled with AT if desired 
* C++:
o C++ bindings defined by CORBA spec 
o Unfortunately, no C++ bindings for ORBit2 
o Use C bindings instead 
* Java:
o Java bindings, defined by CORBA spec 
* Python:
o Via PyOrbit 
o Lifecycle issues become transparent 
Client Bindings:
C - C CORBA bindings, defined by the CORBA spec
Using IDL so its not dependent on a particular language
Cspi - wrapper to hid some of the ugliness of the Corba C bindings

These can make writing AT easier but not designed to be a normative interface
Implementation requires standard C bindings for ORB
AT can bundle Cspi if desktop doesn't support it.

No C++ bindings for ORBit2 compiler,  Use C bindings instead.  
If you want to use an alternate ORB that has CORBA bindings, can use it
Java- Java bindings as defined Corba spec
Python - Via PyOrbit,  lifecycle issues become transparent

Barriers to Adoption
* Dependencies
o ORBit2 or other CORBA-compliant ORB 
o Bonobo (remediable) 
* Performance concerns
o Protocol-based concerns are addressed by ORBit2's sockets-based protocol 
* Competing RPC protocols
Barriers to adoptions:
- Dependencies:  ORBit2 and other CORBA compliant ORB & Bonobo
( concern that there are too many library dependencies - some are pretty soft
lots of libraries.  ORBit2 has some library dependencies.  
The Bonobo dependency is small, could fix that. 

Mark- Registry activation is done through Bonobo so its major.  Can't connect to anything if I don't have Bonobo installed.

The AT just need to make a call to get the start the registry.  

Mark- CORBA doesn't give you a way to find stuff.
- it has a way to find things, but people have found it difficult to use.

The applications that the user wants are all mapping things on to the X display, all are talk to Xserver.  Argument that the registry should be defined by the X display.   Can do registry can be placed on the root window.  

Peter- issues have been discussed many times,  it would be useful to have a document that enumerates the problems and potential solutions. 

Olaf- what about console applications.  Need to have a way to handle console, ss
The xserver solution that would work at console.
- the API don't presume that there is a screen, there are different ways to store the registry and keys.  If you ssh into a text mode application, the interface is being graphically though the x virtual terminal so xserver is there.  There are some ugly problems with CURSES.

Performance concerns. - If you need to marshall and de-marshall a lot of data, that is going to take some time.  If you're not using shared memory, you
Marshalling, demarshalling over TCP/Ip, serialization process is going to take time.

Harald- if I want to access a widget tree, that is a lot of data.  
- opening and closing a connection for each request,  need to optimize

Lots of ways of doing things in Linux distributions: UNO, Jeanie, d..
People have vested interest in these protocols.  We can't say we're going to choose a RPC protocol for the desktop.  We need to identify one and find what are the substantive issues.  Longer term- we can look at ways to improve IPC.

What is the mechanism to go from the proposed implementation to develop a 2.0 version that might be based on Dbus or other protocols.


Potential Alternatives
* Alternatives
o Promote cspi and provide alternate back-ends 
o Replace CORBA with DBUS 
o UNO 
o Make the IDL normative, and allow alternate ABI conformance vehicles 
* Pros/Cons of each
o Cspi cons: bad for managed runtimes, handles internal cacheing, not designed to be universal. 
o Cspi pros: few dependencies in the ABI, already exists and is used by some AT 
o DBUS cons: does yet meet requirements, not yet sufficiently complete. Designed for simpler localhost communications. So-so for managed runtimes. No IDL compilers available. 
o DBUS pros: very few dependencies 

Potential Alternatives (2)
* Alternatives (cont)
o UNO 
o Make the IDL normative, and allow alternate ABI conformance vehicles 
* Pros/Cons of each
o UNO cons: Specific to OpenOffice/StarOffice. 
o UNO pros: shipped by most distros, mature, meets criteria. Performant, and supports IDL compilation. Could be drop-in replacement. 
o 'Many worlds' cons: Novel approach. Short-term path would retain at-spi dependencies. 
o 'Many worlds' pros: allows short-term adoption of existing implementations, while being future-proof 
Recommendation
* Recommend one or several strategies
* Give a summary of the expected results
* Name the next steps to be taken
* Delegate the various tasks 



-- 




More information about the Accessibility mailing list