Does the math role, as written, make sense?

[joanmarie]

The current definition of the math role states the following:

Content with the role math is intended to be marked up in an accessible format such as MathML [MathML3], or with another type of textual representation such as TeX or LaTeX, which can be converted to an accessible format by native browser implementations or a polyfill library.

Why is an ARIA role required for polyfills to work? Unless I'm missing something, it's not. Nor is it, IMHO, our job to provide a means for others to hack around lack of MathML support in user agents.

The rest of our roles (with the exception of presentation/none) do a couple of things:

• Cause the element with that role to appear in the accessibility tree
• Provide a means whereby ATs can know what something is.

I think the math role should do the above two things and only the above two things.

Over time, we may want to consider adding other math related roles (e.g. to achieve parity with MathML or the "refresh" in progress of MathML). HOWEVER, that work, if agreed upon, would fall into the 1.4 cycle. Plus, APA is currently working on knowledge domain accessibility. They may come up with some solution which we'll want to consider.

In the meantime, here is my proposal for the 1.2 cycle:

1. We remove from the spec what is currently Example 6. It's a large MathML example without an reference to ARIA other than the comment 'The math element has an implicit role="math".'
2. We replace it with some simpler example which actually uses ARIA and demonstrates how some other host language than MathML (it could be HTML, SVG, whatever) combined with the math role would make sense for authors to consider. This example should have child elements.
3. Assuming we accomplish 2, we can keep what is currently example 7, namely an img element with the math role and some alt text with a textual representation of the equation.

Thoughts?

[joanmarie]

Something I discovered as commented-out text in the ARIA spec is:

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 (÷)

That's strikes me as text which we might want in our to-be-revised definition of the math role.

[AmeliaBR]

The only way the ARIA 1 version of math (with children presentational) makes sense, to me, is as a container for an embedded object or foreign content. The content needs to be processed and presented separately from any ARIA rules. ARIA doesn't specify how that processing occurs or how the markup is translated into an accessible format. From the perspective of ARIA and the accessibility tree, it behaves something like an embedded Flash player or PDF file or something like that.

But if we're moving towards exposing MathML as a structured document, then this approach falls apart. In that case, we need a way to represent the full content in ARIA, and it may make more sense to think of role="math" as being equivalent to an HTML <code> element, establishing a context for interpreting the content (and therefore changing how punctuation might be read).

But it sounds like we're a ways away from being able to fully specify an accessible representation of MathML, so maybe it's necessary to still keep the "embedded object" interpretation for now.

For the example of an img with role="math" and a textual version of the equation as an alt, this interpretation requires a fallback accessibility behavior: If the browser doesn't have any way of parsing the content in a more advanced way, the plain text name or text content of the element is treated as the "embedded math object". That same textual fallback would also apply if the author put a math role on a span of plain text or CSS-styled HTML or SVG markup: the math role just becomes essentially a group with a special role description for whatever content would be exposed anyway.

With that approach in mind, I'd add the following clarifications:

• Remove the "or a polyfill library" from the second paragraph of the math role definition. I agree with @joanmarie that polyfills are outside the scope of ARIA. A math polyfill converts the markup to a form that the browser understands (even if that form is plain text), and then the browser applies the ARIA role to that modified DOM.

• Clarify that if the user agent doesn't recognize the element or its content as a special math markup syntax, it should treat the element with role="math" as a document structure container, exposing its accessible name if provided by the author, or its child content otherwise.

• Include the "should" for ATs being highly verbose about punctuation for plain text math content.

• Mark "children presentational" as false (as discussed in ARIA 1.1: Remove children-presentational true from math role #425), but with a note that the manner of exposing the child content will depend on whether the browser is using special rules for the content type.

• Keep the note about how MathML is preferred, but that an alternative format fallback is required for browsers without MathML support.

• Maybe add a note that non-MathML representations of equations should be written in such a way that they make sense when converted to unstyled text.

This should handle the three of the most common cases as best as possible:

• Full MathML markup (defer to the MathML accessibility handling)
• An image with a plain text alt (expose as plain text inside a container with a math role)
• A span or div with role="math" and CSS-styled content inside (expose as styled text inside a container with a math role)

Polyfills for converting MathML or Latex would still be expected to generate one of these representations. If a required polyfill doesn't run, the AT experience wouldn't be any worse than the visual experience, reading out the plain text representation from the markup.

[joanmarie]

it may make more sense to think of role="math" as being equivalent to an HTML <code> element, establishing a context for interpreting the content (and therefore changing how punctuation might be read).

This is exactly what I'm thinking.

But it sounds like we're a ways away from being able to fully specify an accessible representation of MathML, so maybe it's necessary to still keep the "embedded object" interpretation for now.

I personally don't think the status of MathML has anything to do with ARIA. Regardless, are you aware of authors or user agents that are relying upon the ARIA math role as you describe (the "embedded object" interpretation)? Or to put it a different way: Let's say during the 1.2 cycle we make the changes I propose and make math akin to the code element in functionality. What specifically would break?

[AmeliaBR]

Let's say during the 1.2 cycle we make the changes I propose and make math akin to the code element in functionality. What specifically would break?

Well, MathML would break unless you specifically allow user agents to treat MathML specially.

But for any element with role="math" that isn't MathML (or theoretically, another type of math markup that the user agent has special rules for), I think we agree: treat it as a group with a math-related role description, plus an interpretation hint which should at least require ATs to preserve punctuation (but could also trigger other math-related heuristics in pronunciation or Braille display, e.g. assuming that a hyphen-minus character is a minus instead of a hyphen).

(Sorry if my original comment was unclear. I rewrote it many times, changing my conclusions as I wrote them out.)

[joanmarie]

Well, MathML would break unless you specifically allow user agents to treat MathML specially.

How would MathML break? MathML doesn't depend on there being an ARIA math role. In fact, if the ARIA math role didn't exist, MathML would still render (or not). And it would be as accessible as it currently is.

[AmeliaBR]

In fact, if the ARIA math role didn't exist, MathML would still render (or not).

So, you're suggesting that (for now, anyway), <math> would not map to the math role, but would have its own host-language mapping that is independent of the ARIA role? That way, the ARIA role wouldn't have to handle the split between the two types of math content — it would be handled by the element role mappings?

That could probably work, so long as there was a note that browsers that do support MathML should not support any ARIA role on <math>, so that someone doesn't accidentally break the MathML accessibility if, as part of their fallback/polyfill strategy, they are using an explicit <math role="math">.

[joanmarie]

In fact, if the ARIA math role didn't exist, MathML would still render (or not).

So, you're suggesting that (for now, anyway), <math> would not map to the math role, but would have its own host-language mapping that is independent of the ARIA role?

I am most definitely not suggesting that.

Look at the mappings right now in the Core-AAM for math in the current Rec. Here's what both a math element and the math role currently cause to happen:

• MSAA/IA2 is told the container is a ROLE_SYSTEM_EQUATION. That's it.
• UIA is told the container has a Control Type of Group and a Localized Control Type of math. That's it.
• ATK/AT-SPI2 is told the container has ROLE_MATH. That's it.
• AXAPI is told the container is an AXGroup with a subrole of AXDocumentMath and a role description of 'math'. That's it.

In other words, the mappings for both the HTML element and the ARIA role boil down to "It's something mathy, ATs. Now you figure out what to do with it."

So ATs already have to look at the contents and decide if it's native MathML, or an image with some alt text (as per the existing ARIA spec example), or some divs and spans CSSed into looking like math, or an SVG, or....

So if we leave HTML-AAM as it is, and Core-AAM as it is, and make the ARIA math role work more like the code element, I'm afraid I have to ask again: What breaks?

That could probably work, so long as there was a note that browsers that do support MathML should not support any ARIA role on <math>, so that someone doesn't accidentally break the MathML accessibility if, as part of their fallback/polyfill strategy, they are using an explicit <math role="math">.

I think that duplicating the role like that is already frowned upon in some spec somewhere. I forget where now. And an author probably could come along and do something like <math role="img"> and totally break the accessibility of the native MathML. But what authors can and cannot to with respect to applying ARIA to native host languages, I believe, typically falls under the jurisdiction of those native host languages.

[AmeliaBR]

@joanmarie Ok, let's see if I can update my understanding again:

The proposal is to treat the element with a math role as a container and expose whatever is inside it according to the normal rules for the markup language.

For MathML, a <math> element is a container, "whatever is inside it" is the markup that defines the actual equation. So the math role still applies to the outer container. ARIA wouldn't define or change how that inner MathML content is exposed.

[AmeliaBR]

Going over some of @cookiecrook's concerns from #425, I see one remaining issue:

Should an aria-label or aria-labelledby on an element with role="math" replace the child content (like it would for role="button" or other children-presentation elements)?

For backwards compatibility with the ARIA 1 definition it should. But that's not consistent with other "container" roles like group or figure. And browsers are inconsistent today — whichever way you spec it, there are two implementations.

Demo using an SVG equation where the text content doesn't make sense without the drawing, but an aria-label provides a plain-text equivalent. James gave a similar example in #425 (comment), where the displayed equation used a pre-formatted ASCII rendering and the aria-label gives a linearized version. With the ARIA 1 definition, the child markup is presentational so it should be ignored anyway — only the accessible name is used. Switching to a "container" model, like figure or group, would mean that the accessible name is used as an extra label in addition to the child content. So that would be a breaking change, exposing the presentational markup as text content.

But, it's already broken today in Chrome and Firefox. They both expose the text nodes in the SVG in addition to the label on the container. In contrast, EdgeHTML and (I presume) WebKit follow the ARIA 1 spec and treat the child content as presentational.

The demo also includes an img as a heading, because I wanted to confirm that all browsers correctly handle a container role applied to an img with alt attribute. They do, exposing the image alternative text as the heading text. So, treating a math as a container role shouldn't change the accessibility of equations represented as image elements with plain text alternatives in the alt.

The final test in that demo is a div with role="math" and the equation (y = x squared) represented as HTML content. I can't test WebKit, but EdgeHTML doesn't expose any of the content, so it just becomes an unnamed, empty math equation. Which is broken and against author expectations; changing to a container model would at least expose it as "y=x2" (and would match Chromium and Firefox). Ideally, of course, the superscript nature of the "2" would also be exposed, and an assistive tool could use the parent math role as a hint on how to interpret and expose it.

So, in conclusion: I think switching to a simple container model for math would be a net improvement, although it's a breaking change for IE/Edge and WebKit. The worst case is that it exposes garbage presentational markup in addition to the text representation intended by the author. The best case is that it actual exposes the content the author intended.

[joanmarie]

@joanmarie Ok, let's see if I can update my understanding again:

The proposal is to treat the element with a math role as a container and expose whatever is inside it according to the normal rules for the markup language.

Yup! Apologies for not being clearer.

For MathML, a <math> element is a container, "whatever is inside it" is the markup that defines the actual equation. So the math role still applies to the outer container. ARIA wouldn't define or change how that inner MathML content is exposed.

Exactly.

[joanmarie]

Should an aria-label or aria-labelledby on an element with role="math" replace the child content (like it would for role="button" or other children-presentation elements)?

In my opinion no. And if the group agrees to make children-presentational=false for the math role, I believe it would obsolete this question (right?).

[joanmarie]

For now I'm going to assume that we have general consensus regarding moving the math role to a function serving as a container of mathematical content. I think one thing we'll need to define is what all constitutes valid content/use cases.

My thoughts: The purpose of the math role will be to display "mathematical expressions". By doing so, ATs could benefit from this role by:

• Enabling full punctuation verbosity so common symbols (e.g. "-") are spoken
• Preferring mathematical names (e.g. "minus") over the normal presentation ("dash", "hyphen")
• Not treating the text as if it were literary (don't pronounce "a" like "uh", don't switch to the Greek synthesizer to speak Greek letters)

Is there any reason why we shouldn't limit our revised math role to mathematical expressions?