Naming the arguments to intent: new property needed?

[NSoiffer]

When navigating 2D structures with AT, it is very common to name the part of the expression one has navigated to. For example, if you have a fraction, then when you "zoom into" the fraction, you will often hear "in numerator" and/or "end numerator" when leaving it. Same for the denominator. For "msup", "base" and "superscript" (or "exponent") might be used. If an intent is given that is not in core, there is no way for AT to use a concept-specific name when navigating.

As an example of how one could handle this, one could add something like ":navname-xxx" to the arguments. As an example

<math>
    <mrow intent=fraction-like($x, "_over_", $y)>
        <mo>\</mo>
        <mtable>
            <mtr><mtd><mi arg='x' intent=':navname-num'>a</mi></mtd></mtr>
            <mtr><mtd><mi arg='y' intent=':navname-denom'>b</mi></mtd></mtr>
        </mtable>
        <mo>/</mo>
    </mrow>
</math>

In this example, the user might hear "fraction-like of a and b end fraction-like" when listening to the expression. If they decide to navigate into it, they might hear "in num, x". Moving right, they might hear "out of num, in denom, y". Without the names, they might hear some generic phrases: "in arg 1" and "out of arg 1, in arg 2 y". That's not ideal, especially when you have nested expressions so that there several "arg 1"s, etc.

We at one point discussed a param=value for properties but felt that was too complex. This is a "data-xxx"-like ugly version of it where AT would could recognize navname- as being important if it is doing navigation and get the name to use by choosing the string that follows it. The main benefit to this approach over the param-value approach is that this doesn't introduce new syntax to the grammar for intent.

[dginev]

When navigating 2D structures with AT

Introducing dedicated markup extensions for "navigation" is an interesting topic, but likely out of scope for the current charter, given the date.

If an intent is given that is not in core, there is no way for AT to use a concept-specific name when navigating.

This is incorrectly stated. Any "supported concept" for an AT can have enhanced treatment, including Open concepts. It is rather the "unknown concepts" (to an AT) which have no expectation to use any enhanced techniques when navigating into the arguments. I think that is a healthy state.

We could offer a default behavior in the spec. We mention an "unknown concept" is vocalized as if it were text. We can also decide that navigating in intent applications that have an "unknown concept" as their head, will vocalize the arguments in order when navigating. "arg 1", "arg 2", as stated in the issue description. If needed, nested structures can be vocalized even more verbosely "unknown-concept-name-arg-1", ""unknown-concept-name-arg-2", etc - but this seems closer to vendor behavior rather than something that needs to be standardized.

Note that knowing the type of an argument does not solve the full nesting-ambiguity problem, as the same exact concept can be nested multiple times. (Very common to nest fractions, hearing "denominator" does not in itself explain at which level).

The design of the Open realm of Intent seeks that when an AT is highly motivated to provide advanced behavior for a rare concept, it can and should, also adding it to Open and documenting useful details in the list. We should not shift that burden to the authoring markup of intent. In my opinion it is an AT responsibility.

[davidcarlisle]

Note that you can do this in any case with no change in the spec. The current definition of property says

The use of these properties in other contexts is not an error, but as with any properties, is by default ignored but may have a system-specific effect.

so having an intent=':navname-num' is perfectly harmless if the mathml is processed elewhere. (In theory another system could define those property names with a different semantic but that seems highly unlikely and not really an issue. (There are other potential differences between systems that arefar more likely and already tolerated)