Erroneous aria-live announcements and WCAG

[mfairchild365]

If an aria-live announcement is made in error, does it fail WCAG? For example, there is an aria-live announcement, made at random, describing an error associated with a form on the page. But there is no visual notification of that error… and that error doesn’t really exist. It was just randomly triggered.

If so, which SC does this fail?

[patrickhlauke]

sounds like a general bug, rather than something to hang off of WCAG

[JAWS-test]

More generally, one could also ask whether information that is not visually present but is output programmatically (whether via live region or not, whether error message or not) is a violation of WCAG. I would say yes, SC 1.3.1 requires all visual information to be available programmatically. Conversely, this could also mean that things that are not visually available are not programmatically available. However, in my opinion this is not clearly stated in the understanding of 1.3.1 and could be added.

[patrickhlauke]

Conversely, this could also mean...

WCAG SCs are not "commutative" in this way, no. By saying "if it's not visually present but announced by SRs, then it fails" you've immediately made text alternatives and any other additional hint/live region/etc done for SRs invalid...

[JAWS-test]

@patrickhlauke My point was about information that is obviously wrong or superfluous. An alternative text of a picture never belongs to it, since the picture is visually present - thus it is clear that there must be a textual equivalent for the picture (for it there is even a separate SC: 1.1.1).
There is an instruction in SC 1.3.1, at least with regard to the semantic structure, not to use any additional or incorrect structures, see F43 and F46. It is not clear to me why this should not also apply to content.

[alastc]

not to use any additional or incorrect structures

I read that as not using structural markup for presentation purposes (in conflict with the meaning of the structure).

I agree with Patrick, it's a bug, but not a fail of WCAG.

[mfairchild365]

Is this something that a future version of WCAG should address?

[patrickhlauke]

@mfairchild365 to me, that would reinforce the fact that "accessibility is somehow special and separate". if a website showed (visually) a wrong notification/toast/message, that would be a regular bug ... but if it does it for AT users, oh no...that's a WCAG failure!

[JAWS-test]

if a website showed (visually) a wrong notification/toast/message, that would be a regular bug ... but if it does it for AT users, oh no...that's a WCAG failure!

That's exactly what lack of accessibility is: bugs for people with impairments. If normal bug-fixing would also fix all accessibility problems, there would be no need for WCAG. I would still see a violation of 1.3.1 here.

[mfairchild365]

@mfairchild365 to me, that would reinforce the fact that "accessibility is somehow special and separate". if a website showed (visually) a wrong notification/toast/message, that would be a regular bug ... but if it does it for AT users, oh no...that's a WCAG failure!

Sorry, I'm not following. If a wrong notification/toast/message was visually displayed, that content is still in the scope of WCAG and needs to be accessible, even if it is there because of a bug. The UX solution would be to remove the notification entirely, but WCAG states that if the content is there, it needs to be accessible.

If an aria-live message is erroneously provided without a visual counterpart, it can disproportionately and negatively affect people with disabilities (if it doesn't reflect reality, is generally unhelpful/confusing, or interruptive). It could also disproportionately advantage people with certain disabilities (if the message could be helpful for everyone). Because of this, allowing aria-live messages that don't reflect the visual experience might hint that "accessibility is somehow special and separate."

[patrickhlauke]

Sorry, I'm not following. If a wrong notification/toast/message was visually displayed, that content is still in the scope of WCAG and needs to be accessible, even if it is there because of a bug.

so which SC would you fail an erroneous visual notification under? a reverse 3.3.1 Error Identification (noting again that I would posit SCs are not commutable in this way)? and if it wasn't a notification specifically about an error as such, just a general notification that's incorrect?

[patrickhlauke]

My point is you either make these scenarios (both visual and aria-live/AT announcements that aren't right) failures in general somehow - which sounds tricky to normatively pin down... "Make sure that notifications/errors aren't incorrect/wrong?" - or you make it a special case just when the AT equivalent is wrong, which seems ... odd.

[mfairchild365]

Sorry, I'm not following. If a wrong notification/toast/message was visually displayed, that content is still in the scope of WCAG and needs to be accessible, even if it is there because of a bug.

so which SC would you fail an erroneous visual notification under? a reverse 3.3.1 Error Identification (noting again that I would posit SCs are not commutable in this way)? and if it wasn't a notification specifically about an error as such, just a general notification that's incorrect?

That’s not what I’m suggesting. I think we are talking past each other and continuing this line of thought would not be constructive.

[mfairchild365]

My conclusion from this thread is that this is not covered by WCAG. There may be opportunity to address this gap in the future, such as in WCAG 3, but there are valid questions about the feasibility of that, and even if it is desirable to do so.

[melaniephilipp]

@patrickhlauke you said:

or you make it a special case just when the AT equivalent is wrong, which seems ... odd.

But isn't that what many SC's are about? Accessibility / WCAG is not just about information missing for people who use AT, but it is also about incorrect information being conveyed to AT. Wrong alt text, wrong semantics, wrong accessible names, etc. Those all are "special cases just when the AT equivalent is wrong" while the visual is correct are they not? So it isn't a leap to think that a wrong aria-live region announcement is also an accessibility issue.

If WCAG 2.x doesn't cover erroneous, misleading aria-live region announcements (which I concede it doesn't), suggesting that WCAG-future cover it is well in line with the intent of our accessibility guidelines.