source: Peter Korn, quoted email, 7 October 2008
Mostly this was Bill Haneman, myself, and Aaron Leventhal. The issues were:
This is what led to the Collections interface - something we felt was both very similar to our existing APIs, and could be most generally implemented most places. As opposed to a DOM interface which would be very alien to something like OpenOffice.org.
source: Proposal to standardize DOM node access, Pete Brunet 7 October 2008
Some questions and comments regarding the ISimpleDOMNode proposal discussion on the IA2 list:
As a few of the commentors have indicated, a primary goal of IA2 has been to facilitate efficient cross platform (Windows/Linux) application development. One
of the primary arguments for standardizing ISimple* is, rather, to facilitate efficient cross-browser AT development. We want to expose special markup like math] on Linux as well but there is no ATK/AT-SPI equivalent to ISimpleDOMNode. The larger OpenA11y group needs to determine if ATK/AT-SPI should include an equivalent to ''ISimple*''.
There is also the issue of the delta between ''ISimple*'' and the IE equivalent. While we are considering harmonizing ''ISimple*'' with ATK/AT-SPI should we also, via AIA, consider defining an interface definition that deprecates both ISimple* and the IE equivalent so application and AT implementers have only one interface to deal with?
[[:accessibility:handlers:references:smls|Specialized markup like Math also needs to be accessible in non-browser environments. Would ISimpleDOMNode
be implementable in other applications such as office applications?
Does ISimpleDOMText
need to be included? I think all of it's function is covered by IA2's IAccessbileText
.
Alternatively, would it be sufficient to provide access to the specialized markup via a new IAccessible2::get_innerMarkup
method?
source: Janina Sajka, Proposal to include ISimpleDOMNode, posted 9 October 2008
I'm taking the liberty of forwarding Aaron's email to the main Open A11y list, because I think it important that we engage all our communities of interest, including especially the Linux/Unix people, in this conversation. I think there's general agreement in both the Expert Handlers group and the IAccessible2 group, that an appropriate expert handler should involve a common architectural approach. Perhaps the solution propounded from Expert Handlers is not precisely what we need, but it seems something like it might be. I believe Aaron's point below is well taken–we are indeed exclusively speaking of XML.
So, in order to continue the conversation with the wider Open A11y community, I'm forwarding this email. There's additional email history on this thread in the IAccessible2 email list archives beginning at:
https://lists.linux-foundation.org/pipermail/accessibility-ia2/2008-September/000593.html
the Unified Use Cases document and recent discussion in the Expert Handler SIG will also be of interest:
Lastly, please note that several participants have requested we not wait three weeks to continue teleconference discussion on this topic. So, in consideration of our early morning participants from Australia, we will NOT use the Open A11y call next Tuesday. Rather, everyone is invited to continue this discussion in the IAccessible2 teleconference this coming Tuesday at 4 PM U.S. Eastern time, 1800h UTC. Additional information for this teleconference will be forthcoming as Tuesday approaches.
Aaron Leventhal writes: > It'd be good to find out more. > > When we say DOM here we're talking about XML-based DOMs. Nodes, tag > names, attributes, etc. > As far as the kinds of specialized content that need expert handlers, > the examples that came up were always XML based. > How alien would it be for OpenOffice to expose nodes MathML content when > there is math, etc. > > It wouldn't be required for the DOM interface to be used everywhere. In > fact if there's no chance of any interactive widgets inside the content, > you could just expose one node at the top, and support only the > innerMarkup method with the full MathML string. > > Basically the concept is to provide a mechanism that can be scaled up as > things get more complex, but can easily handle the basics as well. > > - Aaron
Discussion at [[:accessibility:handlers:meetings|Expert Handlers Calls]]
Discussion at Open Accessibility Workgroup Calls