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)

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:

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:

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.

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

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! 😂 )

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

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

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

• 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

@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

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

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

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

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

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

See #1000 (comment)

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.

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.
Keep in mind too, that it's been this way for a long time.

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.

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