-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intent "alias" capability #40
Comments
I am not sure I am thinking about this the right way, but what I see here is a two-step process. Step 1: specify the meaning/intent of the expression. Step 2: specify how to indicate a preferred way (among the ways which are arguably I hope that we come up with a good way to do Step 1. Examples I keep returning to Once Step 1 specifies the meaning of If course, if one knows that the subject is K-14 then Step 1 may be unnecessary since But, as noted at the beginning of this issue, My first reason is that good AT is able to adapt to the needs of the user. Many expressions Another example is My second reason is that Step 1, in the cases where the expression is ambiguous, If Apologies if I misunderstood the suggested implementation of Step 1 and Step 2. |
This seems to be all about giving the *author* control over
what is spoken, rather than the *reader*. And for accessibility,
isn't the latter the one who should be in control?
And when you say:
To say these synonyms "exist", is to say that practitioners use them -
and so will practitioners using the new Intent standard - as long as we
have an "Open" level.
you seem to suggest that the authors will add their favored
terminology to the open dictionary no matter what.
This almost argues against having an Open list at all.
|
I feel strongly against claiming equivalence where any single person on earth may speak against such. However, I do not see a problem to simply grouping the default intents' rules for a better overview. |
In the Zoom chat @polx suggested that the aliases could help authors to identify the |
It seems to me there are two different ideas:
For '1', I think this can be solved by listing a bunch of names in the description so that any search finds the (single) core name. An advantage of this approach is that it leaves the other names to be used as if they were "open" names and hence will get spoken as an unknown name (typically 'my alias of xxx'). Since solves the "author control" problem ('2'). The only issue is if someone wants to force the speech for a name that is in core and might be spoken differently by AT. A solution to this would be to add a "-" to the start or end of the name. AT needs to converts hyphens to spaces to avoid some speech engines from speaking the hyphen (possibly as "minus" or "dash" or...), so if we say something in the spec about this, then the name "-open-interval" is not recognized as the core name "open-interval" but would be spoken as "open interval of 1 comma 5" instead of (maybe) "the open interval from 1 to 5". The downside is the author is stuck with however the AT says unknown names although this too can be overridden with something like |
To follow up on the WG discussion today about alternatives to the word "alias", here are a few from a thesaurus (there are surprisingly few):
I'm not keen on any of these synonyms and that well may be because "alias" is not close to what is desired. To throw out a few others after poking around in the thesaurus:
Maybe one of those will stimulate some idea for a better name than "alias"... |
I would suggest following the naming convention from Wikidata |
I also tried a thesaurus (fruitlessly).
Someone on the discussion had suggested things like
"seealso" or "related", but they don't quite convey
*why* one might want to see them.
Possibly slightly better might be "alternate",
which (to my mind) conveys that it is a similar thing,
but not just another name for an equivalent thing,
which is what "alias" suggests.
|
Following up on @physikerwelt's suggestion: how about "label" and "similar-names". I feel "also known as" still strongly implies that the other names could be used in place of the "label" with the same result. |
A new neutral phrasing that came to me today: "supplemental names" |
Following this discussion as an author and a 'perpetual student' -- unfortunately the scope of authoring math for pedagogy and authoring math for research do not always align. Pedagogical needs are far more varied, and would occupy the alias debate indefinitely. Research on the other hand is more 'top-down', defining new terms itself. I would argue that pedagogical needs outweighs research for three reasons:
This is not to downplay making research accessible-friendly out-of-the-box. But the need to account for multiple conventions more critically applies to K - undergraduate levels. With that in mind, the ultimate goal is for authors to use these tools. I imagine an authoring tool that one could customize with a `preset' of aliases for a given scope of symbols they intend to use. Would the specifications as grouped in the intents list allow for something like this? Then, an author could create their own such aliases if what they need isn't available. I respect the need to limit authors' complete freedom to override convention; at the same time, some authors are writing for very specific students and it would be best to allow as much customization as possible. But does that spill over into ARIA? The math role discussion suggests they are revising the math role to not interfere with how MathML handles accessibility. |
Thank you for the thoughtful reply @mathematicsformisfits ! I agree we need to get more clarity about the extent we want to be inter-operating with ARIA before everything settles. It makes a very big difference to the intent syntax whether we design it with a mindset that we have We've recently discussed we should find a way to solicit more ARIA feedback to our designs, so I'd expect this issue to remain open a while longer. That said, I am obliged to take exception to your use of
I think what you have done is to motivate well pedagogical uses are important and must be supported well. You have not motivated well that they I would have to challenge you on both of those points. Both kinds of materials are important, and we should aim to provide support for remediating both, already in this first pass. |
@dginev you are right, and I may have been unclear with that statement. All content should fall within the scope. Thank you for pointing that out. Allow me to contribute two examples:
So would the step 1/level 1 include multiple meanings, and then permit a particular phrasing with Then, if a particular phrasing was not available, an author could add their own with ARIA? That would account for any use, and so my distinction between use cases is unnecessary. On the other hand, first time students are sensitive to different phrasing, e.g.
In research, this latter case would be moot. So my apologies -- I do not mean to say it should not be given equal attention. I have just found more need for customization when creating teaching materials. |
Replying to @mathematicsformisfits, but also a general comment to where we find ourselves with this issue:
We have had an update from ARIA, essentially delegating the task of designing the full accessibility experience over MathML to the Math WG. As such, we will have to build the practical pieces we need in the MathML spec itself, likely starting with the main features in MathML 4, and then adding more in MathML 5, if "intent" is adopted and further capabilities are needed. As such, we would have to make a number of decisions on:
We also have to make a decision as to which of these features should be general, and which are specific to "Intent Core" or "Intent Open". I still think the best way to reach conclusions here is to work out the full details of what the lists of intent names will contain, as well as prototyping more examples of how they are used in AT, ideally in real texts. We are running short on time, so this will likely be as informed as we managed to make it through our work this summer. |
This is sort of outside of what we want to put in the spec, but it is useful and should be dealt with somewhere. Moving to docs so that someone remembers to write something up about this. |
Description
We have a common problem of synonymous and near-synonymous names when dealing with mathematical concepts. The same exact construct, often using the same notation, can be narrated using different words, while understood by professionals to have the same meaning. This makes it difficult to maintain a list of Intent values where we have a single name for each listed concept.
There are many reasons for such synonyms existing. To enumerate a partial list:
To say these synonyms "exist", is to say that practitioners use them - and so will practitioners using the new Intent standard - as long as we have an "Open" level. So one way or another, we will need to make provisions for them. If no special mechanism exists, the baseline support I could imagine would be:
Baseline treatment
Add each synonymous name independently to the Intent "Open" list, copying over any relevant additional information from its main entry.
This approach has no explicit connection between the (near-)synonyms, so AT will see them as completely independent.
Proposed "alias" mechanism
Currently, I have experimented with adding a column called "alias" to the list, where each main entry can receive additional known names. AT can then do an extended table lookup, and reuse any implementation for the main entry narration also for the alias narrations.
Benefit 1: each time our group starts a lexicographical discussion about "what is the Best name" to use in the list, we don't have to spend the time and effort making that decision. In the end of the day, these decisions are often arbitrary, not just in our group, but in mathematical practice in general. Rather than debating whether e.g. "log", "common-logarithm" or "logarithm" should be the Best name in our "Core" list, the aliasing mechanism allows us to make a "soft" choice for the primary name, where anyone that prefers an alternative name (again, established in actual mathematical practice) can add it as an alias and use it in their annotations.
Note: This idea of a "soft" preference is also something that entices me on the AT implementation side - if a user annotated "common-logarithm" that is a soft preference to use any speech specially dedicated to that string (for example - to be more specific), and vice versa if a user annotated "log" it could be a soft preference to be more succinct. Neil has made a very good case that this decision is only possible to do correctly by the AT, in the narration mode best suited for an individual user's needs. So AT makes a final decision.
The "soft" preference comes into play where, all else being equal, the author's wish may be respected - hopefully to the benefit of conveying the expression as close as possible to how the author wanted it received.
Benefit 2: rules where AT has special narration implemented can be directly reused, and maintain together, with the concept's aliases.
In the end this is an organizational question for the official lists, and what will be most convenient there long-term. We started a group discussion in our first Math WG call of 2022, and I think the group generally found this to be a suggestion that adds complexity for either limited value, or too soon - one of the sentiments is that we should have the most minimalist outcome possible for the first Intent proposal.
As we agreed in the meeting, I am opening the issue to explore the trade-offs fully. Discussion and feedback welcome!
The text was updated successfully, but these errors were encountered: