Hi Marcus, Thanks for the post. The proxy DLL is just a way to notify COM of the IA2 interfaces so it can do the proper marshalling when a client (AT) calls a server (app) which has implemented IA2 methods. An application still needs to implement the IA2 methods. The proxy DLL is used by the COM marshaller. The app's IA2 implementation would be in a separate DLL. The IA2 proxy is not related to IAccessible (MSAA). It only defines the IA2 interfaces and methods for use by the COM marshaller. I would redraw your interaction diagrams like this:
app fires event --> AT
AT --> calls MSAA or IA2 to fetch data (Which methods are called depends
on the type of event and then the subseqent role and state that are
fetched from the object.)
I didn't include the proxy dll becaues I'm not sure how it's used by the
marshaller but it's not really important with respect to understanding the
bigger picture. The marshaller is just involved in matching the
caller/client/AT with the callee/server/app across the COM boundary. It's
not involved in the actual IA2 implementation.
Regarding only ATs shipping the proxy - that includes the accProbe
interface tester and the NVDA screen reader both of which are open source.
Both of these will ship the proxy. Every IA2 client (AT or IA2 interface
tester) will ship the IA2 proxy DLL. Every app that has implemented IA2,
e.g. Symphony and Firefox 3, will be accessible by every IA2 enabled
client, e.g. JAWS 9 or 10, Window-Eyes 6, NVDA, and AccProbe. Apps don't
need to ship the proxy DLL because the proxy DLL is only needed when there
is an AT to call the IA2 interfaces and the AT will be installing the
proxy DLL.
The blind developer you are working with who is running Window-Eyes 4.x is
won't be able to access the IA2 features of Symphony or FF3 without
upgrading to a later version which has code added which understands how
fetch and process IA2 data. My guess is that it costs an AT vendor on the
order of a quarter million dollars to implement a new feature like IA2 and
this is reflected in the cost of upgrades.
Pete Brunet
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G
Marcus von Appen <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/11/2008 05:27 PM
Please respond to
Marcus von Appen <[EMAIL PROTECTED]>
To
IA2 Accessibility List <[email protected]>
cc
Subject
[Accessibility-ia2] IAccessible2 support in applications and libraries
Hi,
I have some general questions regarding the proposed IAccessible2
standard for Win32 platforms. As I am in the process to spend the python
a11y wrapper, I'm currently developing, Win32 support, I was recommended
to settle on IA2 as it should ease the development of a11y aware
applications on Windows and fills some serious gaps MSAA currently has.
I surely can agree with this, but regarding compatibility, distribution
and availability I have some concerns I'd like to sort out before
starting with the development.
First of all I'd like to know, whether linking to the IAccessible2Proxy
DLL and using its functions is the only thing I have to take care of as
application (or in my case toolkit) developer in order to offer all
necessary support for accessibility systems on Win32 platforms?
My understanding so far is that the IAccessible2Proxy DLL wraps up MSAA
and adds some additional functionality, MSAA does not offer. The
conclusion would be that any MSAA aware technology, software or whatever
else is able receive and provide information via the IAccessible2Proxy
DLL, either by responding to (invoking) the underlying MSAA methods,
which are wrapped up, or by using the IA2 interfaces directly. Is this
correct or is an interaction like the following impossible?
>From application to AT system:
Application ------> IA2Proxy --------> MSAA ----------> AT system
calls invokes interacts
with
>From AT system to application:
AT system ---------> MSAA --------------> IA2Proxy ---------> Application
invokes/ recognized by feedback
reacts
The flow above simply means: Application calls IA2Proxy function, which
calls the wrapped MSAA function, which is recognized by the AT system.
The AT system (in turn or due to user input) reacts or interacts by
calling the MSAA function, whic,h due to its wrapping, is hooked into
IA2Proxy, which gives the feedback to the wanted application.
So far for the low-level technical questions.
While discussing with Pete the other day on IRC, he recommended not to
distribute the IAccessible2Proxy DLL with my toolkit as the AT systems
should ship it. That's a recommendation I cannot second due to at least
two reasons:
- Developers who want to add accessibility to their application will
need a working accessibility environment to verify correct
functionality. The majority of them possibly does not have an AT
system around, but merely stick to the software testing tools
available out there, which also might (and should?) not ship with the
proxy DLL. As a developer usually should know what he does,
(un)registering the shipped DLL would not be a big deal for him.
- Disabled people who do not own an AT system that ships with the DLL
might not benefit from parts or all of the application's features as
it requires the IA2 interfaces, which are not installed.
The second reason brings up the last question I have for now. As I
already told Pete, not anyone has the newest AT system version and I
guess many of those relying on an AT system are not willing to buy an
upgrade or new version of it (in case it's a commercial one, like JAWS
or Window-Eyes).
In fact I'm currently in contact with a blind developer, who uses
Window-Eyes 4.x, which might not get an update that ships with the DLL
(is there someone from GWMicro or FreedomScientific reading, who can
give some more details regarding this issue?).
Affording an upgrade to the most recent version that ships with the DLL
is no option for him at the moment as spending $400-$600 for an upgrade
(or even worse buying a new version for around $1000) is out of his
limits at the moment. This might be the case for several people who have
to rely on an AT system.
Thus I wonder, if older AT systems have any limitation regarding the IA2
specs (without the enhanced functionality), e.g. not being able to
communicate with it through MSAA as IA2 needs some special negotiation
process or whatever else?
Regards
Marcus
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
attljv34.dat
Description: Binary data
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
