W3C home > Mailing lists > Public > public-digipub-ig@w3.org > August 2015

Re: [Moderator Action] RE: Active lobbying: Math

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 25 Aug 2015 06:29:34 -0600
To: "Robin Berjon" <robin@w3.org>
Message-ID: <48A243EE-3788-46F3-99C5-4A830AAA5522@us.ibm.com>
Cc: "Peter Krautzberger" <peter.krautzberger@mathjax.org>, "W3C Digital Publishing IG" <public-digipub-ig@w3.org>

Robin,

ARIA 1.0 was done to address the accessibility of Rich Internet
Application. Although we are working on a 1.1 to address gaps for that type
of content in 1.0, we now have an extension process. We have expanded to
create modules for book digital publishing semantics and also graphics. So,
if you look at the creation off multiple semantic taxonomies we have only
scratched the surface. Math is an obvious essential next step for ARIA.
Unfortunately, our charter is being held in limbo right now by some AC
members. This is also holding up ARIA extensions for web components. I hope
it gets resolved soon. The extension process was put in place so that work
on new modules could start without making the ARIA working group main body
a bottle neck to innovation in new taxonomies like Math.

If we are to do an ARIA module for Math it would require a joint task force
between the new ARIA working group and I think the Math WG with additional
invited experts of course. We would need MathJax people to participate or
even lead the effort. Other than having the new charter approved and
committed people I don't see why this work could not start.

I would argue that the accessibility of digital math is one of the most
important things we should be doing at W3C. It just has not gotten the due
attention. An ARIA module would facilitate multimodal access to Math which
has proven to grow math comprehension for all users by roughly 10 percent.

Rich

Sent from my iPad

> On Aug 25, 2015, at 4:22 AM, Robin Berjon <robin@w3.org> wrote:
>
> On 24/08/2015 21:47 , Peter Krautzberger wrote:
> > I think the main problem is that nobody really knows what it would
> > technically require to implement good math layout in browser engines or
> > what it would take to implement good MathML support.
>
> Nobody might be stretching it, but it's certainly a very small group.
>
> > * In my experience, both browser vendors, publisher, and third party
> > vendors have surprisingly little knowledge of
> >    * MathML as a markup language
> >    * math layout in general
> >    * MathML layout specifically
> >    * math layout using OWP tech
> >    * math accessibility using OWP tech
>
> Part of the problem there is that you don't just easily fall into MathML
> in an incremental manner, say by first trying to tweak the rendering of
> something perhaps even as trivial as <var>x</var> and then building up
> from there. The first step is relatively steep compared to many other
> parts of the platform.
>
> > * The ARIA spec has a massive hole where mathematics should be.
>
> Asking naïvely: is there any reason not to start fixing this right now?
>
> > * Neither browsers nor publishers are active in the MathWG (ok, maybe 1
> > exception).
> >
> > * The MathML spec needs some work in an HTML5 context
> >    * MathML has been "out of sync" (for lack of a better term) with
> > HTML/CSS/SVG for a while
> >    * MathML duplicates HTML/CSS features (sometimes the features are
not
> > compatible though never critically so imho)
> >    * MathML hides quite a few complex layout features behind math
> > syntax, complicating the implementation of both
> >    * ContentMathML has failed outside of CAS.
> >
> > Another key problem is: MathML is neither necessary nor sufficient for
> > math layout on the web. Nowadays, HTML/CSS implementations are good
> > enough for (high quality) math/MathML layout. I'm not speaking of
> > client-side JS-driven rendering but of (server-side) HTML+CSS
generation
> > that looks the same on all recent browsers.
>
> That sounds like a great opportunity and a good starting point to
> rethink MathML.
>
> Starting from HTML+CSS code that's ugly and poorly accessible, but at
> least sports high-quality layout:
>
>    • What can be added to CSS that would clean up both the style and
> markup? What parts of that could actually be useful in other context?
>
>    • What can be done to make it properly accessible, ideally built-in
> rather than bolt-on?
>
>    • What could be added to HTML to make the markup simpler and more
> semantic, possibly by importing some elements from MathML more or less
> directly, without requiring them to be in a MathML context but without
> duplicating HTML functionality?
>
> I'm repeating both myself and others, but going about this with an
> Extensible Web Manifesto spirit would surely help.
>
> And I'm sure the WICG could be a great place to entertain
> (non-monolithic) new ideas and hash them out with support from browser
> vendors.
>
> > Personally, I don't think MathML will be implemented in browsers
(though
> > I'd be extremely happy to be wrong here and will support any effort in
> > this group). I do think there are more realistic alternative goals such
> > as improving CSS implementations incrementally and developing standards
> > for exposing underlying data such as MathML to tools such as AT.
>
> +1
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
Received on Tuesday, 25 August 2015 12:30:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:08 UTC