Deprecation of aria-invalid as a Global property and proposed Introduction of aria-MarkedType/aria-markType

[HaTheo]

I would like to raise a few related issues and propose a set of solutions to address them.

Issue 1: Confusion caused by deprecation of aria-invalid

Description:

The deprecation of aria-invalid as a global entry point has caused confusion among developers.

The current note states:

"Note: This state is being deprecated as a global state in ARIA 1.2. In future versions, it will only be allowed on roles where it is specifically supported."

Many mistakenly believe that the deprecation implies that aria-invalid is invalid ARIA (in that the value should be removed from support by user agents), when in fact it is only discouraged ARIA. This misunderstanding can lead to the incorrect assumption that people should avoid its usage altogether and a fear that there is no way for rich authoring applications to identify spelling or grammatical errors.

Solution:

To help fix this misunderstanding, I am encouraging the addition of a note indicating what the deprecation means in the context of aria-invalid, and special notes to User agents encouraging the continued support for aria-invalid to indicate spelling or grammatical errors.

Such a note might read something like: "Note: The attribute aria-invalid has been deprecated from usage in the WCAG guidelines. This means that while its usage is discouraged, user agents should continue to support it as aria-invalid has a long history of usage by authors outside of form fields to indicate spelling and grammatical errors. Authors should take the availability of other alternative methods, if one supported by applicable user agent, into consideration when making the choice to use aria-invalid. Use of CSS Highlighting with type "spelling-error" or "gramatical-error" is an applicable alternative, but might not work for all use cases."

Issue 2: Plain HTML alternative to Aria-Invalid to mark up spelling grammatical errors and other types of editorial suggestions

Description:

As we have deprecated the use of aria-invalid as a global property to encourage more predictable and consistent usage of aria-invalid and we encourage the usage of CSS highlighting a feature that is applied programmatically through JavaScript on to a range of text, there is no plain HTML or CSS+HTML way to indicate spelling or grammatical errors. This means that authors of HTML content must use JavaScript if they are to move away from the usage of aria-Invalid on spans of text with spelling or grammatical errors.

Solution:

As a solution, I would like to propose a new property called aria-markedtype. This property could be used on elements with the role="mark", or who use the mark tag initially but could be expanded to support other elements in the future for the case of authoring of non-text content. This would provide a clear and unambiguous way to indicate the type of marker being used, and provide a solution for the deprecation of aria-invalid as a global property for those who wish to use CSS/HTML alone. Such a property would take a set of fixed values "Highlight"(default for role="mark" elements or mark elements), "spelling-error", "grammar-error", or a custom marker type as defined by the usage of a string bearing the name of the type i.e. "Inclusive language" to be used on platforms such as in UIA where custom annotation/marker types are allowed and used.

Issue 3: CSS-Highlighting not clearly documented in AAM

The following issue is just a marker to an issue filed in the Core-AAM. This error appears here: https://www.w3.org/TR/wai-aria-1.2/#aria-invalid

[spectranaut]

Plan to discuss this on April 25th.

[spectranaut]

Discussed in today's ARIA meeting: https://www.w3.org/2024/04/25-aria-minutes.html#t05

[spectranaut]

One out come of this discussion is to create a CSS-AAM, which @jnurthen and I will look into in the end of May