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

One more thing:

The spec really needs to say what format the accessible name / alt text 
will have -- otherwise it's just not useful to the implementors. Opera 
(Simon Pieters) agrees with me on this
In general we need the spec to prioritize usefulness over philosphy or we 
can make the stuff actually work. I don't care whether MathML or TeX is 
used, just say what it is.

- Aaron



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? When is description used and what should it point to?

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.

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/
          Oedipus' Online Complex: http://my.opera.com/oedipus
--------------------------------------------------------------

Received on Friday, 11 April 2008 12:13:38 UTC