add aria-labelsynonyms #1794
add aria-labelsynonyms #1794
Conversation
cookiecrook
requested review from
aleventhal,
jnurthen,
joanmarie,
scottaohara,
smhigley and
spectranaut
|
Is it potentially worth combining this proposal with #816 - specifically the It does seem that for for interactive elements / commands, a comma separated list of alternative names would be incredibly helpful, but on non-interactive elements i could see this fulfilling the use cases outlined in the linked issue (e.g., terse name for columnheaders, and the other examples mentioned by @cookiecrook in this comment) |
|
@scottaohara wrote:
I see that as a separate use case. For example, the "terse label" and the other header use cases in #816 are intended to be voiced or otherwise conveyed by the device during certain contexts, but these label synonyms #1794 are only intended as alternative accessors when spoken or typed by the user. I don't think these would ever be spoken by AT during a standard browsing context. Perhaps I'm missing the connection you're making. |
Co-authored-by: Valerie Young <spectranaut@gmail.com>
…sallowing on presentational children
Co-authored-by: Scott O'Hara <scottaohara@users.noreply.github.com>
|
Committed @scottaohara's suggestions. r? |
|
Are there any ATs other than MacOS that are signed up for this? Not saying it's a bad idea at all, but I'm concerned that Mac will be the only platform that uses this, and it will lack follow through. IOW, what if nobody is signing up to drive solutions for other ATs, and authors get a false impression regarding its impact. Maybe we need to make sure to have an adoption strategy for this. |
|
This reminds me of how when you're in a settings panel on some platforms, using the search feature finds the thing you want even if it's just a synonym. This might be a nice way to support similar use cases in HTML, such as "find in page" and search engines. (As such, I wonder whether this shouldn't be part of HTML, since ARIA doesn't generally affect browser behavior. Worth discussing, anyway.) |
|
I'm wondering if author-supplied markup is the best way to solve this synonym problem. Making the voice access feature a bit smarter, so that it either knows common synonyms or can learn them, or so that it pulls from context for our old friend "more info" seems like it might be more effective. Are there authors who are asking for this feature? |
A neat benefit of doing it in the AT would be more consistency across content, even when the author didn't know about this piece of markup. It's also one less ARIA attribute. |
|
@cyns wrote:
and @aleventhal wrote:
There is nothing here stopping that from happening. I would encourage it in addition to this author-provided Web API.
Yes. Multiples before I filed the original issue #1038, and multiple since then… some even commented in the issue. |
|
@aleventhal wrote:
In addition to MacOS, this has been shipping for 3 years in iOS and tvOS. I wonder if @chendo would be interested for ShortCatApp. |
|
As mentioned by @DanielGoransson in the original issue #1038, this feature is especially relevant to support developers wrt WCAG Success Criteria 2.5.3: Label in Name. |
|
For the discussion. Search engines currently handle synonyms and there are synonym libraries available, such as https://www.npmjs.com/package/synonyms Apologies to those working on this, but I'm concerned that it won't get a lot of uptake, while a generalized downstream solution could more both feasible and more consistent. |
|
I think the synonym lookup project you pointed to is dismissible. English-only, with 1 issue and 1 PR in 6 years? Regardless, this proposal is solving a more difficult problem than a simple synonym lookup script could achieve in the near term. If you look at the use cases, "x" is not a synonym of "close" nor is "Wednesday" a synonym of "first." Beyond the fact that this is solving a different problem, speech command and control AT (as opposed to NLP-based virtual assistants) often still rely on recognition against a finite list of commands, to improve reliability. |
This would be a great feature actually! Currently, Shortcat has its own list of common synonyms to expand, e.g. "delete" also matches "clear", "destroy", "remove"; however, this isn't performant, and only works on English so far. However, I'm not sure how I'd retrieve these label synonyms with the existing Accessibility APIs. |
|
@cyns @aleventhal, Perhaps the name "label synonyms" is the hang up? Do you think "label alternates" or something else would be more representative of these typeahead and speech-input scenarios we're trying to solve? It may at least avoid the misinterpretation that this is as simple a problem as thesaurus lookup could solve. |
|
@chendo wrote:
The Web API would be mapped by WebKit the same way as the native API on Mac, which is both a getter and a setter. I'll reach out offline for any follow-up questions. |
|
Another example from this page. The "Thumbs Up" (👍) button action has an association to "+1" and "Like" that is not exposed to assistive technology. Some other sites use the ❤️ icon for "Like", "Love," "+1," etc. Not all are direct language synonyms, but any should work if the Voice Control user says something like "click +1". This particular example is associated with the aria-actions PR to some degree. "Like this" "+1 this" etc. should all work for a speech user. |
|
Would be interested to know if Microsoft would be on board for this. |
|
@KimPatch FYI |
|
Speaking as someone who's trained many speech input users and used speech input or mixed speech/pen tablet input for several decades for all my work (including PC Dragon straight and with third-party tools and custom commands, Mac Dragon, Mac OS and iOS) I'd stress that a key thing that speech users need is the ability to turn off synonyms. Synonymous speech commands for dangerous actions like delete is a load of trouble, especially given users that don't necessarily know all the synonyms. Synonymous commands are a huge problem because commands can be tripped accidentally for all kinds of reasons. It makes troubleshooting much, much harder and makes users want to give up on speech input. Yes, it's useful to have a fairly terse way to say something (but not too terse because extremely short commands are not as well recognized and can trip accidentally). And it's also important that users remember commands. Two word commands are usually the best, and combining commands speeds things tremendously. So it's a balance. And default commands have historically done a fairly terrible job of recognizing this balance. Adding synonymous commands to try to fix the problem causes another problem. I think the solution is to allow users to modify, save and share commands, including the ability to modify any command and turn off any command wording. Enable the people actually using the software develop command sets – kinda like how language develops, and make it easy for people to use just the commands they want and pass commands around. My two cents… |
|
@cookiecrook do we want to leave this open? Are we still looking at doing this? |
closes #1038
Preview | Diff