Moving ARIA2 technique from 3.3.3 and putting in 3.3.2; adding ARIA21 to 3.3.3

[mbgower]

Recommendation: ARIA2: Identifying a required field with the aria-required property is removed as a sufficient technique for SC 3.3.3, and added to SC 3.3.2.
As a second recommendation, ARIA21 should be added to 3.3.3.
Rationale:
SC 3.3.3 Error Suggestions is concerned with responding to a detected error in a user form interaction, while SC 3.3.2 Labels or Instructions covers providing guidance when content needs user input.

ARIA2: Identifying a required field with the aria-required property is more appropriate as a label or instruction technique to guide user input than as a technique only to be used in response to an error, which is what is currently implied (unless it is the WG's position that aria-required should only be set to true after a user has failed to fill in a required field).
For 3.3.3, a better aria technique to include would be ARIA21: Using Aria-Invalid to Indicate An Error Field.

[joshueoconnor]

I agree that ARIA 2 should be added to 3.3.2 but not that ARIA 2 should be removed from 3.3.3.

[joshueoconnor]

Adding ARIA2 to SC 3.3.2 - 1e83c62

[joshueoconnor]

Update to ARIA 2 - applicability to 3.3.2 848a9f1

[joshueoconnor]

the question around the second recommendation.. ARIA21 should be added to 3.3.3..remains. My 2 cents are that I think it is fine relating just to 3.3.1 - as it acts as a basic flag that there is an error - and 3.3.3 is around error suggestion. I do wonder if these SCs should be merged.

[mbgower]

Getting ARIA2 as part of 3.3.2 was the more critical part of this, so glad it is being put in place. On the other parts of this, it seems to me if the decision is made to leave ARIA2 in 3.3.3, then it should reside in 3.3.1 as well. 3.3.1 certainly talks about required fields...
But for both 3.3.1 and 3.3.3, I've always thought of them as covering techniques that are set in response to a detected error. I guess it's conceivable that someone would wait until after a user misses a field to mark ariai-required as "true", but it seems a little unusual. So I would argue it either should be in both 3.3.1 and 3.3.3 or neither. I guess maybe the counter argument is that aria-invalid just flags an error, so ARIA21 goes in 3.3.1, while aria-required flags an error and what is needed to fix it, so ARIA2 resides in 3.3.3?

[mraccess77]

This comes back to the age old question is required status mandated before the user gets an error message or only after. The technique can be used in either -- but I don't think we have come to a conclusion on whether it's a failure to not include the required status as something you don't know a field is required until the user has filled out another field.

[mbgower]

I decided to look at the oldest issues in WCAG to see if any could be closed. The oldest one is mine!

Looking at this again, with 8 more years perspective, I still believe the first part of issue has merit.

1. ARIA2 as a sufficient technique for 3.3.3 Error Suggestions continues to seem wrong-headed to me. Why would one wait until an error is detected to apply aria-required? And how is assigning "required" really a suggestion? I would continue to advocate it be removed.
2. I don't think using aria-invalid is much more appropriate for error suggestions than aria-required. Neither of them really tell the user how to resolve the error, which is the core purpose. So, I think my second (or third, depending on how you count this) recommendation should be ignored.
3. Is assigning a role of "required" an instruction? I think a case can be made that aria-required helps meet 3.3.2 (instructions are provided).

In any case, applying the usual rubric that 'it's been in place for over 15 years; does it really matter?' makes me feel like this isn't really worth pursuing in any case.

If we cannot get traction on removing ARIA2 from 3.3.3, I'm inclined to close this.

[patrickhlauke]

a counterpoint to the

'it's been in place for over 15 years; does it really matter?'

part is that I, and I'm sure many other accessibility practitioners, have utterly ignored any techniques in WCAG over the last 15 or so years, exactly because many of them seem slightly flawed, incomplete, or just old, being guided instead just by the normative wording first and foremost, and a bit of the understanding interpretation (and even then taking that with a pinch of salt).

keeping techniques that we don't quite feel right about out there since "they've done no harm so far regardless" just guarantees that folks will continue to ignore them.