Overlap between 3.3.1 and 4.1.2?

[patrickhlauke]

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 the aria-* 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?

[detlevhfischer]

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).

[patrickhlauke]

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...

[DavidMacDonald]

@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.

[mraccess77]

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.

[patrickhlauke]

@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?

[patrickhlauke]

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?

[mraccess77]

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.

[DavidMacDonald]

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

• 3.3.1 is met with static unassociated text.
• Regarding requiring an association under 4.1.2 (or 1.3.1) I think it's a little more squishy, because I've found it hard to get consensus on new formal WCAG 2.x failures based on advancements of technology since 2008, even though accessibility pros have been logging them (with good reason) as failures since they became mainstream.

[DavidMacDonald]

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.

[bruce-usab]

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.

[ghost]

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.

[lkmorlan]

Is support for aria-errormessage at the point where that could be the recommended solution?