Re: math role for ARIA - ARIA Subteam Public Meeting Minutes 2008-03-31 [DRAFT]

Some comments interspersed below.  I hope it doesn't get too confusing...

On Fri, Apr 18, 2008 at 2:16 AM, Aaron M Leventhal <aleventh@us.ibm.com>
wrote:

>
> Al, sorry for the delay in replying.
>
> Al Gilman <Alfred.S.Gilman@ieee.org> wrote on 04/14/2008 04:24:12 PM:
>
> >
> > On 11 Apr 2008, at 4:57 AM, Aaron M Leventhal wrote:
> > >
> > > I don't understand the definition of the role, especially the
> > > describedby parts. I thought we were just going to use the
> > > accessible name for the math text?
> >
> > You thought the browser would take the LaTeX from the @alt and stuff
> > it in the accessible name.
> >
> > This has the downside that if the user doesn't have the helper, it
> > can obliterate a
> > good @alt that the author provided.
>
>
> Can you give me an example? What might the good alt for an equation be,
> that we don't want to obliterate?
> Since alt is a text equivalent for the image. Things that are not the
> equivalent should be put in the aria-describedby or title. Since the LaTeX
> (or whatever) way of expressing the formula is an equivalent it should be
> the alt that's used.


Suppose someone provides the TeX for the equation as an alt attr.  As you
said, that is alternative representation that describes the image, but few
readers will find it accessible if they don't know TeX.  For them, it might
as well be a binary format -- both are good sources of computer input.  If
the alt text is an (English) description of the image, that too (if written
well), gives an alternative representation, although it won't be likely be
useful for computer processing into other formats such as braille. To me,
the question that arises is to whom/what is the alt attr aimed at --
software or a human user?  Given current practice, is there anything this
group can do about what is placed there?

>
>
> > Neil has said that their helper, when it is called, is willing to dig
> > a little more to get the LaTeX so that the author can put in both the
> > LaTeX for those with the helper and their own reading of the equation
> > in some markup in the document.
> Okay, can I have an example of this format? It's not good enough to say to
> the authors and implementors "there is a way". If the implementors need to
> invent instead of just implement the mapping, we will all do it differently
> and authors won't have a stable platform.


Part of the answer is dictated by current practice.  In current practice,
there are at least three places where TeX or other formats are placed:

   1. in the alt tag
   2. inside of the image as comments
   3. inside of an applet element, in a "param"/value tag.

However, current practice is in a state of flux (eg, applets have lost
favor), and who knows what HTML5 (which, at least for now), includes
MathML), or javascript related solutions will do to current practice.  My
thought that the standard should leave out specification where TeX, MathML,
or other formats can live/be specified.  That info can be put in a "best
practices" doc which would be easier to update as new approaches are tried
and accepted (or rejected).

>
>
> > We discussed another option: the helper returning its reading of the
> > math
> > through the API by which it was called;
> > and Neil preferred an approach where they use what you are already
> > doing so the
> > AT has a minimum of additional logic to code and he (Design Science)
> > doesn't have to
> > negotiate different APIs with each AT or drag them all to the Linux
> > Foundation table
> > to work out a common API for calling the helper, except the most basic.
> Yes, but we also want to be able to support Braille math of different
> types. Accessibiity has always done the model separately from the view for a
> good reason. If we want ATs to be able to leverage shared math->TTS logic
> then we can put that in a library.
> But in any case, I'm not sure how this affects us. In either case the alt
> needs to have a text equivalent of the equation.


What I outlined on the call was two different approaches that could be used:

   1. Some js converts any TeX, etc, into a speech string and sticks it
   somewhere in the js-modified DOM where AT automatically picks it up.  Alt
   text was discussed as a possibility as was "described-by".
   2. Some js creates an accessible interface to the math/image and
   communicates with the AT to give it speech, braille, sync-highlighting,
   navigation, etc.

The first approach has the advantage that it is simple and "just works"
assuming the "right" location for where the js puts the text string to speak
is chosen.  The disadvantages are that there is no braille support (unless
some place to put the braille is agreed upon), sync-highlighting can't be
supported, nor can navigation (other than by the words/briaille chars
generated for the math).  Another downside is that SSML or other flavors of
speech cues can't be embedded in the speech string unless something is
agreed upon with AT vendors -- it can't go into the alt text because that is
assumed to be plain text.

The second approach is more flexible, but still has many limitations.  If
MSAA is used, only "plain text" speech can be supported.  There is no
support for speech cues, braille, sync-highlighting, or navigation.  To get
those, either vendors need to support a private interface or the Linux
Foundation or some other group needs to come up with a standard and the AT
vendors and maybe accessibility standards need to change a bit to support
that.

In either approach, the js runs when the reader loads the page, so that the
reader's choice of speech and braille code are used.  That's a big plus over
author-generated speech and/or braille.

It is not obvious to me which of the two approaches is preferable.  Indeed,
these are not exclusive options and so both could be done.  The key to the
first approach is agreeing where the speech and maybe braille should be
placed and getting AT buy-in on using those locations in preference (if
needed) to some standard location (ie, you don't want to hear both alt text
and math speech).


>
> >
> > > When is description used and what should it point to?
> >
> > The description is the literate reading of the math, from either
> > MathML or from LaTeX,
> > as generated by the helper called by the AT.  It can be stuffed in
> > with a 'hiding'
> > style, at the foot of the page as a footnote, or .. we didn't get
> > that far.
> We should make a final decision on how to do the text equivalent.
>
> > What we didn't talk about is the relationship between this
> > description and any other
> > descriptions.  If the author has already supplied a description of
> > the mathematical
> > expression (mathematically correct term v. 'equation') the helper's
> > version should
> > parallel and not obliterate it.  So I was thinking we should tell the
> > helper to add
> > the ID for its description at the front of the list of IDs that
> > appear in the
> > @describedby attribute, if it already exists.  create one if not
> > already existing.
> A description is different from an accessible name. An accessible name
> means, this is the text for this. A description is additional information.
> So this is a misuse of the description field, which will burn us when the
> math equation really does need a description, e.g. "This is the Pythagorean
> thereom invented in XXX BC by Pythagorus. He discovered it when blah blah."


I don't know enough about the intent of the various fields to say which
field (if any) is the right one to use for a speech string.  They all seem
to have some drawbacks.  I hope though that I've outlined the options for
math accessibility clearly enough that the experts can make a good decision.

>
>
> >
> >
> > > Also I don't think we should mention speech, because this is for
> > > conversion to any accessible format -- could also be various types
> > > of Braille, Gardner-style math, etc.
> >
> > The destination modality is very important in that the text the
> > helper generates is
> > very different if German Math Braille is desired or if German speech
> > is desired.
> > That's for the 'helper' API to communicate from AT to helper in the
> > near term,
> > migrating to the helper using the DCCI information in the future.
> That's why we need to separate the model from view.  The author should
> supply the model. The AT can translate that into any view it likes.
>
> >
> > But yes, the pattern in the markup is the same; the speech/braille/
> > etc. destination
> > format is out-of-band w.r.t. the markup.  The markup just has a place
> > to put
> > "the desired text as produced by the AT-helper module".
> The author needs to deal with each modality that the math might be
> presented in?


As outlined above, it is the javascript (or other technology) that deals
with the modality options.

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






>
>
> >
> >
> > > This is for sections that represent math, such as images and ASCII
> > > art, but are not in a formal mathematical language. Such images
> > > MUST be labeled by text that can be converted to an accessible
> > > format, using the describedby property with a reference to a
> > > description of the math expression as it would be spoken. This is
> > > designed to facilitate conversion to speech. The text description
> > > should have no special markup used to control a speech device.
> > > Authors MAY store image alternative text in the image formats
> > > themselves. In these scenarios the alternative text from the image
> > > SHOULD also be brought into the text of the document and referenced
> > > by the describedby property.
> > >
> > > - Aaron
> > >
> > >
> > >
> > >
> > > "Gregory J. Rosmaita" <unagi69@concentric.net>
> > > Sent by: w3c-wai-pf-request@w3.org
> > > 04/01/2008 12:03 AM
> > >
> > > Please respond to
> > > unagi69@concentric.net
> > >
> > >
> > > To
> > > <wai-xtech@w3.org>
> > > cc
> > > <w3c-wai-pf@w3.org>
> > > Subject
> > > math role for ARIA - ARIA Subteam Public Meeting Minutes 2008-03-31
> > > [DRAFT]
> > >
> > >
> > >
> > >
> > >
> > >
> > > aloha!
> > >
> > > todays' ARIA Subteam meeting was held in a public channel to
> > > accomodate
> > > collaborators who are not part of the working group, therefore, the
> > > minutes from today's ARIA Subteam meeting are (a) public and (b)
> > > can be
> > > found at:
> > >
> > > http://www.w3.org/2008/03/31-aria-math-minutes.html
> > >
> > > and as plain text following my signature; the accompanying IRC log
> > > can be
> > > accessed via:
> > >
> > > http://www.w3.org/2008/03/31-aria-math-irc
> > >
> > > as usual, please log any errors, omissions, mis-attributions and
> > > mistakes
> > > by replying-to this post on-list
> > >
> > > special thanks to neil soiffer for the time he has spent developing
> > > and
> > > discussing a math role for ARIA (within PF and the MathML WG) and
> > > for his
> > > participation in an hour-and-a-half call today, as well as his
> > > offer to
> > > continue collaboration with the PF WG on the math role and the Best
> > > Practices for using the math role...  thanks as well to pete brunet of
> > > IBM, for joining to provide insight into IAccessible2 -- the group
> > > looks
> > > forward to working with both neil and pete as it moves forward towards
> > > completion...
> > >
> > > for background, the term "Expert Handlers" in relation to work being
> > > conducted by the Open Accessibility Workgroup, can be more fully
> > > explored
> > > by consulting the use cases document for "Expert Handlers for
> > > Specialized
> > > markup" discussed during today's call:
> > >
> > > http://a11y.org/uuc
> > >
> > > please also take the time to review the accompanying "Strageties,
> > > Comments
> > > & Reviews" wiki page, located at:
> > >
> > > http://www.linux-foundation.org/en/Accessibility/Handlers/UseCases/
> > > Unified/ScratchPad
> > >
> > > gregory.
> > >
> > >                                   - DRAFT -
> > >
> > >                            ARIA discussion of Math
> > >
> > > 31 Mar 2008
> > >
> > >   Agenda
> > >   [http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JanMar/
> > > 0547.html]
> > >
> > >   See also: IRC log [http://www.w3.org/2008/03/31-aria-math-irc]
> > >
> > > Attendees
> > >
> > >   Present
> > >          Al_Gilman, Gregory_Rosmaita, James_Nurthen, Jon_Gunderson,
> > >          Lisa_Pappas, Michael_Cooper, Neil_Soiffer, Pete_Brunet,
> > >          Rich_Schwerdtfeger, Kenny_Johar, Marc_Silbey, Matt_May
> > >
> > >   Regrets
> > >          Janina_Sajka, Sally_Cain
> > >
> > >   Chair
> > >          Rich_Schwerdtfeger
> > >
> > >   Scribe
> > >          oedipus, Gregory_Rosmaita
> > >
> > > Contents
> > >
> > >     * Topics
> > >         1. math role for ARIA 1.0
> > >     * Summary of Action Items
> > >     _________________________________________________________________
> > >
> > >
> > >
> > >   <Rich> scribe: oedipus
> > >
> > >   <Rich> last irc discussion thread on math:
> > >   http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JanMar/0453.html
> > >
> > >   <MichaelC> Agenda:
> > >   http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JanMar/0547.html
> > >   (first item only)
> > >
> > >   <scribe> scribe: Gregory_Rosmaita
> > >
> > >   <scribe> scribeNick: oedipus
> > >
> > > math role for ARIA 1.0
> > >
> > >   RS: trying to get your math request added to aria; think is great
> > >   thing to add; want to 1) meet your needs and 2) provide best
> > > practices
> > >   for embedding math
> > >   ... last thread in IRC
> > >
> > >   <Rich>
> > >   http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JanMar/0453.html
> > >
> > >   AG: 19 March 2008 -- you replied, but bunch of technical details
> > >
> > >   RS: new math role -- what does it mean? how to use? how to reuse ALT
> > >   text? how to handle images?
> > >
> > >   NS: brought up with MathML WG -- asked if had comments; some of
> > > things
> > >   we discussed in PF email exchange came up -- restrictions on what
> > > type
> > >   of math should be placed in a math role; MathML WG felt that a
> > > lot of
> > >   stuff out, for past compatibility not good to abandon what is being
> > >   done today and historically -- mix of TeX and MathML
> > >   ... none of them are tagged identifying what they are; existing
> > >   practice wide-open and that needs to stop
> > >   ... sniffer trying to find math will be able to tell TeX, MathML, or
> > >   similar syntax
> > >   ... leave open-ended and not specify
> > >   ... second: subtype "math-tex" -- discarded as bad idea -- to
> > >   ambigous; too many TeX variants
> > >   ... third issue: if math, might not be any alt text in suitable
> > >   format, but down the road one could use OCR to pull equation from
> > >   image -- already an OCR for math with acuracy in 97% range;
> > > again, not
> > >   tagged, but open ended
> > >   ... fourth: didn't care where it is -- BP can say "use alt text
> > > or use
> > >   image" but one kind of math out there is JSMath -- uses TeX-like
> > > base
> > >   to create javascripted (inaccessible) math
> > >   ... don't want to force math into an image that has to be parsed
> > >   ... no single practice -- math kind of a "wild west" frontier trying
> > >   to get integrated into HTML
> > >
> > >   RS: what does having role="math" help with all formats?
> > >
> > >   NS: key thing which will allow anyone to do a11y -- 1) given cost of
> > >   trying to discover math, having tag iding as math, keys a
> > >   sniffer/handler to find and discover format; second) alerts AT that
> > >   this is Math and calls a handler to come up with text to speak it,
> > >   rather than gibberish
> > >
> > >   we are in #aria-math for math discussion
> > >
> > >   switch to #aria-math
> > >
> > >   NS: MathML WG felt that using attribute value "math" too general
> > >   (plot, diagram, formula) want to restrict it more -- suggested
> > >   "formula" or MSAAEquation
> > >
> > >   AG: MSAAEquation was the suggestion
> > >
> > >   RS: if prefer math, can in API mapping documents map to
> > >   role="equation"
> > >
> > >   NS: not as picky as rest of wg, but thought "equation" restricted it
> > >   and was more precise and maps well to what already exists
> > >
> > >   AG: a) have to channel simon p -- was pressuring us to have this
> > > fully
> > >   specificied -- thinking that he is building into HTML5 and
> > > browser --
> > >   challanged that -- this is a flag AT uses to call helper -- it is
> > > the
> > >   helper that decides how loose or strict it is going to be able to
> > > grok
> > >   and that above 85% success would be BIG win
> > >   ... where existing equations are in TeX can do that
> > >   ... akward thing in that HTML has history of getting into trouble
> > > with
> > >   putting sloppy definitions in specs which lead to differing/sloppy
> > >   implementations; authos have been upset about what happens when
> > > their
> > >   code hits the browser; strong desire in HTML WG to nail things down
> > >   better and have more specific specificiation -- need to distinguish
> > >   what role is here -- HTML and base UA not going to do everything for
> > >   everyone
> > >
> > >   NS: math may be embedded in image -- may not even be perceptable to
> > >   HTML parser
> > >
> > >   AG: SimonP would want to be quick -- if you are happy to sniff/ping
> > >   inserts and give a sign "math handlers/sniffers" go find and process
> > >   this; in accessibility also have problem -- in WCAG developed
> > > concept
> > >   of accessibly supported technologies -- loose outer defninition
> > >   (function performance) then "and furthermore if use this technique
> > >   with this technology, value gets through to end user:
> > >
> > >   s/user;/user;
> > >
> > >   AG: value of "math" or "equation" is describing intent -- how you
> > >   should understand this fragment of content;
> > >   ... when tell authors what to do, need "and furthermore if you do
> > >   this, it is supported" so both a loose and a stricter statement
> > >
> > >   <kenny> michael, I am using skype for this call today.
> > >
> > >   NS: should be suggestion in Best Practices that says "this
> > > technology
> > >   will be exposed/found if you do x with y app" -- would not leave
> > > open
> > >   ended if starting from scratch, but since ARIA attempting to capture
> > >   meaning in current practice and those practices vary greately
> > >
> > >   RS: mark this as "equation" here are common BP to support
> > >   interoperability today, but is there an optional parameter for
> > >   "equation" you would want?
> > >
> > >   NS: 2 things: 1) where is the math going to be found; 2) give me a
> > >   strong clue as to what type of math i need to deal with
> > >   (self-discoverable)
> > >   ... with TeX similar, but different -- one thing not well understood
> > >   about TeX was written without logical parser -- doesn't tokenize
> > >   things but tokenizes each character
> > >   ... some variants of TeX tokenize elements; things like that make
> > > TeX
> > >   an open ended thing
> > >   ... would be nice to specify that, but 20 variantsof TeX and many
> > >   implementations follow custom rules
> > >
> > >   AG: took first pass at approach: didn't address "casting to a
> > > dialect"
> > >   but did point to where can find; put encoded math in ALT
> > > attribute one
> > >   pattern has to be looked for (proably a search list); what is new in
> > >   ARIA is "describedby" points to something for people or machines --
> > >   could point to a machine understandable -- could develop conventions
> > >   for TeX -- ways to put into meta data (use SCRIPT that not
> > > displayed,
> > >   ask what type of script, get return) -- hav
> > >
> > >   RS: describedby like a long desc for area in document
> > >   ... can hide with CSS or have visible; gets mapped to accessible
> > >   description in a11y APIs so one can extract text if needed;
> > >   ... suggestion on how to process math object? OCR it, use
> > > description
> > >   (describedby)
> > >   ... can't specify TeX because too many variants
> > >
> > >   NS: right
> > >   ... question i have which hasn't been answered by PF is "how
> > > important
> > >   is compatibility with existing use cases?" -- is goal of ARIA to
> > >   change and constrain use of math to make more accessible or just
> > >   trying to describe current usage
> > >
> > >   RS: ARIA about interoperability with platform a11y APIs --
> > > everything
> > >   needs to be obtained through APIs; could say, if use ARIA, this
> > > is how
> > >   you should use it for math -- if in best interest of industry -- use
> > >   of ARIA might direct them to a more consistent use of math on web
> > >
> > >   NS: driving factor on some, but not all, putting math in HTML is
> > >   terseness; some use TeX-like notation that uses javascript to
> > >   "prettify" -- wikipedia/wikimedia has extension that creates TeX
> > > from
> > >   ascii notation or to describe image containing math
> > >   ... JSMath -- if javascript really doing writing, could put out more
> > >   description
> > >   ... maybe verbosity is not an issue on second thought -- tool will
> > >   generate extra stuff
> > >
> > >   AG: wikipedia case where site doing patern driven transform is good
> > >   likelihood of uptake thing -- getting JSMath library to generate
> > > more
> > >   stuff would rate down
> > >
> > >   NS: working with us
> > >
> > >   AG: maybe will work with us like dojo
> > >   ... everyone in end cares about character count -- not just mobile
> > >   providers; wasted chars not good idea -- if put TeX in alt and mark
> > >   with role then should work -- content devlopers who want to put in
> > >   different flavors of TeX, that we have the "try harder" coding
> > >   patterns we target for when more than just an image and alt text
> > >
> > >   JRG: ideally what is most accesible way to put math on web
> > >
> > >   NS: MathML -- works with XHTML no problem, but problem with HTML
> > > -- if
> > >   you only use IE, can put in HTML document and IE extention mechanism
> > >   will handle it, but nothing in firefox or safari
> > >
> > >   RS: role="equation" - source equals "URI for mathML" and let AT suck
> > >   it out
> > >
> > >   NS: URIs have 2000 character limits?
> > >
> > >   AG: good question
> > >
> > >   RS: here is URI for source of that, don't need alt text -- if you
> > >   understand MathML go get it
> > >
> > >   AG: problem when src used to point to math image
> > >
> > >   RS: can handle that
> > >
> > >   AG: HLink versus XLink wars
> > >
> > >   NS: essentially 1 thing saying let's make it explicit and put on
> > > image
> > >   or embed tag -- MathML WG trying to make math more interoperable --
> > >   people carry around images, but leave alt text behind; embedding in
> > >   image safe way to go -- always there
> > >   ... extractable from image, not dependent on alt -- TeX part of
> > > image
> > >   ... not bad idea to have attribute that make these things
> > > obvious, but
> > >   worry about fragility of extraction method
> > >
> > >   RS: like to have 2 vehicles in BP: role="equation" -- in BP say
> > > "store
> > >   equivalent text in image"
> > >
> > >   NS: here are 3 or 4 ways that are supported by most extraction techs
> > >   ... 1 would be ALT text (current practice); other would be using
> > >   "describedby" and other in image itself
> > >
> > >   RS: no URL to mathml equiv
> > >
> > >   NS: not sure
> > >
> > >   AG: should be supported
> > >
> > >   GJR: strong plus one
> > >
> > >   AG: if provider has equation in MathML, need to know -- want to use
> > >   that if present
> > >
> > >   RS: mathML equiv to give URL (optional parameter)
> > >
> > >   NS: why just MathML? if to make discovery easy, shouldn't be limited
> > >   to MathML -- just URL of equivalent
> > >
> > >   RS: server could tell media type when pull down TeX
> > >
> > >   NS: is a text format
> > >
> > >   MC: datatype or new mime-type property?
> > >
> > >   AG: has to be tested to make sure current implementations of OBJECT
> > >   won't break; if put in OBJECT and make MathML first choice, that is
> > >   the Best Practice possible; problem is whith mime-types for MathML
> > >
> > >   NS: persued and rejected by MathML WG
> > >
> > >   AG: problem: UA can't determine ahead of time if can process
> > > MathML --
> > >   doesn't know MathML is MathML until gets it
> > >
> > >   RS: right
> > >
> > >   NS: sigh, right
> > >   ... though OBJECT has own problems
> > >
> > >   AG: matter of debate -- tantek told us it has been fixed; HTML5
> > >   faction against it (VIDEO, AUDIO, etc.) -- shouldn't lose cascading
> > >   fallback idea; want to wait to have highest and best form avialable
> > >   ... issues: need mime-type identifier; need extractor for TeX in
> > > image
> > >
> > >   <kenny> Do we know if any screen readers today support LaTex?
> > >
> > >   MC: putting mathML in attributes means using escape characters
> > >
> > >   AG: TeX in alt rather than MathML
> > >
> > >   <kenny> Thanks gregory.
> > >
> > >   AG: if load into IFRAME, how is communicated to UA that this thing
> > >   contains math -- application/xml+mathml -- if can't process XML move
> > >   onto something else
> > >
> > >   NS: not going to work right now
> > >
> > >   GJR: MC can WCAG2 address the author's best practice by advising
> > > that
> > >   TeX be embeded in an image
> > >
> > >   AG: interim technique; also want to fix the web so highest and best
> > >   math (MathML) can be documented as object and served to users
> > >
> > >   NS: MathML in HTML5 -- consensus that math will be in HTML5 --
> > >   probably MathML in some as yet unkown/specified form
> > >   ... want to discourage hacks
> > >
> > >   AG: agree -- just trying to separate 2 issues: need role now so
> > >   something can be processed and
> > >
> > >   GJR: need to take info to WCAG and ATAG
> > >
> > >   RS: if alt text not in document, are you going to pull alt text
> > > out of
> > >   image and map to a11y api?
> > >
> > >   NS: don't think UA itself would do sniffing (although would be great
> > >   if would) -- UA's not the ones that turn MathML into speech, AT
> > >   vendors don't want to handle MathML directly, so would have to use
> > >   Expert Handler (http://a11y.org/handlers) -- there is pllugin for IE
> > >   that allows speech -- AT essential to getting braille support
> > >   ... developed tech to go out and pull the alt text out, paste into
> > >   equation editor; port that back into viewer -- take the TeX
> > > translate
> > >   to MathML then run through MathML to Speech and MahtML to braille
> > >   engines -- very doable; current limitation -- plugin calls for
> > > MathML
> > >   and need to do javascript on imagesand scan of page to determine
> > > what
> > >   math is there in what form
> > >   ... if have role="math" could limit search
> > >
> > >   AG: summarize: if the user has a png format for their picture of
> > >   equation and put embedded meta-data in png, not expect browser to
> > > put
> > >   into API as accessible description -- can take alt text and
> > > processed
> > >   as usual; if mathML in embedded, math helper might write good
> > >   description into accessibility API
> > >
> > >   NS: ARIA exported to AT, javascript that binds will do
> > > translation and
> > >   in case of UAs not serving up dom, can rewrite page AT should
> > > pick up
> > >   ... alt text put out as value field in MSAA?
> > >
> > >   RS: no, AccessibleName and helpInformation -- MSAA has
> > > description API
> > >   (equiv of help) IA2 has relationships that understand "describedby";
> > >   don't know what UIAutomation plans
> > >
> > >   NS: whatever written, write correctly, even if in alt
> > >
> > >   RS: wearing AT vendor hat, if TeX embedded in image, would want to
> > >   know that if don't have TeX plugin
> > >
> > >   NS: what is loud and clear from AT vendors is "we're not dealing
> > > with
> > >   math; you do that, tell us what to put out, and we'll support it"
> > > not
> > >   going to search DOM, will speak if is there -- don't want to fetch
> > >   image and parse it
> > >
> > >   RS: 2 things: 1) either can put a describedby as technique or a tool
> > >   can fulfill that role; 2) HTML5 people will not like URL pointing
> > >
> > >   NS: HTML5 people will tell you that they will handle math as text/
> > > html
> > >   -- dubious at this point if possible
> > >   ... describedby field in TeX or MathML -- if had javascript that
> > > looks
> > >   for math and outputs speech, is it still "describedby"?
> > >
> > >   AG: describedby takes list of IDs -- have to revisit what UAs do
> > > with
> > >   concatonated methods
> > >   ... can't do this on fly, but are things can write into DOM that can
> > >   capture (SSML)
> > >
> > >   NS: with MSAA can't use SSML, have to use straight text
> > >   ... as long as you come up with soulition that describedby is
> > > machine
> > >   field, need to id field that needs priority to generate speech,
> > >   braille, etc.
> > >
> > >   AG: hoemwork item, but this discussion has GREATLY cleared up the
> > >   issues; thought going to take directoy to APIs -- if put back into
> > >   DOM, have to rethink thorugh fully so AT ends up with it
> > >
> > >   NS: found varying levels of commitment from AT vendors: base level -
> > >   have MSAA interface, but that is limited to string of text (can't
> > > put
> > >   braille in that -- text you put in isn't braille you get out in
> > > math)
> > >   -- that's why have to expose handler interface to all UAs all ATs
> > > all
> > >   platforms; minimum base is ability to take math code and output
> > > speech
> > >
> > >   RS: braille involves fight with AT
> > >
> > >   NS: we dont' speak things, we return text for speech and braille
> > >   engines
> > >
> > >   AG: take back to ATs -- knee-jerk reaction is that that is part of
> > >   procedure call on dispatching expert handler -- should know if have
> > >   braille device and follow user's preference; Fluid Project
> > > beating on
> > >   W3C elsewhere, so will be a W3C user prefernces in context that
> > > can be
> > >   exposed
> > >
> > >   RS: don't want future equivalent for MathML
> > >   ... "equation" or "math"
> > >
> > >   LP: preference for math -- it's shorter
> > >
> > >   NS: MathML prefered equation, personally don't care
> > >
> > >   AG: can live with either -- math good idea now -- authors will
> > > relate
> > >   better to math - will think equation doesn't always apply
> > >
> > >   RS: can say in description "this is a math equation"
> > >
> > >   NS: not equations, expressions, but...
> > >
> > >   RS: math expression in definition
> > >
> > >   <Al> +1
> > >
> > >   +1
> > >
> > >   <Rich> +1
> > >
> > >   <kenny> +1
> > >
> > >   LP +1
> > >
> > >   <Jon> +1
> > >
> > >   raman gave +1 to "math" on list
> > >
> > >   RESOLUTION: ARIA will use math role type; in definition will state
> > >   that this is a "math expression"
> > >
> > >   rssagent make minutes
> > >
> > >   RS: describedby a universal property, right?
> > >
> > >   MC: yes
> > >
> > >   RS: don't have to say antyhing explicit in spec about math, but a BP
> > >   thing; have to compose best practices section 1) alternative text
> > >   embedded in image, third party app extracts info and load
> > >   "describedby" with that info, or may speak, or author may but in
> > >   "describedby" himslef
> > >
> > >   NS: describedby -- words to speak or what should be written into DOM
> > >   using existing API bindings
> > >
> > >   AG: need to get AaronL (mozilla) and SimonP (opera) in on this
> > >
> > >   RS: best way to speak it (as long as not changing voice dynamics) ==
> > >   that way AT doesn't have to think alot to deliver to TTS or braille
> > >   device
> > >
> > >   NS: machine encoding shouldn't be part of "describedby"
> > >
> > >   AG: how does API binding respect cascade of acceptable forms
> > >
> > >   NS: someone could manually use field -- need to know if field exists
> > >
> > >   AG: action/homework item: UA best practice for AT helper (expert
> > >   handler -- if writes back into DOM, how to do it)
> > >   ... need browser brothers to address this
> > >
> > >   RS: if start putting other markup in there, going to go bonkers
> > >
> > >   AG: are we going to say if TeX in image and can figure how to say
> > > that
> > >   can overwrite ALT and go with that -- haven't been considering that
> > >   piece of problem
> > >
> > >   NS: 2 ways: 1) we say "override ALT or describedby" and put in
> > >   description AT can pick up: 2) tighter binding -- id as Math -- call
> > >   expert handler, and that will tell us what to say -- that fall back
> > >   position is needed -- may be rewriting ALT or describedby -- should
> > >   process, put back into DOM
> > >
> > >   AG: for PF, in terms of browsers binding DOM to API, much plainer if
> > >   return to AT that called handler than figuring out override; don't
> > >   want to overwrite something suitable to speak that is only
> > > handled by
> > >   handler; handler api has to return best advoice on how to speak or
> > >   braille expression
> > >
> > >   RS: what is best practice: how does an AT know that an expert
> > >   handler/plugin (MathPlayer - works only in IE)
> > >
> > >   NS: have to work with each AT vendor to tell them "when you get to
> > >   this node, use our interfaces" when you get to our interface, then
> > >   speak, highlight, braille-output
> > >   ... plug-in a dll that gets into registry
> > >   ... want standard way that says "here is how you work with expert
> > >   handler" rather than one-off solutions
> > >
> > >   AG: browsers look like going to implement ARIA, will be
> > > refelected in
> > >   accessibleRole in API -- if use a11y API can bootstrap off of that,
> > >   determine if math and then ask for help
> > >
> > >   RS: preferential way to look at describedby or alt -- that would be
> > >   what is to be spoken
> > >
> > >   NS: JavaScript solution is a cross-platform base fallback -- can't
> > >   give highlighting or braille currnetly; if could write SSML into
> > > math
> > >   speech, would be much better, but if stuck with plain text, fake it
> > >   with commas and periods and other klduges
> > >
> > >   AG: small SSML implementations not available yet
> > >
> > >   RS: if use describedby method should be processable in speech
> > >
> > >   NS: exactly what i did with MSAA/SAPI5 -- value field with plain
> > > text
> > >   ... like RS' solution
> > >
> > >   RS: need to put something in best practices -- don't need to do
> > >   anything special with UA devs
> > >
> > >   AG: have in our vocab "valuetext" -- if make "valuetext" apply to
> > > math
> > >   role, have place to stuff it
> > >
> > >   RS: [ponders] --
> > >
> > >   NS: can it be a long string?
> > >
> > >   RS: yes
> > >   ... currently valuetext associated with valuemax valuemin etc.
> > >
> > >   AG: document has tools to deal with it attribute by attribute --
> > > math
> > >   role has this property: "valuetext" defaults to how to say, can also
> > >   put in how to braille
> > >
> > >   RS: in HTML what is maximum lenght of string
> > >
> > >   AG: have to look for it
> > >   ... generic limit on strings 255
> > >
> > >   MC: anything directed towards human should be in an element
> > >
> > >   RS: between 2 tags can be as long as want
> > >
> > >   AG: that points to describedby over valuetext -- problem: have to
> > > work
> > >   with AT so that role="math" goies straight to describedby and prcess
> > >   it in its entirety
> > >
> > >   RS: think have enought to write something up
> > >
> > >   ACTION ARIA Editors: write up proposal for role="math" and best
> > >   practices for its use
> > >
> > >   <kenny> bye
> > >
> > >   NS: happy to participate as needed
> > >
> > > Summary of Action Items
> > >
> > >   [End of minutes]
> > >
> > > --------------------------------------------------------------
> > > You cannot depend on your eyes when your imagination is out of
> > > focus.                                           -- Mark Twain
> > > --------------------------------------------------------------
> > > Gregory J. Rosmaita: unagi69@concentric.net
> > >   Camera Obscura: http://www.hicom.net/~oedipus/<http://www.hicom.net/%7Eoedipus/>
> > >          Oedipus' Online Complex: http://my.opera.com/oedipus
> > > --------------------------------------------------------------
> > >
> > >
> >
>