[Accessibility] Conference transcripts for Tuesday and Wed. AM

[earl johnson]

There were folks on the phone and IRC that aren't captured on the 
attendees list, I was one of them.

Earl

Doug Beattie wrote:

> 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 
> 
> 
>