Re: multi-symbol variables

Maybe I'm starting to drift off topic, but is intent needed when the
reading of the leaf elements is the "natural" one? Bear with me as I'll
eventually get back to what people have discussed...

Let me start with something that is maybe uncontroversial: do we need to
specify intent on <mn> in most cases? I can see roman numerals and non-base
10 numbers as *maybe* exceptions, but as long as they are "spelled" out, it
is hard to see the need.

For <mi>, are they needed? There are *known* cases such as "sin" where you
need to pronounce them differently than the spelling, but these are
abbreviations that are well recognized. Others, such as GF (galois field)
are also abbreviations, but I think that there is general agreement to say
"GF". Maybe some <mi> such as a subscripted "B" might be spoken as
"Bessel", but usually that would include the order and hence an intent set
on the msub. I think the main thing of interest for AT is whether the <mi>
should be spoken as a word or spelled out.

For <mo>, the contents, although symbols, have names. The Unicode names are
a good fallback, but not always. For example, "+ is "plus sign". It is
reasonable to expect that  for common symbols, AT will have better ways to
pronounce them. Since some symbols have multiple uses, using intent is
reasonable on  <mo>, but I suspect mostly unnecessary.

For mtext and ms, they almost always want to be spoken as their text.

To return to some of the examples. If someone uses a prime, double prime,
etc, a literal reading "x double prime" doesn't need anything special in
some sense since the words are derived from the leaf values. Bruce's
suggestion of intent="literal" or maybe intent="silent" (meaning *this* tag
does not contribute to the reading) would be helpful versus an intent that
requires pulling together the children into the reading. <mrow> would be
another case where literal/silent makes a lot of sense as a default intent.

The use of generic or functional intent values versus literal reading
values is the heart of what I perceive as the conflict/tension we still
haven't resolved. I believe no one is advocating that intent be required,
and hence some defaults are needed. Perhaps thinking about the default
intent values will help resolve this tension. I believe the defaults can be
crafted in a functional manner (Sam has already shown some), but I'm less
sure (because I haven't thought it through) that a literal reading method
of defaults makes sense, but the above about leaf elements is a start in
that direction.

Apologies for the somewhat rambling nature of my reply, but I'm still
unclear as to what is best -- I see pros and cons to both.

    Neil


On Fri, Oct 8, 2021 at 9:10 AM Deyan Ginev <deyan.ginev@gmail.com> wrote:

> Hi Paul,
>
> Yes, exactly, I was trying to motivate why these custom strings are
> needed in general - happy you agree!
>
> ---
>
> Re: Bruce's mention of a custom keyword to make this explicit, I think
> that won't be needed in what we've prototyped so far, since the "Level
> 3 fallback" technique handles the case.
>
> intent="B-double-prime"
> intent="p-n-tilde"
> intent="F-tau-star"
>
> would just get the baseline aria-label treatment initially (as they
> are unknown to the AT tool), until a day comes that some AT tool
> developer decides to add special rules anchored on them.
>
> Greetings,
> Deyan
>
>
>