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

[aleventhal]

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]

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]

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]

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]

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

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

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]

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

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

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

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]

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

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

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