Erroneous aria-live announcements and WCAG #3832
Replies: 17 comments
-
|
sounds like a general bug, rather than something to hang off of WCAG |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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... |
Beta Was this translation helpful? Give feedback.
-
|
@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). |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
Is this something that a future version of WCAG should address? |
Beta Was this translation helpful? Give feedback.
-
|
@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! |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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." |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@patrickhlauke you said:
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. |
Beta Was this translation helpful? Give feedback.
-
|
but that starts with the assumption that only the AT version will be wrong and is an accessibility issue, while an erroneus notification that is visible..isn't somehow? it's lopsided and special-cases this for AT users while the other is either assumed to always be correct, or that the impact it has on non-AT users is not an accessibility issue. On 13 Sep 2023, at 00:15, melaniephilipp ***@***.***> wrote:
@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.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Would be a visible error message that
not a violation of WCAG 3.3.1 and 3.3.3? |
Beta Was this translation helpful? Give feedback.
-
|
This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list. |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions