[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