Re: a minimal core intent proposal

As a general conceptual approach, I tend to share David's viewpoint that "functional semantic disambiguation" is the ideal direction. If the goal is to simply dictate the precise words that a screen-reader or TTS tool will read, then it seems the correct approach would be to figure out the technical mechanics of meshing already existing tagging methods of controlling speech (e.g., SSML and/or ARIA) with MathML.

--Steve



Steve Noble
Principal Researcher, Accessibility
Psychometrics & Testing Services

Pearson

502 969 3088
steve.noble@pearson.com<mailto:steve.noble@pearson.com>

[https://ci3.googleusercontent.com/proxy/xFjftXlwMzpdFeTtDgc4_IwyMYm8ThtQHIsgElkS8fyiCO2M7ZM0WaO7r2uy-bmKAe5S2sIcg7d-mwbD4ArkJhyafHke-SgJ2ui8DoGoBhZw4YIyWeK3LUozNMwBff4JR2tdu8nZ2fvoNvkkA06KNw9-s3P9UvYsHSTphHss6X0=s0-d-e1-ft#http://accessibility4school.pearson.com/access/4c49fe02-e204-46b4-b6f0-82f5a3f159cb/pearson-accessibility.jpg]

________________________________
From: David Carlisle <davidc@nag.co.uk>
Sent: Thursday, November 10, 2022 7:17 AM
To: www-math@w3.org <www-math@w3.org>
Subject: Re: a minimal core intent proposal

On 09/11/2022 17:54, Neil Soiffer wrote:
I wrote a proposal<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fmathml-docs%2Fminimal-intent-core&data=05%7C01%7Cdavid.carlisle%40nag.co.uk%7C02c7f5c99f504beea9e008dac27bb1ac%7Ce7971626b996462eb3c9bbba3a50d55d%7C1%7C0%7C638036134129448216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pDOYz6CunNERyLXU3mzduG24e3IVTCb80rOgmsKNynk%3D&reserved=0> for simplifying what goes into intent core. It ended up being sort of an "AT requirements" document for core. If I extend it a little further to include what AT should do with "intent" (currently just presumed everyone knows), it would be the basis for an actual AT requirements document (or appendix). It also serves to let authors/authoring software know what they can count on as default behavior by AT.

The proposal contains some open questions, but I believe it is fleshed out enough that it is understandable and actionable (let's do this/don't do this). It extends what I put in Deyan's intent spreadsheet and also has explanations. It will be the basis for the third agenda item on Thursday.

    Neil



A (perhaps subversive) comment on

> intent="open-interval@silent(_open-interval-from, $start, _to, $end)"


> I don’t have a strong argument why this explicit use of words as arguments should be avoided, but it seems wrong. If this is considered “good form”, then the third case can be dropped.


I can't say I like it much: I'd rather it was just a fallback for tricky cases, but if it is there, people will use it...


"intent" started out (some years back) as "semantics" but over time we have pushed it more and more away from semantic disambiguation and towards controlling an AT speech engine.

It seems to me that if we really want to go this way we should (or could)  drop the remaining vestiges of the functional "semantic" markup and just have a templated natural language string


intent="open interval from $start to $end"


if it is only used by AT speech do the "_" and "," and "()" give anything?

That is, the content of the attribute would basically be in the format of the "Speech Hints" Column in the existing spreadsheet.

An advantage of the functional semantic disambiguation is/was that it gave AT more flexibility in the words generated, but probably needs the original long list of core functions,
but once most, or even some "functions" have arguments such as

_open-interval-from

it really isn't usable for anything but text, so I'm not sure what we gain by using _ to force it to look like a single token in a function call.

David












Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: 30 St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our Privacy Notice <https://www.nag.com/content/privacy-notice> for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware by Microsoft Exchange Online (EOP)

Received on Thursday, 10 November 2022 13:44:22 UTC