Clarify property use as descriptions

[dginev]

The spec text currently states:
https://w3c.github.io/mathml/#intent_property

property
A property annotates the intent with an additional property which may be used by the system to adjust the generated speech or Braille in system specifc ways. The property may be directly related to the speech form, such as :infix or indirectly affect the style of speech with properties such as :unit or :chemistry

The list of properties supported by any system is open but should include the core properties as described below.

It seems important to extend this text to match the original is-a motivation (#426). The text from ARIA aria-description and the definition of Accessible Description can be a good inspiration. As a first stab:

Non-core properties can be treated as a string value that describes or annotates the intent head, or if the head is empty - the current element. Non-core properties can provide more verbose information, as necessary, to offer an accessible description.

Suggestions welcome.

[NSoiffer]

Sounds good to me other than "can" should be "may" (spec language).

[davidcarlisle]

I don't think we should be encouraging people to smuggle sentences in to property names it is isn't like aria-description that takes a string. Properties, including non core ones should be labels, identifying some property not a textual description of the property.

[dginev]

I don't think as necessary is encouraging anyone to overdo the descriptions and write full sentences. It is also the language used by ARIA.

The key addition is signaling that the "accessible description" features typical to HTML+ARIA are also meant to be available in MathML Intent, if one chooses to leverage them.

[davidcarlisle]

but aria-description is a fixed attribute taking a free text string in its value. It doesn't seem right to take a description of that use to describe how to choose the name of a property.

[dginev]

I suppose we should discuss what is the "most verbose" possible use of a property that is still in scope. To use a recent pedagogical example, here is an English description that I would hope to be in scope. Naturally it uses color, as it is designed for visual consumption only:

Here the right-hand side of that equality is described by the text with a short sentence. That could have also (or instead) been provided as information inside the MathML, to be presented by the AT during navigation. For a long, but useful, property, I would imagine:

<mrow intent=":average-a-bunch-of-points-along-the-path">
  <mfrac><mn>1</mn><mi>N</mi></mfrac>
  <munderover>...</munderover><mrow>...
  <mfrac><mi>n</mi><mi>N</mi></mfrac></mrow>
</mrow>

This kind of annotation would be especially useful when the formulas get exceedingly large in size, while also useful for educational purposes in more entry-level equations.

[NSoiffer]

I hate to suggest it at this late date, but maybe that usage isn't a property, but something else. Earlier (I couldn't find the discussion I was thinking about) there was mention of using it in a more "property" sense. For example :real:positive.

While I can imagine the same mechanism (e.g., a popup) is used to convey extra properties such as "real, positive" as is used for descriptions, it seems like a design mistake to conflate the two ideas into one thing. A hacky way to unite these ideas is to say that something isn't a property in the sense that it can be used for functionality, is a literal property :_average-a-bunch-of-points-along-the-path? AT and other processors would not try to make sense of literal properties.

Just brain storming...

[dginev]

I am confused. None of this is new or different? is-a is meant as an accessible description for what a mathml subtree "is" conceptually, offered as auxiliary/secondary/optional information. And aiming for parity with the accessible descriptions of ARIA.

We renamed that to property, added : syntax and merged it with hints (#438 , #450 )

I assume you would be fine with annotating the mrow above as :average or :arithmetic-mean ?

So the contested extension is -over-points-along-the-path, and possibly the colloquial word bunch for bunch-of-points. But these kinds of qualifiers are normal in pedagogical use, where you try to elaborate to the benefit of novices. It certainly won't be useful for all sums, or even all materials that deal with this exact sum. That is up to the author/annotator of each document.

There are more official long auxiliary names as well, such as

• :cyclotomic-fast-fourier-transform
• :one-three-seven-trimethylpurine-two-six-dione
  • which is (admittedly the longest possible) chemical name of "caffeine".

[davidcarlisle]

surely an FFT is a function so would be coded as a concept not as a property, similarly caffine as a value is concept it's a chemical constant cf mathematical constants, it might have property :chemical-element or some such but I wouldn't code the specific chemical name as a property.

[dginev]

Sure, I'm happy to offer a concrete example for that use as well.

Here is a CFFT from ar5iv:1108.4168, Section 3: https://ar5iv.labs.arxiv.org/html/1108.4168#S3.p3.2.m2.1

I claim it is a useful feature to enhance it with the accessible description:

<mrow intent=":cyclotomic-fast-fourier-transform">
  <mi>𝐀</mi>
  <mi>𝐋</mi>
  <msup>
    <mi>𝐟</mi>
    <mo>′</mo>
  </msup>
</mrow>

The property is available on demand, while retaining the primary readout of the presentation tree. That way the first time a readout is produced it speaks the specific instance of performing that kind of transform.

The concept names for is-a can act as types, and we don't want to speak the type in place of the concrete term being typed. Which is why I wouldn't recommend dropping the : and changing such cases to an "intent concept".

(Aside: Sadly the actual MathML in ar5iv has an imperfect presentation tree, as latexml merged the variables in a single mi. I have corrected the tree in the comment here to an error-free form.)

[polx]

I just met a paper aiming at covering multiple aspects of this formula enrichment possibilities which they call "math augmentation": https://dl.acm.org/doi/10.1145/3491102.3501932

The paper concludes with recommendations about markup languages to support augmentations. Intents seem to correspond to my eyes but the flexibility of the situation makes me think that we should leave the door wide open instead of defining possible interactive usage (e.g. allowing multiple situations (levels?) of verbosity).

[dginev]

@polx yes that paper is fascinating. We have already discussed it briefly in the MathML context - see #441

But I am not sure I understand. Are you suggesting that parity with "accessible descriptions" closes a door? I am not sure I see that.

To me it is an opportunity to increase the uniformity between usual HTML and MathML user experience, and I think we should aim for that. I had initially proposed a separate attribute to avoid even the perception of interplay with other intent features (#426) - or just use aria-description itself - as descriptions shouldn't hinder any other experimentation you have in mind.

[brucemiller]

Although properties share a lot of isa character, their primary purpose has evolved into being modifiers of the encoded (or implied) intent so as to affect the generated speech, or choose from several speech patterns. To stretch the isa character into a general description seems to me to go too far; An unknown property would be interpreted and used differently in those two cases (modifier vs description) and would lead to confusion and unpredictable behavior.

Exactly to increase uniformity with the "web platform", and avoid MathML being the odd man out, wherever there is existing (or developing) mechanisms for things like descriptions, tooltips, etc, we should leverage those mechanisms, rather than reinvent them.

[dginev]

@brucemiller it isn't exactly clear, are you suggesting that MathML 4 recommends using aria-description for accessible descriptions here?

[brucemiller]

I probably am, or at least we should buy into whatever mechanism the web platform recommends for "descriptions" (which presumably is aria). I suspect we'll be more successful by focusing intent on generating the basic text/speech equivalent, rather than trying to cover every possible accessibility related facet. The latter runs the risk of complicating and confusing the use of intent, and clashing with other aspects of the platform (as with CSS).

[polx]

My comment with bringing in the paper was rather: it's impressive how infinite the imagination of people will be to enrich the interactive use of formulæ.

So we will not have enough by adding a single level. My suggestion is to propose some kind of extensible mechanism of multiple labels and let this be handled by some JS.
Such labels can have formulæ, pictures, links, styles or many many more things. I only see the semantic element applicable.

What the intents has taught us, however, is that aria-label are not sufficient for even the intent purposes: they don't allow/invite read-aloud of children. Or?

[dginev]

What the intents has taught us, however, is that aria-label are not sufficient for even the intent purposes: they don't allow/invite read-aloud of children. Or?

Yes exactly. aria-label="an English label" is a flat label, just as intent="_an-english-label" is flat and won't invite read-aloud of children.

Since I have been at times gardening ARIA parity (meaning "try to be at least us good as the support available in ARIA"), here is my current thinking:

There are two ARIA features that are simple and useful, which I have been careful to keep enabled in the current intent syntax (in the spirit of the "mandate" we were given by the ARIA group in ARIA #1723 ).

• You can do anything you can do with aria-label using Intent _literal values, but we have also put in enough work that you can do more than just labels (e.g. accessible navigation via compound intent expressions)
• You could do anything you can do with aria-description with properties/is-a, as long as we clarify the text that non-core properties can be treated as "accessible description" strings.

I haven't done any work on more advanced features, such as aria-live regions, mostly due to maction being deemphasized in recent MathML Core work, which recommends leveraging the outer HTML interactivity (where aria-live is already specified).

[NSoiffer]

To ground the discussion a bit...

MDN says this about aria-describedby:

The aria-describedby property is appropriate when the associated content contains descriptions experienced as plain text. If the content contains a large amount of content, useful semantics, or has a complex structure requiring user navigation, use aria-details. aria-details allows assistive technology users to visit the associated structured content and provides additional navigation commands, making it easier to understand the structure, or to experience the information in smaller pieces.

It also mentions the description must be plain text.

AFAIK, no screen reader will do anything with aria-describedby in MathML. It would be tricky to get MathCAT to be able to handle aria-describedby because MathCAT can't see anything outside of the MathML it was given. Likely, the screen reader itself would need to be modified. Or maybe the id can be buried in a semantics child?

Screen readers will look in the MathML for some things. For example, if I add tabindex="0" to a MathML element, the screen reader's focus lands there. However, but NVDA and JAWS are then very confused when you hit an arrow key.