[Accessibility-handlers] Minutes from ISimpleDOMNode discussion
Janina Sajka
janina at a11y.org
Mon Nov 3 10:21:41 PST 2008
Thanks, Pete.
For the record, Gregory has also posted these minutes under the main
Open A11y Meetings, Agendas and Minutes page at:
http://www.linuxfoundation.org/en/Accessibility/Minutes/Minutes20081028
We should perhaps consider whether it would be useful to cross-link
these minutes to Expert Handlers, and even perhaps to the IA2 minutes
pages.
We also have audio available that we might post..
Janina
Pete Brunet writes:
> Here are the minutes I sent to Janina last Friday to be posted in the Open
> A11y minutes. I didn't write down any action items. There was some
> discussion related to getting XML samples, Braille and speech samples, and
> getting ideas about how to apply IAccessible text., but unfortunately I
> didn't capture the action items in my minutes. -Pete
>
> Regrets: none
> Attendees: Pete Brunet, Mick Curran, Janina Sajka, David Bolter, Jamie
> Teh, Aaron Leventhal, Neil Soiffer, Peter Korn
>
> Discussion about whether or not to standardize ISimpleDOMNode
>
> PK: There was a similar debate some time ago but Bill Haneman was opposed
> AL: I don't remember ththat, but if we had DOM support then maybe we would
> have ended up using the DOM too much; what we have now is good; the new
> converstaion is that is might be helpful for expert handlers
> PK: Back in around 2002 Bill, Aaron, and I looked at this, i.e. would the
> DOM be a good way to provide access to HTML content. The DOM then was not
> able to provide access to rendered info, i.e. on screen location of text;
> that's a problem for magnifers. Also there was no DOM standard; would
> have to get existing projects to support someone's DOM or get everyone to
> decide on a new DOM spec. We decided that the ATK interface wouldn't try
> to look like the HTML DOM. Howver, the old decisions may no longer be as
> valid. Will and Li Yuan would be better to offer input for today.
> AL: The goal is not that ISimpleDOMNode would be used everywhere; there
> are just a couple of special use cases; Mozilla already supports
> ISimpleDOMNode on Win, from before IA2, e.g. for getting bounds of
> characters. The expert handler can get acess to the XML subtree and can
> pass on the XML DOM tree or the innerhtml.
> PK/AL: If screen magnifier is magnifying elements as they are spoken, and
> if the content is spcecial, ISimpleDOMText provides the bounding rectangle
> and logical ordering. ZoomText uses these in Firefox
> AL: For OOo implement ISimpleDOMNode on special markup; just return the
> math string, or implement an a11y obect for each node and suppport clipped
> and unclipped; could add ATK objects along with the ISimpleDOMNode info;
> would need atk for when caret is moving; can QI/QS between the interfaces.
> There are several ways to approach it: 1) every node supports
> ISimpleDOMNode, a subset of nodes support MSAA/IA2, AT only accesses XML
> if role/QI indicates availability of ISimpleDOMNode, May want to
> consider adding ISimpleDOM* interfaces to the set of MSAA/IA2 interfaces.
> AT can process raw info directly or hand it off to an expert handler.
> JT/NS: You have to backup the DOM nodes with real a11y objects so you can
> get the bounds.
> AL: Also ISimpleDOM* has no events so need full MSAA/IA2 support on the
> nodes
> PK: Need keyboard equivalent to mouse features, i.e. selecting text, and
> caret support too
> AL: Need virtual buffer support too
> PK: Regulations say you must have keyboard support without an AT
> AL: Firefox supports careting through math; Firefox wants to support math
> as first level objects, using ATK, MSAA/IA2; expert handlers want other
> special markup (chem, music, etc)
> PK/JS: The core question is should Open A11y support ISimpleDOM*
> PK: For general use?
> AL: No, just for special content: math, music, chem
> JS: There a corrallary to drive us to a generic approach, i.e. a lot of
> XML will never get handled well by AT; we need experts to get involved and
> handle that well; and let AT handle what they know like how to deal with
> Braille
> NS: We found talking to ATVs that they'd love to have math accessibility;
> they want an expert handler toi do it; they want generic standardized
> interfaces and don't want to change it for other markup (music, chem,
> svg); so the expert handlers (and ATs) shouldn't need a different
> interfaces for different platforms; and the ATVs want to have the option
> to differentiate if they see a business case for improving what an expert
> handler has done
> JT: Am concerned that only ISimpleDOM* would get implemented and not
> MSAA/IA2
> JT: What does "complies with IA2 mean?" I don't think ISimpleDOM* belongs
> in IA2
> MC: There is nothing stopping app/AT from having an agreement to use some
> nonstandard approach; it's OK if ISimpleDOM* is standardized
> JT: And used where appropriate
> JS: The expert handler group has been looking for something
> JT: We already process HTML and it's a big task; handling special content
> is going to be tough, e.g. if you are arrowing through symbol by symbol
> you have to know what DOM chunck to read; it's not a simple matter of just
> getting text; the expert handler has to know how to process a single
> smbol; the expert handler has to look at chuncks of the DOM; and consider
> braille, when on a chunck have to expand that so user can move through it
> char by char in the Braille device and what happens if Braille user
> presses cursor routing key on a Braille cell and for speech, what if user
> is using a language other than English; how do you translate symbols in a
> way that is understandable?
> JS: HTML is understood, but what if it isn't HTML
> MC: What if we have music XML; for math, the browser or it's plugin is
> rendering - so for other XMLs shouldn the browser render it - might not
> know the Braille and speech to use but we should be able to get there with
> the AT and UA devs working together
> NS: Disagree, Firefox has native support, IE uses a plugin, Safari and
> Opera use CSS, but you're never going to get someone to do chemistry or
> music.
> MC: Are plugins available for music?
> JS/NS: We don't think so
> JT: If browser doens't support so no need for AT support, but if browers
> can already render then we need a solution; should we look at the short
> term expedient solution, such as ISimpleDOMNode or should we focus on the
> final solution? Interim solutions have a habit of being permanent
> solutions.
> AL: If people want a general XML soution why not consider just dealing
> with the XML DOM in a general way, but if theres a better way lets do it
> PK: Concerned that if we give this an impramature, then folks will do this
> and not the other things they need to do - so messaging is very important
> - optional aspect must be stressed; don't want to deal with situation were
> - "well it work's with this AT" so I don't have a problem - we need this
> content to implement ATK/IA2 for the case of handling caret movement, need
> to make it clear that apps must implemnet IA2/ATK; if you are rendering
> you need to impolement the a11y api and then can go beyond that to
> implement ISimpleDOMNode
> JT: The catch with that argument is that if the a11y code is already
> implementing caret suport then no need to implement ISimpleDOMNode; you'd
> be be doubling up on interfaces; you'd get text first with ISimpleDOMNode
> but then use caret navigation for the markup anyway; if you want caret
> navigation then you already have to come up with a better way; under Win
> all screen readers implement virtual buffers and thus have caret nav (one
> reason is the in process nature of Win a11y.
> PK: We have legacy of ATs doing everything, but regulations are now waying
> that apps must have native keyboard support
> JT: Some browsers aren't going to be accessible unless they start with
> ISimpleDOMNode, but that's not a good message; they need to implement the
> proper a11y APIs.
> AL: As far as I know all browers want to do IA2 eventualy, but want to get
> started via ISimpleDOMNode
> JT: We are talking about the situation that browser can get a11y support
> from a single AT by implementing ISimpleDOMNode; we have doubts about the
> whole virtual buffer concept but we've learned that under Windows there is
> no other way.
> PK: Where do we go from here?
> AL: We need an alternative proposal; how to use IA2/ATK for math (SVG
> must use ARIA - SVG has no semantics); maybe we can use accessible text
> for math; for music/chem let's look at use cases
> PK: Let's get some math/chem/music markup to analyze; then come to
> consensus to how would deal with these XML fragments with existing apis;
> concrete examples would be helpful
> MC: Would like braille and speech output examples
> JT: Can't see how this is going to work; afriad theory can diverge from
> practicality
> MC/JT: Don't want to stand in the way of progress though
> AL: Anybody have head start on how would use IAText with math?
> PK: Can imagine couple of ways; break up
> numerator/demoninator/expressions and then have accessible relations; can
> decompose into accessilbe objects; but how to determine what an object
> is?
> JT: Seeing the markup would be helpful
> JS: Neil's company writes expert handlers and have reinvented wheel over
> and over when AT or OS rev'd
> PK: Let's start with a bunch of mathml to think through how this might be
> handled
> JT: None of us has a solultion; IAText is char by char, so the problem is
> not compatible
> PK: Maybe chunck by chunck
> JT: One other probblem is that I've never seen an equation editor that
> does careting properly; need careting guidelines how to implement
> accessibility
> DB: Are we talking about just reading or also edting?
> JT: I would like to edit
> JS: How equations are spoken is country specific
> JT: I can think of three different math codes
>
> 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
> _______________________________________________
> Accessibility-handlers mailing list
> Accessibility-handlers at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-handlers
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina at a11y.org
Linux Foundation http://a11y.org
IPv6 is the answer!
More information about the Accessibility-handlers
mailing list