The 1.1 spec states that the accessible name's final output is a flat string:
The string contains only character data; it does not contain any markup.
This makes sense if the goal is to remove things like font size and other tags that would be irrelevant when spoken.
But what about MathML? For example, when a student takes a multiple choice test, MathML could be used in buttons, checkbox labels, aria alerts, or other widgets.
I would recommend that it pass through intact to the the Accessibility API, so that a screen reader can apply its own speech rules to it, and/or display the appropriate braille representation of the math.
A simple example that would benefit: 23 (two to the third power). MathML is the only way currently to ensure this is displayed properly in braille, and also spoken correctly. It seems unfair to exclude it from the accessible name.
Another alternative: expect the user agent to run the MathML through its own speech engine to replace it with an appropriately flattened text string. This is less ideal for braille readers, but still better than the last option.
The last option (and the current state of things, generally): drop the math completely, as though it was just another irrelevant style tag. But this doesn't seem like the right answer.
pbblair
commented
5 years ago
The 1.1 spec states that the accessible name's final output is a flat string:
This makes sense if the goal is to remove things like font size and other tags that would be irrelevant when spoken.
But what about MathML? For example, when a student takes a multiple choice test, MathML could be used in buttons, checkbox labels, aria alerts, or other widgets.
I would recommend that it pass through intact to the the Accessibility API, so that a screen reader can apply its own speech rules to it, and/or display the appropriate braille representation of the math.
A simple example that would benefit: 23 (two to the third power). MathML is the only way currently to ensure this is displayed properly in braille, and also spoken correctly. It seems unfair to exclude it from the accessible name.
Another alternative: expect the user agent to run the MathML through its own speech engine to replace it with an appropriately flattened text string. This is less ideal for braille readers, but still better than the last option.
The last option (and the current state of things, generally): drop the math completely, as though it was just another irrelevant style tag. But this doesn't seem like the right answer.
Some guidance in this spec would be appreciated.