Spec is unclear on aria-invalid="spelling" | "grammar" uses

aleventhal commented 5 years ago

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:

<div contenteditable spellcheck="false">
  <p>The evil <span aria-invalid="spelling">grammur</span> dictators are on <span aria-invalid="grammar">you're</span> back today!</p>
</div>

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

jnurthen commented 5 years ago

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'd like to see 2 things to improve the situation:

usage examples somewhere in the Authoring Practices
a PR for clearer spec text (I'm unsure what would need changing as I'd assume I could do the example above based on the current spec text)

aleventhal commented 5 years ago

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? :)

carmacleod commented 3 years ago

The spec for aria-invalid says:

If the value is computed to be invalid or out-of-range, the application author SHOULD set this attribute to true.

and then the possible values are listed in the Values table:

Value	Description
grammar	A grammatical error was detected.
false (default)	There are no detected errors in the value.
spelling	A spelling error was detected.
true	The value entered by the user has failed validation.

Agreed that the initial sentence in the prose should change to allow for values other than true. How about:

If the value is computed to be invalid or out-of-range, the application author SHOULD set this attribute to grammar, spelling or true.

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:

Application authors SHOULD provide suggestions for corrections if they are known.

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:

For future expansion, the aria-invalid attribute is an enumerated type. Any value not recognized in the list of allowed values MUST be treated by user agents as if the value true had been provided.

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:

The aria-invalid attribute is an enumerated type. For future expansion, any value not recognized in the list of allowed values MUST be treated by user agents as if the value true had been provided.

aleventhal commented 3 years ago

@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.

carmacleod commented 3 years ago

@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:

When the user attempts to submit data involving a field for which aria-required is true, authors MAY use the aria-invalid attribute to signal there is an error. However, if the user has not attempted to submit the form, authors SHOULD NOT set the aria-invalid attribute on required widgets simply because the user has not yet entered data.

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 aria-invalid from a global attribute to one that is only supported on certain roles is messing up allowing for the spelling and grammar values.

So... how should we fix this? Do any ATs actually handle aria-invalid on a span? Should we consider making it global again? Or do we allow it on role="generic"? Or are you perhaps angling for a new role that you can put on your spans? :) (Here we go with role="static/text" again! 😂 )

JAWS-test commented 3 years ago

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 <span>.

Tested with Chrome at https://codepen.io/jaws-test/pen/eYdoLeb

aleventhal commented 3 years ago

@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.

JAWS-test commented 3 years ago

@aleventhal I only have JAWS 2020. For contenteditable, only aria-invalid=spelling is correctly detected by JAWS, but not aria-invalid=grammar. NVDA recognizes both correctly

aleventhal commented 3 years ago

@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! :)

JAWS-test commented 3 years ago

Actually, aria-invalid=true/false and spelling/grammar are two quite different things that are hard to fit into one attribute:

true/false: should only work for form fields and affects the validation of a form. Works in combination with aria-errormessage
spelling/grammar should work on text (single words or groups of words), whether in a form field or not. It should not work on a form field itself. And it has nothing to do with validation of a form, because I can submit a form even with errors related to grammar and spelling. Does not work in combination with aria-errormessage

JAWS-test commented 3 years ago

@aleventhal

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

aleventhal commented 3 years ago

@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.

aleventhal commented 3 years ago

@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. The setting is under "Proofing" and is called "Grammar and Advanced Proofing".

JAWS-test commented 3 years ago

The setting is under "Proofing" and is called "Grammar and Advanced Proofing".

Even with this JAWS setting, with JAWS 2021 and Chrome I only get aria-invalid=spelling, but not grammar

aleventhal commented 3 years ago

@JAWS-test I got different results ... but I believe I had to restart JAWS.

carmacleod commented 3 years ago

There are 2 possible ways to go with this (see the next 2 comments in this issue). The group decided to take a straw poll to see if there's a clear choice. Please read the next 2 comments, and give them your 👍 or 👎.

carmacleod commented 3 years ago

Put aria-invalid back to global, and carefully word the prose to say that aria-invalid="true" and "false" are only allowed on form control related roles.

carmacleod commented 3 years ago

Create a new global attribute, for the sake of discussion call it aria-incorrect, that can have values of "spelling" and/or "grammar" in a token (or token list, if that would be useful). Restrict aria-invalid values to "true" and "false", and keep it as only supported on form control related roles.

JAWS-test commented 3 years ago

See https://github.com/w3c/aria/issues/1000#issuecomment-505089305

aleventhal commented 3 years ago

Option 1 seems pragmatic -- it works today, no need for any browser updates. Option 2 is nice and clean - it's cleaner, prettier markup, but it's a bit more work and adds yet another attribute.

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.

mcking65 commented 3 years ago

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.

aleventhal commented 3 years ago

@mcking65 we don't expose it to ATs this way. We expose it as separate attributes. Keep in mind too, that it's been this way for a long time.

aleventhal commented 3 years ago

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.

cookiecrook commented 3 years ago

In the ARIA call this morning, @jnurthen mentioned the Highlight API from https://github.com/w3c/csswg-drafts/issues/6498 may be a reasonable replacement.

scottaohara commented 3 years ago

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.

aleventhal commented 3 years ago

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 https://github.com/w3c/aria/issues/989#issuecomment-948852899, 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.

jnurthen commented 2 years ago

See discussion at https://www.w3.org/2021/12/09-aria-minutes.html#t07

w3c / aria

Spec is unclear on aria-invalid="spelling" | "grammar" uses #989