Open patrickhlauke opened 5 years ago
Same thing with 4.1.3 and 4.1.2: A status message lacking role=status or aria-live could fail just 4.1.3 or also 4.1.2 (where I would have failed it previously).
in the case of 4.1.2 and 4.1.3, i can kind of see the distinction here, as 4.1.2 is about user interface components (generally controls), whereas a status is often non-interactive so arguably not a user interface component...
but yes, conceptually, i agree. would be good to get it clarified, even if just with a note...
@patrickhlauke I've been assigned this issue. Here's a proposed [unapproved] response:
Historically there was not a way to associate an error message with its corresponding input (under 4.1.2). So, when WCAG 2.0 first came out a pass of 3.3.1 was simply providing an error message either at the top of the page or near the input. There was no aria-invalid
and aria-derscribedby
back then. The working group at the time didn't intend more than that. WCAG SC 3.3.1 requires that error messages be presented in text and nothing further.
There is a justification under 4.1.2 that when a way to provide a programmatic relationship became available and was accessibility supported that there is a positive obligation to do so given both aria-describedby
and aria-invalid
provide information about the state and properties of the input. WCAG was intended to be able to apply to new technologies that became accessibility supported. The Success Criteria were never meant to be limited by the technology available when WCAG was released.
We think however that we should wait until there is better accessibility support for aria-errormessage
, which would be the more correct way to do this, before formalizing this as a failure technique as aria-describedby
is still an interim solution.
PERSONAL NOTE: I log an issue failure of 4.1.2, in my reports when there are missing aria-invalid
and aria-derscribedby
on error messages.
I agree that an error message that is inline would need to be associated with the field in error. Whether it would be a failure to also require aria-invalid in addition to the error messages if the error message clearly stated "error" is something I'm not convinced of as SC 1.3.1 can be met through text and the associated text communicates that. That is -- use of certain wording like "error" or "invalid" in the associated text would mitigate the hard requirement for aria-invalid. However, if the associated message didn't contain a term indicating error then aria-invalid would be required.
@DavidMacDonald thanks, you provide a lot of context there...but i think my core answer remains unanswered still: if you have an error in text next to an input, but have not associated it...can you pass 3.3.1 but fail 4.1.2? and if that's the case, should the techniques focusing on aria be removed from 3.3.1 understanding and keep it purely focused on the text side of things, without suggesting that aria association/programmatic association is required for 3.3.1? they're certainly related, but not necessary...it could just be text that's not associated programmatically at all?
I agree that an error message that is inline would need to be associated with the field in error. [...] if the associated message didn't contain a term indicating error then aria-invalid would be required.
i don't dispute that, but the question is: under which SC? is it a fail under 1.3.1, 3.3.1 and 4.1.2? or just 1.3.1? or 4.1.2?
In my opinion not SC 3.3.1. Generally SC 1.3.1 would be the best place for aria-describedby errors. aria-invalid might be a possibility under SC 4.1.2 as well -- but SC 1.3.1 would seem to cover it sufficiently. There have been many times where I have failed both in situations because there is crossover though so I wouldn't fault someone for including it under both. So to answer David's question -- yes, you can meet 3.3.1 by just putting error text on the screen without association.
NOTE: this is just me discussing, not a proposed response
So to answer David's [I think you mean @patrickhlauke ] question -- yes, you can meet 3.3.1 by just putting error text on the screen without association.
I agree
but the question is: under which SC? is it a fail under 1.3.1, 3.3.1 and 4.1.2? or just 1.3.1? or 4.1.2?
There is a ton of overlap between 1.3.1 and 4.1.2. Personally, I tend to fail standard HTML components under 1.3.1 and custom components under 4.1.2 but I think it's perfectly legit in either place.
I tend to fail standard HTML components under 1.3.1 and custom components under 4.1.2 but I think it's perfectly legit in either place.
I would argue that is this is very sensible approach that we should promote as a best practice. 4.1.2 includes the explicit caveat about standard elements meeting SC 4.1.2. Also, the original context, and all techniques, associate with 1.3.1 are all about correct use of standard elements.
If errors are detected, my view is that 3.3.1 can pass if errors provided in text and that there is some call-to-action, such as an alert or moving focus. They don't then have to be hooked up.
But as the structure visually communicates that the errors are connected to the input fields, I'll fail 1.3.1 Info and Relationships if aria-describedby
isn't being used (unless it is not needed).
I am aware that there is an advisory technique for this, ARIA1. But I think there is a difference between instructions (nice-to-know) and errors (necessary-to-know).
As per the above point, I'll usually do this with standard, native form fields. I may use 4.1.2 if it is a custom component, however this has been much rarer, in my experience.
Is support for aria-errormessage
at the point where that could be the recommended solution?
Generally, when encountering issues where a form error was visually present, but not associated programmatically with a form field, and the form field lacked something like
aria-invalid="true"
, I tend to pass 3.3.1 but fail under 4.1.2. However, I see in https://www.w3.org/WAI/WCAG21/Understanding/error-identification.html that a lot of the sufficient techniques focus on thearia-*
side of things.So, just want to get a sense: do people generally fail situations like a lack of
aria-invalid
and lack of association (e.g.aria-describedby
or similar) between visible error text and form field an issue of just 4.1.2, or 3.3.1 AND 4.1.2? And if the latter, should the understanding document contain a note or similar reminding auditors that these situations would also cause a 4.1.2 failure?