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
Spec is unclear on aria-invalid="spelling" | "grammar" uses #989
Comments
Are there any examples in the wild where this is used? I'd always assumed it was something theoretical that didn't actually work correctly anywhere.
|
I added this back in my IBM/Firefox days for some use case or another, but don't remember. However, Google is intending to use this now for both Google Docs and Gmail. There isn't actually another semantic way to expose grammar errors. Browsers don't implement that it's always server-based, afaik. I'll get around to your other requests at some point? :) |
The spec for aria-invalid says:
and then the possible values are listed in the Values table:
Agreed that the initial sentence in the prose should change to allow for values other than true. How about:
Other than that sentence, I'm not sure what you mean, @aleventhal, about the spec not matching CORE-AAM? Can you explain in more detail? Aside 1 (only tangentially related to this issue), I think the following sentence needs a bit of wordsmithing:
This feels too vague. I think authors would wonder how they should provide suggestions. Should they be using aria-errormessage? Is there an aria-suggestions attribute somewhere? Or is it simply that they "SHOULD somehow provide" or "SHOULD design UI to provide" suggestions? Aside 2, regarding the following sentences:
I think the phrase "For future expansion," belongs in the 2nd sentence, and the phrase "enumerated type" should link to https://w3c.github.io/aria/#enumerated-attribute-values, so I would rewrite the above 2 sentences as follows:
|
@carmacleod The unclear part is that aria-invalid=true needs to go on a form control, but aria-invalid=spelling|grammar can go on a lot more elements, such as a span. |
@aleventhal Hmmm, you're right - that is not at all clear in the spec. I would argue that it's not clear in CORE-AAM either. :) The only place form controls are vaguely hinted at in the spec prose is:
Also, form controls make up most of the roles in the "Used in roles" list: application, checkbox, combobox, gridcell, listbox, radiogroup, slider, spinbutton, textbox, tree, columnheader, rowheader, searchbox, switch, treegrid I guess changing So... how should we fix this? Do any ATs actually handle aria-invalid on a span? |
JAWS does not distinguish between aria-invalid=true/spelling/grammar and outputs aria-invalid only at the form element itself, not inside or outside a form element NVDA correctly distinguishes between aria-invalid=true/spelling/grammar and outputs spelling/grammar also inside and outside form fields, e.g. at Tested with Chrome at https://codepen.io/jaws-test/pen/eYdoLeb |
@JAWS-test could you try with contenteditable? This worked last time I checked. I'm sure it works in 2021, and probably in 2020 as well. It would be nice-to-have in a virtual buffer, but it's absolutely essential in a contenteditable while arrowing through the text. |
@aleventhal |
@JAWS-test That sounds familiar -- I think it was fixed in 2021. We need to get you a copy of 2021, otherwise we will have to rename you Old-JAWS-Test! :) |
Actually, aria-invalid=true/false and spelling/grammar are two quite different things that are hard to fit into one attribute:
|
Using JAWS 2021.2012.57 and Chrome 88.0.4324.104 and your example: only aria-invalid=spelling is output by JAWS, but not aria-invalid=grammar. The cause is probably a JAWS bug because Chrome correctly passes the aria-invalid information to the Accessibility API The same is true for Firefox. In Firefox, however, aria-invalid=spelling is also detected within role=textbox, and aria-invalid=spelling/grammar at role=textbox is always detected as an erroneous field |
@JAWS-test thank you for finding that bug in JAWS. I had reported it, and believed it to be fixed. I'll let them know it's a high priority. |
@JAWS-test , my mistake. It does work. There's a setting that I forgot about, which needs to be enabled :(. I've asked Vispero to consider turning on the setting by default. Most users won't know or think about it. |
Even with this JAWS setting, with JAWS 2021 and Chrome I only get aria-invalid=spelling, but not grammar |
@JAWS-test I got different results ... but I believe I had to restart JAWS. |
There are 2 possible ways to go with this (see the next 2 comments in this issue). |
|
|
See #1000 (comment) |
Option 1 seems pragmatic -- it works today, no need for any browser updates. I guess the question is whether having cleaner-looking markup is worth the extra work in the various browsers. I suspect the wait for Firefox, Chrome and Edge would probably be very short, because the update cycles are fast. Safari would be potentially a long wait. @cookiecrook would, option 2 cause Safari users to need to wait longer before this is supported? (Aka is the old markup supported now)? I'm personally ok with whatever the group decides on this. |
A primary concern are scenarios where overloading a single attribute creates complex processing for assistive technologies. For example, you can have spelling or grammar issues in a value that is valid. Keeping aria-invalid as boolean and limiting its applicability to inputs is simple for both authors and assistive technologies. It simplifies presentation for users. It is much easier to test. Input validation is really important, so unambiguous clarity is really valuable for authors, AT developers, and users. |
@mcking65 we don't expose it to ATs this way. We expose it as separate attributes. |
This is still an issue -- the spec says aria-invalid is not allowed on generic, but it needs to be for use with "spelling" or "grammar" values. This is common practice in rich text editors that implement their own spelling and grammar checking. |
In the ARIA call this morning, @jnurthen mentioned the Highlight API from w3c/csswg-drafts#6498 may be a reasonable replacement. |
need to add a note for the spec to indicate that while this is being deprecated globally, UAs shouldn't rush to remove the feature until a replacing feature has been provided by the spec. |
I don't think UA's should even remove the feature after a replacing feature
has been provided, at least not any time soon.
Unless they want to break rich text editors that don't update their
implementations.
…On Thu, Oct 21, 2021 at 1:35 PM scottaohara ***@***.***> wrote:
need to add a note for the spec to indicate that while this is being
deprecated globally, UAs shouldn't rush to remove the feature until a
replacing feature has been provided by the spec.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#989 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZTY5T3N7SFO24NVHNTUIBFMLANCNFSM4HRGV6YQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
See discussion at https://www.w3.org/2021/12/09-aria-minutes.html#t07 |
The original intention of aria-invalid="grammar" or "spelling" is unclear from the ARIA spec, although clear from CORE-AAM. So the two are not really in sync.
Reading the spec, one would not necessarily understand this use case:
This allows apps such as online word processors or email clients to implement their own server-based spelling and grammar checking, and expose that to screen readers. This was the original intention of this markup (I was there proposing it and implementing), but it's unclear from the spec text, which is unfortunate.
If you look at CORE-AAM, it has special lines for "grammar" and "spelling" so that the proper text attributes are exposed to screen readers. This matches the expected ATK/IA2 output here: https://wiki.linuxfoundation.org/accessibility/iaccessible2/textattributes
The text was updated successfully, but these errors were encountered: