Re: [mediaqueries] MathML

Hi Florian and all,

I second what Avneesh says.  However, I did take some notes although they are not complete as it is very hard to keep up with everyone when people talk over each other, and participating in a meeting like this ;)

Below are some notes I did take which I promised Peter, but I think what you recapped is pretty close to what I also remember from the meeting.

I also talk to a colleague Sue-Ann Ma here at Benetech who is the product manager for Math Support Finder
http://msf.mathmlcloud.org <http://msf.mathmlcloud.org/>
This work is not yet complete but so far all systems tested the visual rendering of the MathML is fine, I would be curious to see what Peter thinks of this if there are missing holes in the findings thus far which is skewing our understanding that visual MathML for the most part is good enough especially in the level of math we are talking about for K-12 publications.

---------
Rough notes from MathML in EPUB discussion Tuesday Sept 20 5PM - 5:45PM

ebook readers scripts don’t run mathml may not be supported fallback image in mathml fails

mathml and separate piece of info
and a media query to turn the right one on/off


Romain: declare media in Script
so direction to publisher include image with alt text and the alternative would be to render the mathml

AT might want to skip CSS display none (AT hides)

Alt-text for image.

css switching is ok the scripting part, why can’t the browsers support it?

if we are in an env. that support scripts

env. script where mathjax not supported and would return no.

Peter: browsers that switch that flag should switch that flag that supports it..

Either the browser supports it or the AT

Volker: will MQ override the hidden?
Peter: if JS flips the switch then the mathml will appear.

If you are in a scripting env. why can’t you just change the CSS with the script.

You can but but if you write it best one way.

as we encounter more situations like this could set a precidense.

Readium side can implement the MQ.

Romain: green light for CSS to work on spec.  who will implement in browsers?

Write community issue to support this for browsers.

George: publishers are commenting out the mathml and adding a image.
older browsers and RS that must show the image.  the math will be there and that image will be there for most of the time, but the math is there and AT could get.
HideMath visually but allow AT

add alt text to aria label with role math underneath.

display none
How would AT’s get math, they ignore role-math.
Edge only exposes AT DOM,

if publisher wants to have pixel perfect they will never want MathML since they have no control over the rendering.

MathML is in the content, couldn’t AT expose it

canvas: fallback
in canvas you have fallback but you can walk the whole DOM.
If we take a image  with fallback of mathml
Volker: we did this in chromvox looking for LATEX

MathJax use Wikipidea use server side hidden but accessibility AT

Mark: Image hide from AT aria-hidden attached to it and have visually hidden but 1 px hack.


Put mathml html attributes data-math
MQ: returns true if user says yes and there is Accessible Math (UA/AT says yes to math)

AT’s do they JS style access or some sort of Private Browser level.

Some AT’s have do this.  Some AT’s won’t do this.
external AT crawl things themselves could be real JS API available.
otherwise Browsers should have access to AT api to turn on/off math

(Unfortunately this is where I stopped and got more involved in the discussion)

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



> On Oct 3, 2016, at 4:52 AM, Avneesh Singh <avneesh.sg@gmail.com> wrote:
> 
> Hi Florian,
> 
> Firstly I will like to thank you for giving the MathML issue such a good attention.
> 
> There were many insights provided by the group in the informal meeting at the end of the day. Some points that influenced the direction include.
> - MQ idea is based on the assumption that browsers will provide perfect visual appeal of MathML. But, right now browsers do not do so.
> - All assistive technologies will support MathML. Many assistive technologies support MathML right now, but as per the discussions in TPAC, all of them are not perfect.
> 
> This is why the discussion led towards the variant of MQ> Copying the section from your email:
> "A variant of the MQ was proposed. It would instead mean that MathML was supported AND that the user expressed explicit preference for MathML content (via a setting of some kind). This would be useful in an accessibility context for users who know the strengths and limitations of their environment, and based on that make a judgment call that a MathML rendition would serve them best. While this MQ wouldn't be wrong or harmful, it doesn't really change the fact that MathML is not great for accessibility and that there are better alternatives, and that implementations and integration with screen readers are not great either, so it would not be terribly useful."
> 
> We have not defined this variant of MQ yet, but some of the facts that support it are:
> - Publishers are already using MathML in their production workflow. But they have to comment it due to lack of support on consumption side. so, MathML is already available.
> - JAWS and NVDA, the two most popular Windows screen readers support MathML. It is also supported by Voiceover, but I remember the statement from Peter that support in Voiceover is not up to the mark. So, assistive technology support MathML. It would need some more refinements, but the support is there.
> - The variant of MQ also give an option to fall back to alttext if the assistive technology does not support MathML.
> 
> We are carrying on the work of finding the right solution in EPUB accessibility group, and we are optimistic that we will have a solution to share with you.
> 
> With regards
> Avneesh
> -----Original Message----- From: Florian Rivoal
> Sent: Monday, October 3, 2016 08:17
> To: www-style list ; W3C Digital Publishing IG
> Cc: Peter Krautzberger
> Subject: [mediaqueries] MathML
> 
> During TPAC at the join session between the CSSWG and the DPUB-IG, I was actioned to write the specification for a media query indicating support for MathML.
> 
> This was based on a statement from the DPUB group that such an MQ would be useful in addressing a number of epub/publication related use cases. The central thesis being that without such an MQ, and in environments where JS cannot be counted on, there was no good way to provide fallback content for MathML, and that therefore content authors simply defaulted to providing the fallback only (typically an image), without including the MathML at all.
> 
> During an ad-hoc (and unfortunately not minuted) follow up session at the end of the day attended by a few math and dpub people, as well as Tab and I on the CSSWG side, it became clear that there wasn't actually a consensus that this MQ would be useful.
> 
> Peter Krautzberger (CCed) has written his take on this here https://www.peterkrautzberger.org/0190/.
> 
> My understanding of what was said in that session is:
> 
> - MathML implementations vary significantly in quality and in their coverage of the specification. Having such an MQ would allow filtering out UAs that don't support MathML at all, but would not change the fact that those who do don't do it well enough.
> 
> - Even though MathML is markup, and therefore more amenable to support by screenreaders than plain images, it is not actually a good format for accessibility purposes, and screen reader integration is not that good either. Alternatives such as HTML or SVG representations of the content with sufficient ARIA annotations can give better results.
> 
> - MathML has been stagnating for a long time, and implementations do not seem to be making much progress. There is no reason to believe that implementations (either visual or screen readers) will improve sufficiently any time soon (or ever) to make the previous two problems go away.
> 
> - While a number of publishers do express the desire to use MathML in production and would welcome the help of such an MQ for doing that, most of those who have actually tried to use MathML in production give up after testing shows that neither the presentation nor the accessibility is up to their expectations, and therefore go back to publishing math in some other form (images, svg...).
> 
> - MathJax, while itself incomplete, seems to be the only MathML implementation people are willy to rely on for production content. While the MQ with the proposed API would enable detection of math support either natively or by script, if the only usable environment is the script based one, the MQ is not needed.
> 
> - A variant of the MQ was proposed. It would instead mean that MathML was supported AND that the user expressed explicit preference for MathML content (via a setting of some kind). This would be useful in an accessibility context for users who know the strengths and limitations of their environment, and based on that make a judgment call that a MathML rendition would serve them best. While this MQ wouldn't be wrong or harmful, it doesn't really change the fact that MathML is not great for accessibility and that there are better alternatives, and that implementations and integration with screen readers are not great either, so it would not be terribly useful.
> 
> I do not know nearly enough about MathML, Aria, accessibility or publishing to be a good judge the validity of these various statements, but they were made by people who, like Peter, should know what they are talking about. My conclusion is at the very least that there is not a clear consensus in the Math/publishing community about whether this MQ is a good idea.
> 
> Because of this, I do not plan to write the specification for this MQ for now. I encourage people who still think it is a good idea to talk to people who think it is not (Peter is probably a good representative of that position). Convincing Peter is not a prerequisite for putting this MQ back on track for standardization, but coming up with good counterpoints to his arguments probably is.
> 
> Detailed example uses (here is the markup, here is the CSS, here is kind of user would benefit, here is an environment where it would produce useful results, here is why this is better than alternative approaches) would also be very much appreciated.
> 
> - Florian
>