Interop with/use of accessibilityFeature property for MathML

[dginev]

I was investigating the question of whether there is a standardized way to annotate the target consumer for a given MathML dialect, mostly thinking of assistive technology.
(short answer: There isn't)

Instead, I discovered that ePub 3 has put in some work to leverage schema.org vocabularies for annotating various features that may or may not be enabled in a given document.

Most relevant may be the accessibilityFeature property, ands its schema.org accessibilityFeature vocabulary.

That effort seems to have independently (or has there been contact?) invented an annotation for chemical formulas, called MathML-chemistry.

The great enabling feature of using this approach is that we can do global, document-level, annotations, which we are currently missing. And it is helpful that it documents a fixed vocabulary for feature flags.

Reading their current vocabulary, this would be an example that the MathML on a page is already remediated for accessibility, either via alttext "or other means" and pertains to chemistry:

<article vocab="https://schema.org/" typeof="DigitalDocument">
   <meta property="accessibilityFeature" content="describedMath"/>
   <meta property="accessibilityFeature" content="MathML"/>
   <meta property="accessibilityFeature" content="MathML-chemistry"/>
   <!-- ... -->

Suggestion: I think the WG should discuss the mechanism and its possible use in MathML 4, and if seen favorably -- suggest helpful extensions.

[dginev]

Separately, and closer to my original query about specifying target consumers, there is a property that designates supported vendor APIs.

Namely, the accessibilityAPI property.

For example, this markup would indicate compatibility with the Android Access API:

   <meta property="accessibilityAPI" content="AndroidAccessibility"/>

[davidcarlisle]

but the description of that property says

The property is not applicable to resources that are not tightly integrated with their user interface. It can describe whether a word processing document that only opens in a specific application will work on a given platform, for example, but is not a useful indicator of whether an HTML document will, as there are numerous user agents a user could use to render it.

so it's probably not ideal for describing whether a html+mathml document will work with any specific API. (That doesn't mean there is anything that is better)

[NSoiffer]

I think there a some subtleties with the accessibilityAPI property that I don't understand. It is described as indicating " that assistive technologies on the platform should be able to access the resource." But (for example) MSAA and UIA are both Windows technologies, so if "platform" means OS, then why have two? But I think this is not about saying this document works this (random) technology, but that this document works with this platform-specific accessibility API.

The accessibilityFeature property (as are all the features?) a way for consumers to know whether content has the level/features they are interested in. As their example says, with it, a user can known when they get a higher level of accessibility because is uses MathML for the math (and/or the chemistry) or whether they are stuck with descriptions or some specialized format that requires specialized tools to read.

Although those two fields don't seem appropriate, perhaps we should start a conversation with some of the EPUB folks to see if there is something more appropriate, and if not, get it added. @clapierre is a member of that community, so maybe he can elaborate.

[dginev]

@clapierre We are exploring possible approaches to globally announce the features from MathML 4 Intent which are required by/present in an HTML5 document.

That should be completely compatible with the schema.org approach, and at least for now I don't quite understand the subtle issues others have identified with the accessibilityAPI and accessibilityFeature properties. One practical way forward would be to come up with a proposal for a handful of useful additions to their schema.org vocabularies and consult with the ePub group.