[Accessibility-ia2] Math interfaces

Neil Soiffer NeilS at DesSci.com
Tue Feb 6 09:00:38 PST 2007


[I wrote this last week, but my machine crashed (its a Window's box :-(), and I forgot to send it when it rebooted.  Thankfully most of the message was saved -- Pete's agenda reminded me about it -- apologies for the long delay]

On the teleconference this morning we discussed math accessibility and I promised to post the interfaces that we are working with vendors on.  Later on in this email, I post some info from the IDLs we have.  First, some background for those of you not on the call...

Currently, we/Design Science/MathPlayer generates a plain text speech string if someone queries MathPlayer for the "name" or "value" fields using MSAA in IE.  For the MSAA "role", we use ROLE_SYSTEM_TEXT.  I tried using ROLE_SYSTEM_EQUATION and no AT software would work with MathPlayer, so I fell back on ROLE_SYSTEM_TEXT.  That is currently how most AT software interacts with MathPlayer.  Some go further and others are working with us to implement some of what is described below.

One of the points Aaron raised that I (reluctantly) agree with is that the accessibility interface provides access to the contents of the document, and doesn't present a view or interpretation of the data.  As I also said, this punts math accessibility elsewhere.  Eg, by that reasoning, Mozilla has already solved the math accessibility problem because it lets AT software get at the DOM and grab the math.  From a user's perspective (and I think most/all AT vendor's perspective), that is not a solution.  I think Aaron would agree that math in Firefox is not accessible even though AT software can get at the MathML in the document.

There was some vague (at least to me) discussion of this being some other standard that AT vendors should support.  After a little further consideration, I am back to thinking that perhaps there really is a place in IA2 for string-based access to highly structured data (math, chemistry, SVG-based graphics, ...).

For highly structured data, access to the structure is not particularly useful.  For a text analogy, it would almost be like exposing the underlying data structures of text application -- the data is all there, the AT just needs to know how to put it together to form a text string to send to a TTS... if the AT can somehow know what that structure means.

MSAA and IA2 offer a way for to get at the structure tree of the math, but there is no requirement for what that tree actually means.  Hence, it is meaningless access.  At a minimum, IA2 must specify that the tree identify itself as representing some standard such as MathML.  I would go further and say that IA2 *must* specify that *a* (defined) standard tree is returned.  If the returned structure can be one of multiple formats for math, the likelihood of a vendor implementing all of them is near zero given that implementing useful accessibility for a single standard is already a heavy burden.

The alternative to specifying the structure that should be returned for math is to assume that the math application is the expert about math accessibility (rather than the AT) and have IA2 define an interface that is string-based for math access.  One reason that this is not unreasonable is that both speech and braille are inherently linear (as is synchronized highlighting with speech).  This chain of logic gets me back to what I was originally thought the group should do... and contradicts my statement at the outset of this mail that I agree with Aaron that access to the raw data is all that MSAA and IA2 should provide.

At long last, here are some IDL file snippets for math accessibility:

interface IMathSpeech : IDispatch {
 // generate NONE, SAPI4, SAPI5, SSML depending on the value of 'speechTags'
 HRESULT GetSpokenText([in] SpeechTagsEnum speechTags, [out] BSTR *spokenText);
};

For an IA2 proposal, I think a braille math interface it would simply be something like:
 interface IMathBraille : IDispatch {
 HRESULT GetBraille(
    [in] BSTR codeName,        // braille math code to return
    [in] long width,           // number of braille cells on the line
    [out] BSTR *braille        // the resulting braille
);

Probably the returned braille needs to specify its mapping to dots (another parameter (an array) that could be passed in or returned depending on who we want to say has control over that).  Alternatively, "braille ASCII" could be the specified format for IA2 for 6-dot braille and a different mapping used for 8-dot (don't know if there is a standard).

Neil Soiffer
Senior Scientist
Design Science, Inc.
neils at dessci.com
www.dessci.com
~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility-ia2/attachments/20070206/2f0f1dd0/attachment.htm 


More information about the Accessibility-ia2 mailing list