Notes and other documents by the Math WG. See also https://github.com/w3c/mathml-core (repo for the MathML Core spec) and https://github.com/w3c/mathml (repo for the MathML 4 spec).
In the accessibility gap analysis, there are two dimensions that could be more clearly separated.
How should the disambiguating "intent" information be expressed? Should it be a string - or an array of strings - that directly specifies the text which is to be presented to the user (e.g., spoken, or forwarded to braille output)? Or should it be a formal representation of the meaning of an expression/subexpression? Or should it be a hint to the rendering application (e.g., a subject matter designator or other disambiguating information drawn from a formal taxonomy)?
What mechanism should be used to deliver the information described in (1) to the user agent and associated assistive technologies (in particular, screen readers and read-aloud systems)?
It seems to me that the current draft doesn't clearly separate these concerns, and hence overlooks possibilities. For example, one could define an aria-mathintent attribute for use on elements with role=math and their child elements. The value of this attribute could be a formal specification of the expression, or items taken from a defined, mathematical content disambiguating taxonomy. The current discussion of ARIA instead focuses on aria-label and aria-labelledby, and assumes that these existing properties would carry a final (presentational) rendering of the expression, or, better, multiple such renderings in a way that would need to be clarified and for which no structure presently exists in WAI-ARIA.
I have strong concerns about using aria-label or aria-labelledby in so far as these options involve supplying the final rendering in the markup rather than relying on the user's assistive technology to generate the presentation. If the authoring tool or the Web application is responsible for rendering, then the user's presentational preferences (e.g., preferred braille code, preferred spoken mathematics conventions) are unlikely to be applied, unless support for these features is provided in the application and the user is able to set preferences at that level. Then there's the disadvantage that different Web sites/applications could carry different rendering tools or different versions thereof - crating inconsistency for the user. Further, the desirable rendering may differ depending on whether the user is reading the entire expression or engaging in structural navigation. The same arguments apply to the use of mechanisms other than ARIA in so far as the expression would be represented in the document markup, and the DOM, as a final rendering rather than in some kind of formal vocabulary (e.g., MathML with associated, disambiguating annotations).
I would prefer that the disambiguating information be some kind of formal vocabulary, as in the proposed "MathML-specific solution" or the parallel presentational/content MathML - but not necessarily using those mechanisms for delivery.
Similar remarks apply to the proposed CSS-like syntax: a clearer separation of what data the properties would hold (i.e., final rendering or a formal disambiguating notation), and what the annotation mechanism is (in this case, a CSS-like language) would facilitate the discussion considerably. Microdata and RDFA are in a similar position: the annotations could represent the rendered text of the expression (e.g., speech and braille separately or either one of these), or a formal vocabulary that conveys "intent".
I don't currently have strong preferences regarding the delivery mechanism. It does appear that having the ability to derive a string representation of the expression (e.g., the MathML markup itself, with disambiguating annotations, or some other formal representation) that an assistive technology can process in a discrete module - whether written as part of the AT or supplied externally - is a valid use case.
In sum, I think disentangling the issue of how the information is represented from what technology should be used to carry it would clarify the discussion somewhat. It also seems to me that carrying the final rendered form of the expression in the markup is undesirable, and that it is not a substitute for a mechanism that properly disambiguates the notation while leaving it to the assistive technology to decide how to present it to the user.
In the accessibility gap analysis, there are two dimensions that could be more clearly separated.
How should the disambiguating "intent" information be expressed? Should it be a string - or an array of strings - that directly specifies the text which is to be presented to the user (e.g., spoken, or forwarded to braille output)? Or should it be a formal representation of the meaning of an expression/subexpression? Or should it be a hint to the rendering application (e.g., a subject matter designator or other disambiguating information drawn from a formal taxonomy)?
What mechanism should be used to deliver the information described in (1) to the user agent and associated assistive technologies (in particular, screen readers and read-aloud systems)? It seems to me that the current draft doesn't clearly separate these concerns, and hence overlooks possibilities. For example, one could define an aria-mathintent attribute for use on elements with role=math and their child elements. The value of this attribute could be a formal specification of the expression, or items taken from a defined, mathematical content disambiguating taxonomy. The current discussion of ARIA instead focuses on aria-label and aria-labelledby, and assumes that these existing properties would carry a final (presentational) rendering of the expression, or, better, multiple such renderings in a way that would need to be clarified and for which no structure presently exists in WAI-ARIA.
I have strong concerns about using aria-label or aria-labelledby in so far as these options involve supplying the final rendering in the markup rather than relying on the user's assistive technology to generate the presentation. If the authoring tool or the Web application is responsible for rendering, then the user's presentational preferences (e.g., preferred braille code, preferred spoken mathematics conventions) are unlikely to be applied, unless support for these features is provided in the application and the user is able to set preferences at that level. Then there's the disadvantage that different Web sites/applications could carry different rendering tools or different versions thereof - crating inconsistency for the user. Further, the desirable rendering may differ depending on whether the user is reading the entire expression or engaging in structural navigation. The same arguments apply to the use of mechanisms other than ARIA in so far as the expression would be represented in the document markup, and the DOM, as a final rendering rather than in some kind of formal vocabulary (e.g., MathML with associated, disambiguating annotations).
I would prefer that the disambiguating information be some kind of formal vocabulary, as in the proposed "MathML-specific solution" or the parallel presentational/content MathML - but not necessarily using those mechanisms for delivery.
Similar remarks apply to the proposed CSS-like syntax: a clearer separation of what data the properties would hold (i.e., final rendering or a formal disambiguating notation), and what the annotation mechanism is (in this case, a CSS-like language) would facilitate the discussion considerably. Microdata and RDFA are in a similar position: the annotations could represent the rendered text of the expression (e.g., speech and braille separately or either one of these), or a formal vocabulary that conveys "intent".
I don't currently have strong preferences regarding the delivery mechanism. It does appear that having the ability to derive a string representation of the expression (e.g., the MathML markup itself, with disambiguating annotations, or some other formal representation) that an assistive technology can process in a discrete module - whether written as part of the AT or supplied externally - is a valid use case.
In sum, I think disentangling the issue of how the information is represented from what technology should be used to carry it would clarify the discussion somewhat. It also seems to me that carrying the final rendered form of the expression in the markup is undesirable, and that it is not a substitute for a mechanism that properly disambiguates the notation while leaving it to the assistive technology to decide how to present it to the user.