Re: [mediaqueries] MathML

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

Received on Monday, 3 October 2016 12:06:38 UTC