Consider adding context attribute through which ATs could ensure correct presentation of content

[joanmarie]

Use case: screen readers (and other tools) presenting technical information via speech output.

A couple of quick examples:

1. The author wants the screen reader to speak superscript 2 as "squared" because the context is algebra.
2. The author wants the screen reader to speak superscript 2 as "superscript 2" either because the context is not algebra or because familiarity with notations is being tested.

There are undoubtedly other cases were a single notation can mean a number of things depending on the subject matter. Screen readers and other tools presenting this information have heuristics to try to get this correct. But heuristics are fragile. I think it would be better if we could provide a mechanism through which authors could specify the context (subject matter; desire to not interpret anything about symbols; etc.) to the tools presenting the information to the end user.

[johnfoliot]

...context ...customize presentation.

This very much sounds like Personalization Joanie, and I question whether ARIA is the way to go here... (Just sayin'...) JF

…

On Wed, May 23, 2018 at 9:12 AM, joanmarie ***@***.***> wrote: Use case: screen readers (and other tools) presenting technical information via speech output. A couple of quick examples: 1. The author wants the screen reader to speak superscript 2 as "squared" because the context is algebra. 2. The author wants the screen reader to speak superscript 2 as "superscript 2" either because the context is not algebra or because familiarity with notations is being tested. There are undoubtedly other cases were a single notation can mean a number of things depending on the subject matter. Screen readers and other tools presenting this information have heuristics to try to get this correct. But heuristics are fragile. I think it would be better if we could provide a mechanism through which authors could specify the context (subject matter; desire to not interpret anything about symbols; etc.) to the tools presenting the information to the end user. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#767>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c2ieSctUQLnP2XV8bT9plYIZsEYjks5t1WBZgaJpZM4UKa_G> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[joanmarie]

I know @johnfoliot. :) And "personalization" was one of the things that was mentioned during the discussion at the face-to-face meeting I am currently at.

What I would like to do in this issue is gather input from stakeholders so that we know what all the use cases are. Having done so, then we can all then strive towards reaching consensus on the right solutions. The right solution might prove to be to close this issues as WONTFIX (i.e. in ARIA) and move it elsewhere. But I'd like to gather the input first. Hope you don't mind.

[joanmarie]

I tweaked the summary/title of this issue. Consider the following actual use case I have:

Right now, independent of personalization, Orca always says "superscript 2" for a superscript 2. A number of people tell me that this is a bug in Orca and that Orca needs to look at the surrounding content and have heuristics so that Orca says "squared" when the superscript 2 is serving as a power, but something else when it's not a power. So apparently I have to add a bunch of heuristics to Orca. Heuristics are hard to get right. And when you're always trying to optimize performance so that presentation is not laggy, yet another heuristic is not desirable. If I could instead just look up at an ancestor of the element and find an attribute that tells me that the squared is clearly serving as a power (or not), that would be super helpful: both more reliable and more performant. And it would not require an author to slap aria-label (or some other property) on all the superscripted numbers in their content to force Orca (and/or other tools) to say the right thing.

And note that the superscripted 2 is just one example. I learned this week that some tool (MathPlayer, perhaps?) has something like 1300 heuristic rules in order to try to get symbol names right for the context -- and still fails to get every symbol correct. (Props that it does a decent job most of the time, but 1300 rules. Seriously?)

Long way of saying the following: I do think that there is a personalization aspect to this problem. But I also think that there is a separate non-personalization aspect, namely screen readers and other utilities generating spoken math should be able to identify the broader context in which something appears in order to speak it in the appropriate way for the material. End users and authors should potentially also be able to override (personalize) that appropriate-for-most behavior. But the default/generic/non-personalized behavior should be right, and that's hard to do without context.

[jnurthen]

Agree that ARIA may well not be the right place for this but placing into a 1.3 Milestone for visibility

[alia11y]

I am going to discuss it in our Pronunciation Task Force meeting. This issue seems related to our working group.