- From: Romain <rdeltour@gmail.com>
- Date: Tue, 4 Oct 2016 17:18:41 +0200
- To: Florian Rivoal <florian@rivoal.net>
- Cc: Ivan Herman <ivan@w3.org>, Paul Topping <pault@dessci.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Avneesh Singh <avneesh.sg@gmail.com>, "www-style@w3.org" <www-style@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Peter Krautzberger <peter.krautzberger@mathjax.org>
> On 04 Oct 2016, at 16:33, Florian Rivoal <florian@rivoal.net> wrote: > > >> On Oct 4, 2016, at 12:59, Ivan Herman <ivan@w3.org> wrote: >> >> if the browser does include a MathML renderer, this is what one would want to use, otherwise (as a fallback) an image. How to put both formats into the code and ensure that what gets displayed is the optimal one for that specific environment? How to avoid that, for example, *both* the mathml content and the corresponding jpg image gets displayed? Or none of the two? (Alas!, the fallback image approach within MathML does not work; browsers that ignore MathML also ignore that feature as well.) > > That was the case that was presented to the CSSWG, and let to the initial adoption of the proposal. However, it was later commented that: > > - Even if the browser includes a MathML renderer, you may not way to use it, as it is neither ideal for accessibility (because markup is not semantic), nor is it reliable for presentation > > - Fallbacks can be better than images. ARIA annotated HTML or SVG can both be accessible and visually good representations. And given that they are, it isn't clear why they should be used as fallbacks instead of as the preferred rendering. > > - If the accessibility of MathML is judged good enough, it can be included in the markup and styled to be visually hidden (off screen, transparent...) and be used simultaneously with the image/SVG/HTML visual rendering (See Robin's mail). > > This means that the MQ might not be used even if it was there, and that there are alternative ways to produce accessible and visually appealing math. So that's why the action to spec the MQ was put on hold. For the record, the above is a pretty good summary of my recollections of the ad-hoc meeting we had at TPAC. Also, we have to keep in mind that this whole discussion essentially started when we started writing the EPUB Accessibility Guidelines document, which is a very pragmatic document, with a flexible editing process (as in "not REC track"). For the needs of this document, I believe that a workaround solution –along the lines of the one presented in Robin's email and Mark's proposal– would be a good realistic guideline for the short term. That shouldn't prevent people working on a better longer term solution, but this would likely not involve MQs, and not be in the sole scope of the DPUB IG or CSS WG. Romain. [1] https://rawgit.com/mhakkinen/extdesc/master/Extended-desc.md.html > > - Florian
Received on Tuesday, 4 October 2016 15:19:19 UTC