RE: Math role edits (Was: MathML - and action 1494.)

+1.

I will be sending notes to some browser manufacturers to see about getting
broader support for MathML per today's ARIA call. I am looking up the
mathml drawing tool from IDEAL GROUP. It may not be on the Google play
store yet. I saw it at CSUN.

Rich


Rich Schwerdtfeger



From: "John Foliot" <john@foliot.ca>
To: "'James Craig'" <jcraig@apple.com>, "'PF'" <public-pfwg@w3.org>
Cc: "'Michael Cooper'" <cooper@w3.org>, <janina@rednote.net>,
            Richard Schwerdtfeger/Austin/IBM@IBMUS, "'Greg Kraus'"
            <gdkraus@ncsu.edu>, "'Sean J Keegan'" <skeegan@stanford.edu>
Date: 08/11/2014 01:45 PM
Subject: RE: Math role edits (Was: MathML - and action 1494.)



Hi James,

This looks good, and addresses my concerns. Thanks!

JF

From: James Craig [mailto:jcraig@apple.com]
Sent: Monday, August 11, 2014 11:38 AM
To: PF
Cc: Michael Cooper; janina@rednote.net; Richard Schwerdtfeger; John Foliot;
Greg Kraus; Sean J Keegan
Subject: Math role edits (Was: MathML - and action 1494.)

Here's the informative note I wrote for Action-1494. Any concerns,
objections, or suggestions?

      NOTE
      Browsers that support native implementations of MathML are able to
      provide a more robust, accessible math experience than can be
      accomplished with plain text approximations of math. Some rendering
      engines have close integration with screen readers that allow spacial
      touch exploration of the formula and refreshable braille display
      output in the Nemeth Braille format. This level of integration is not
      supported with images of mathematical formulas, even if the author
      provides a plain text approximation.
      At the time of this writing, some mainstream browsers do not support
      MathML natively, and must be retrofit using a JavaScript polyfill
      library. When authoring math content, use native MathML wherever
      possible, and test thoroughly. Use a polyfill library or provide a
      fallback image with a text alternative approximation if necessary.

In order to address additional comments from Rich and others, I massaged
some of the ARIA 1.0 text as well. For example, it now mentions "native
implementations and polyfill libraries" instead of indicating math would
rely on a "plug-in."

http://rawgit.com/w3c/aria/master/spec/aria.html#math

https://github.com/w3c/aria/commit/de79388c1cd65e2fc07d8789ae546b16f87b3df2


I don't believe the text massaging resulted in any significant normative
changes, but please review the diff or compare the current WD to the ED if
you desire. I did include a new image fallback example with some author
suggestions (a normative MAY), and an editorial note about screen reader
verbosity.
      Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula§
      If a rendering engine does not support a native math format such as
      MathML, authors may use JavaScript to downgrade the content to a
      format the browser can display, such as this HTML image using a data
      URI and plain text alternative.
      EXAMPLE 9
      <img role="math" src="..." alt="x=(−b±√(b²−4ac))÷2a">


      Editor's note: Might need an RFC-2119 "should" requirement here to
      encourage AT to speak math approximations with high punctuation
      verbosity. Otherwise ambiguous characters like a forward slash (/)
      may not be spoken even when intended to be used interchangeably with
      the division sign character (÷).

We discussed this topic in the ARIA call this morning and I believe
everyone on the call was generally in agreement. If there are concrete
concerns, please mention the relevant spec text and suggest changes where
appropriate.

Thanks,
James Craig

--
Indifference towards people and the reality in
which they live is actually the one and only
cardinal sin in design. — Dieter Rams