The Linux Foundation

 
Accessibility/Handlers/Meetings/Minutes20080929.html

From The Linux Foundation

Contents

Minutes of the Open A11y Expert Handlers SIG Call 2008/09/29

Note: These minutes have not yet been finalized.

Preliminaries

Attendance

  • Neil Soiffer (NS/chair)
  • Janina Sajka (JS)
  • Vladmir Bulatov (VB)
  • Aaron Leventhal (AL)


Approval of Last Meeting's Minutes



Minutes of Expert Handlers Conference Call 2008/09/29

Aaron described his ISimpleDOMNode. They accessed info via the DOM (mainly for IE). Initially, AT used MSAA with Firefox, but it wasn't as good as At's access to IE. Firefox added ISimpleDOMNode. It is a simpler interface than IE's interfaces. It allows you to walk the DOM, getting the parents, children, etc., or getting the entire child's "HTML". It is the full DOM, not a mirror to the accessible DOM.

ISimpleDOMNode allows the AT to decide that it doesn't want to handle the content and it can hand it off to the EH, either by passing the contents or a pointer to the interface.

The AT should be the one that associates a handler with specific content, not the application.

This solves one of the problems we have been talking about. It doesn't address what the interface is between the AT and EH. For example, what is the speech text, braille, etc. However, it keeps the apps out of the business of interacting with the EH other than ISimpleDOMNode.

VB: What about navigation?

AL: Supports "navigate to". Can't do highlighting directly. ISimpleDOMNode can QI for other interfaces though. It directly supports access to node info (names, namespace, attributes), cascaded style info, In particular, ARIA roles, properties can be accessed. scroll to (make x,y visible) child, parent, sibling, .... language (current language) ISimpleDOMText access to text node, bounds, font family ISimpleDOMDocument (URL, title, MIME type, ...)

ISimpleDOMNode is only used/implemented by Firefox, but ATs are asking Opera to implement, which will then get WebKit to implement it.

NS: ISimpleDOMNode sounds a bit like Acrobat/Reader's DOM interface: IPDDomNode, IPDDomDocument, IPDDomeElement (see http://partners.adobe.com/public/developer/en/pdf/access.pdf). In the last few years, I think use by AT of this interface has become widespread (as oppose to the MSAA interface).

AL: Easiest only implement InnerHTML, next traversal methods, to overlay on Accessible to QIs back and forth work (links, form controls inside of content).

JS: what about non text node bounds.

AL: maybe that info should be added to ISimpleDOMNode.

AL: support can be incremental. First static info can be implemented (Braille, Speech Text), then more support can be added such as QI for other interfaces/info.

JS: need to get non-windows folks on call in October or November. We'll figure out who later.

VB: still worried about graphics not really a tree. Not natural to navigate as a tree. AL: ARIA provides relational links, and so accessing them allows for different views on the DOM tree.

AL: See codetalks.org for more examples of ARIA.






[Article] [Discussion] [View source] [History]