Consider deprecating aria-errormessage due to existence of aria-describedby

[sivakusayan]

@aleventhal started a discussion in the Chromium slack regarding whether aria-errormessage is really needed when aria-describedby is already available.

I tracked down the origin of aria-errormessage to ISSUE-651: Allow aria-invalid to specify more types of errors including custom errors. It seems that it was originally added to ensure screen readers on Apple operating systems would read an error message more readily. Aaron pointed out that an alternative is to prioritize reading the description if aria-invalid was true, potentially making aria-errormessage markup bloat.

I'm opening this issue to gather feedback from the working group, or anyone else who might care. Aaron already expressed that he would be in favor of deprecating aria-errormessage, but I'll let him clarify in case I misrepresented his points.

---

Just to add some thoughts:

• I wonder if there is value in keeping the errors separate from the description. For example, what if a screen reader user wants to configure their screen reader to ignore descriptions, but communicate errors?
• UIA does not have a clean mapping for aria-errormessage at this time. There isn't an obvious path forward I'm aware of unless UIA is extended, or browsers start exposing another custom attribute separate from AriaProperties, or the hacky approach I proposed in the linked issue is considered (granted, I'm not too familiar with UIA).
• The other major accessibility APIs do have well-defined mappings for aria-errormessage, on the other hand. I'm not sure how much error message semantics are used in native apps, but deprecating this attribute will make it so websites cannot define semantics available to native applications.

[jnurthen]

IMO the whole point of aria-errormessage is that it should be read by screen readers even when set to verbosity levels when aria-describedby would not normally be read. I guess aria-invalid could be used as suggested above but in the case where there is both a valid description AND an error message for the same field we would end up reading a description that the user has requested should not be read.

[aleventhal]

I like the idea of using the invalid state as the clue to force reading of aria-describedby. It doesn't have to be aria-invalid, but any invalid state for the field, right? https://css-tricks.com/almanac/selectors/i/invalid/

When conducting interviews for accessibility roles, I often ask how to mark up forms for good a11y. None of the candidates knew about aria-errormessage … It was aria-describedby all the way for form error messages. Anecdotal, but it seems like the awareness isn't there.

[jnurthen]

Part of the reason for its lack of usage is that aria-errormessage just isn't as reliable today. If we can fix that part then it really does seem like a better solution. I recall that in the meeting @cookiecrook stated that MacOS supports these 2 distinct concepts.

Could aria-errormessage map to aria-describedby and aria-invalid="true" on platforms that don't currently support it? Would this be a good interim solution? (probably not but thought I'd throw it out there)

[sivakusayan]

Could aria-errormessage map to aria-describedby and aria-invalid="true" on platforms that don't currently support it? Would this be a good interim solution? (probably not but thought I'd throw it out there)

That idea was brought up to fix the UIA mappings. I think that could make sense, but I wonder if it would be confusing to have description calculation be different depending on the accessibility API, instead of it being the same for each API.

Edit: In case anybody is curious about support, this is what I found the last time I touched this area (July 2023):

• JAWS supports multiple IDREFs in aria-errormessage
• NVDA does not support aria-errormessage, and the issue hasn't seemed to gain traction.
• VoiceOver does not support aria-errormessage
• Orca supports one IDREF in aria-errormessage (I can file a bug for this if the WG wants to keep this attribute)
• Talkback will (probably?) respect aria-errormessage once a browser implements it, although it needs to pass a text string rather than node references like other accessibility APIs. Chromium seems to populate AccessibilityNodeInfo::setError() to make sure Talkback reads out grammar errors in input fields, and it can hypothetically be leveraged here, too.

[sivakusayan]

Similar discussion from a couple years ago: https://github.com/w3c/aria/issues/128

[MarioBatusic]

IMO it is very useful for screen readers to have a distinction between descriptions, that could be muted by user option and an error message that cannot be so. But is there hope and possibility that all AAPIs and screen readers iplement the spec?

[BogdanCerovac]

Just adding another vote for against deprecation here. And adding another argument of why we should keep the aria-errormessage (and hope that it will be soon enjoy wider support as well);

Thanks to Adrian Roselli that opened the aria-description not exposed directly to VO users and "aria-describedby content hidden behind new interaction" bug 262895 for WebKit where I could also learn from James Craig about the platform implementation differences that caused the issue.

This has direct impact also on aria-errormessage as we can now see that perhaps aria-describedby shouldn't be used to expose field error messages and is only used for that because it was more supported and robust.

And situation with aria-describedby is not potentially directly related to the "what if a screen reader user wants to configure their screen reader to ignore descriptions, but communicate errors" mentioned in the opening comment...

[Adriani90]

Actually, is aria: alert role not already doing the same thing? I think aria describedby still suffers from lack of support when using NVDA in browse mode and the aria describedby is set on a grouping. See for example this issue: https://github.com/nvaccess/nvda/issues/12718

On the other hand, aria alert suffers from several bugs in NVDA, lots of cases where the focus is not properly handled in browse mode or many situations where reporting of "alert" interputs the reporting of the alert content itself or many cases where alert is not announced at all. see for example this issue: https://github.com/nvaccess/nvda/issues/14990

Maybe we should join forces and improve support for aria alert role in screen readers and browsers, then we would not need the errormessage role. I think most web developers work with alert role anyway right? Aria describedby is often used to rather indicate what is expected i.e. before filling a form, while role alert would give the user indications what went wrong after filling the form. So in my view both make sense.

[scottaohara]

marking something as an alert doesn't associate it with the form control in question.

Maybe we should join forces and improve support for aria alert role in screen readers and browsers, then we would not need the errormessage role. I think most web developers work with alert role anyway right?

aria-errormessage is not a role, it's an attribute to identify the content that describes the error for the form control in question.

So different things that 'could' work together, but alert is out of scope for this specific conversation.

[BogdanCerovac]

@Adriani90 - as @scottaohara already wrote - aria-errormessage is attribute "connecting" form field with error message.

When screen-reader user navigates to the field that is marked as invalid (with for example aria-invalid="true"), screen reader also announces that field is invalid and uses aria-errormessage "connected" text as the error message.

aria-errormessage is in my opinion ideal for developers that can use it to explicitly "connect" error message with field and it only gets exposed if field is invalid. Really wish it will be soon supported and not deprecated. It's sad seing it in new products where developers didn't check the support and trusted it's there...

It also allows live regions (same message can have role="alert", for example), and it also allows additional aria-description or aria-describedby that can be used for other purposes (and we get the separation of error messages and descriptions, so that we can also implement logic in the screen readers to always read out error messages, but not descriptions (if user prefers that).

Live regions (like alert) used to communicate errors in complex forms are in my experience sometimes problematic for end users because they can be overheard (or "overwritten" by other alerts that may happen at the same time - I had experience with complex form that had a chat and another live region and it was a giant mess). But yes, that's another topic :)

[Adriani90]

FYI, NVDA supports now aria errorMessage as per https://github.com/nvaccess/nvda/pull/16411 This will ship with NVDA 2024.3 in stable but it is already in alpha.

[Wildebrew]

aria-errormessage is significantly different from aria-describedby The content of elements referenced with aria-describedby are always announced, regardless of their visible status. (it doesn't matter how you hide them, aria-describedby causes them to be announced). This is good for instructions, tooltips, and other static descriptive text, but it's bad for conditional announcements such as error messages. Authors often put error messages into the HTML template for a form but display them only when there is an error. If you are to use aria-describedby for this you have to use Javascript to add and remove the aria-describedby attribute based on the visibility of the error message. If they don't, and this happens quite often, the screen reader user hears the error messages regardless of whether the form control is in error or not.

With aria-errormessage, you can build the association into the form template and activate the error message screen reader announcement by setting aria-invalid="true" on the invalid form control. (in most browsers this is automatically done for you if the form control fails HTML5 form validation e.g. required fields left blank).

This makes error message association easier, you don't need Jatascript to constantly juggle the aria-describedby values. You can also set the visual display of the error message to the aria-invalid attribute so you can ensure error message association is tied to visibility. There are the other things too, e.g. preventing screen reader users from accidentally turning offf error message announcements through verbosity settings. Screen readers can automatically announce error messages before aria-describedby references, so when an element has both you no longer have to juggle the order of id attributes in the aria-describedby value. A screen reader can implement earcons to identify error messages, etc.

[aleventhal]

Birkir, these do sound like a value add to me.

As a browser developer, I'm wondering if this all works consistently across environments. Does anyone know? What testing has been done?

On Thu, Jun 13, 2024 at 9:26 AM Birkir Gunnarsson @.***> wrote:

aria-errormessage is significantly different from aria-describedby The content of elements referenced with aria-describedby are always announced, regardless of their visible status. (it doesn't matter how you hide them, aria-describedby causes them to be announced). This is good for instructions, tooltips, and other static descriptive text, but it's bad for conditional announcements such as error messages. Authors often put error messages into the HTML template for a form but display them only when there is an error. If you are to use aria-describedby for this you have to use Javascript to add and remove the aria-describedby attribute based on the visibility of the error message. If they don't, and this happens quite often, the screen reader user hears the error messages regardless of whether the form control is in error or not.

With aria-errormessage, you can build the association into the form template and activate the error message screen reader announcement by setting aria-invalid="true" on the invalid form control. (in most browsers this is automatically done for you if the form control fails HTML5 form validation e.g. required fields left blank).

This makes error message association easier, you don't need Jatascript to constantly juggle the aria-describedby values. You can also set the visual display of the error message to the aria-invalid attribute so you can ensure error message association is tied to visibility. There are the other things too, e.g. preventing screen reader users from accidentally turning offf error message announcements through verbosity settings. Screen readers can automatically announce error messages before aria-describedby references, so when an element has both you no longer have to juggle the order of id attributes in the aria-describedby value. A screen reader can implement earcons to identify error messages, etc.

— Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/2048#issuecomment-2165671621, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZTBNSXN3ZZPBIGCWZ3ZHGMWXAVCNFSM6AAAAAA5G777H6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGY3TCNRSGE . You are receiving this because you were mentioned.Message ID: <w3c/aria/issues/2048/2165671621 @.***>

[ITenthusiasm]

@aleventhal, I've been using https://a11ysupport.io/tech/aria/aria-errormessage_attribute to keep track, though its tests seem a little outdated.

I am also waiting for the glorious day when aria-errormessage is supported, as it will allow me to make some improvements to my FormValidityObserver library tool.

[aleventhal]

Wow! That's the first I've seen a11ysupport.io. As a browser developer, this is a goldmine.

On Fri, Jul 5, 2024 at 8:05 AM Isaiah Thomason @.***> wrote:

@aleventhal https://github.com/aleventhal, I've been using https://a11ysupport.io/tech/aria/aria-errormessage_attribute to keep track, though its tests seem a little outdated.

I am also waiting for the glorious day when aria-errormessage is supported, as it will allow me to make some simplifications to my FormValidityObserver https://github.com/enthusiastic-js/form-observer/blob/main/docs/form-validity-observer/README.md library tool.

— Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/2048#issuecomment-2210757201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZW7RRE2APWSY5TN5ODZK2DZNAVCNFSM6AAAAAA5G777H6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJQG42TOMRQGE . You are receiving this because you were mentioned.Message ID: @.***>

[BogdanCerovac]

NVDA support has landed to stable NVDA (https://github.com/nvaccess/nvda/issues/8318 🥇).

As far as I know the only one missing aria-errormessage now is Talkback (please correct me if I am wrong, just tested quickly).

I opened a bug report in Android public tracker (as aria-invalid doesn't work and is prerequisite for aria-errormessage to work, I joined both in same ticket); https://issuetracker.google.com/issues/361595175

Hopefully we will land on universal support and could finally use aria-errormessage as it was intended 🤓.

[GraemeHedges]

I'd like to add my voice to those against deprecation.

aria-errormessage in conjunction with aria-invalid presents a very clean way of closely aligning our visual error messaging with our accessibility handling (the example in mdn web docs does just that). Personally I really like to use that kind pattern because it really reinforces accessibility as a core consideration when creating UI.

Using aria-describedby is a poor substitute for a specific error handling implementation that now has wide support from almost all screen readers.