[Accessibility-ia2] Proposal to include ISimpleDOMNode, ISimpleDOMDocument and ISimpleDOMText as optional part IAccessible2

Aaron Leventhal aaronlev at moonset.net
Fri Sep 26 05:24:34 PDT 2008

My proposal is this:
Include at least ISimpleDOMNode, and possibly ISimpleDOMDocument and 
ISimpleDOMText in IAccessible2, as optional interfaces for an 
application to expose.

The interfaces I'm referring to can be licensed as LGPL. They are 
currently exposed only by Mozilla:

I anticipate some questions and concerns. So here's a mini-faq :)

What assistive technologies use ISimpleDOMNode?
1. JAWS 10
2. ZoomText
3. Upcoming version of System Access To Go
4. Another AT with upcoming Firefox support, but I haven't yet received 
permission to mention it

Why use it when there's IAccessible2?
It's the fastest way to implement cross-browser support for a virtual 
buffer/browse/review mode. The AT can share a lot more code with their 
IE implementation.

What other advantages does it have?
It can easily be used to expose mathematics to an expert handler. 
There's an "innerHTML" method which can be used to exposed the markup 
for any subtree, yet you can still access IAccessible/IAccessible2 down 
in a descendant if the math includes some form controls or links.

What other browser vendors want to use it?
At least one browser has already been asked to support ISimpleDOMNode 
because, in combination with plain IAccessible, it's a quick way to get 
started. Ultimately if other browsers want to be accessible on Windows, 
they will all be asked for the same thing.

Would IAccessible/IAccessible2 still be needed?
Yes, especially because it has no event system. IAccessible and 
IAccessible2 would still be crucial for widgets. IAccessible2 would 
especially be important for rich text editing and other advanced 
features (such as ARIA and live regions).

Would it be required to implement it?
No. It's a convenience for the web and (I believe) very useful for 
exposing math and other content to expert handlers.

There are some methods we don't need in there, or some changes we should 
make. Can the interfaces still be changed?
Possible, but we need to talk about that. It would be easiest for ATs if 
it stayed exactly the same, but perhaps we can devise a transition 
strategy of some kind. It's worth discussing

Would this be useful in ATK/AT-SPI as well?
Probably not, since Orca and other ATs there don't have a history of 
using or needing this. If some cross-platform expert handlers that 
consumed part of it became common, then perhaps a similar interface with 
only the necessary methods could be deemed useful.

Anyway, those are my thoughts. I'd appreciate feedback. Please remember 
I'm saying that implementing it would be at the app's descretion, and is 
just to make life easier for virtual buffer implementations, but 
supportng expert handlers as well.

- Aaron

More information about the Accessibility-ia2 mailing list