The Linux Foundation

 
Accessibility/Minutes/Minutes20081028

From The Linux Foundation

Revision as of 02:21, 4 November 2008 by Oedipus (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Open A11y Working Group Conference Call (28 October 2008)

Contents


Preliminary Items

Participants

  • Pete Brunet (PB/co-chair)
  • Janina Sajka (JS/co-chair)
    • David Bolter (DB)
    • Mick Curran (MC)
    • Peter Korn (PK)
    • Aaron Leventhal (AL)
    • Neil Soiffer (NS)
    • Jamie Teh (JT)

For Reference

Approval of Past Minutes

Resolutions Reached at the 2008-10-14 Open A11y Conference Call



Meeting Minutes

Note: The regular Open Accessibility call was held during the IAccessible2 call's time slot to make it feasible for Australian participantion

Topic 1: Whether or Not to Standardize ISimpleDOMNode

PK: There was a similar debate sometime ago but Bill Haneman was opposed

AL: I don't remember that, 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 conversation 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. However, 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 Windows, from before IA2, e.g. forgetting bounds of characters. The expert handler can get acess tothe XML subtree and can pass on the XML DOM tree or the innerhtml.

AL: If screen magnifier is magnifying elements as they are spoken, and if the content is special, 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 support 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, chemistry

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 to do it; they want generic standardized interfaces and don't want to change it for other markup (music, chemistry, 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 IA2mean?" 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 chunk 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 chunks of the DOM; and consider braille, when on a chunk 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 plug-in is rendering - so for other XMLs shouldn't 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 plug-in, Safari and Opera use CSS, but you're never going to get someone to do chemistry or music.

MC: Are plug-ins available for music?

JS/NS: We don't think so

JT: If browser doensn't support so no need for AT support, but if browsers 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 there's a better way lets do it

PK: Concerned that if we give this an impramatur, 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 implement IA2/ATK; if you are rendering you need to implement 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 support 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 themarkup anyway; if you want caret navigation then you already have to comeup 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 Windows a11y.

PK: We have legacy of ATs doing everything, but regulations are now saying 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 browsers want to do IA2 eventually, 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/chemical/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; afraid 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 revised

PK: Let's start with a bunch of MathML to think through how this might be handled JT: None of us has a solution; IAText is char by char, so the problem is not compatible

PK: Maybe chunk by chunk

JT: One other problem 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



Topic 2: SIG Updates



Topic 3: Website Update

General Interest Links

Expert Handlers Links to Further Discussion



New Business


Identify Topics for the 4 November 2008 Teleconference


Wrap Up




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