Should Error descriptive really require the error to be in the accessibility tree? [36b590]

[WilcoFiers]

From: https://www.w3.org/WAI/standards-guidelines/act/rules/36b590/proposed/#failed-example-4

<form>
    <label for="age">Age (years)</label>
    <input type="number" id="age" value="0" />
    <span id="error" aria-hidden="true">Invalid value for age. Age must be at least 1.</span><br />
    <input type="button" value="Submit" />
</form>

While this is certainly a problem, I don't really think this is a 3.3.1 problem. Putting aria-hidden on anything that shouldn't be hidden is a failure of WCAG. I don't know why this would be a failure of 3.3.1, but if it was on for example a heading, that same problem would go under 1.3.1.

I feel like it might be good for us to revisit these and have a dedicated rule for using aria-hidden on things that shouldn't be hidden.

[Jym77]

3.3.1 states:

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

I would argue that in this case, the error is not "described to the user in text", at least not to all users (not to AT users); and therefore this is indeed a 3.3.1 error.

---

Thus said, I have nothing against a rule checking that aria-hidden is used correctly.

[giacomo-petri]

From 3.3.1 Understanding:

Screen reader users, for example, will not know there was an error until they encounter one of the indicators. They may abandon the form altogether before encountering the error indicator, thinking that the page simply is not functional.

It seems exactly this scenario. I think it might be helpful to keep this as a failure.

[Jym77]

CG call: write a rule to check that visible but aria-hidden stuff is indeed meant to be hidden, then revisit this issue.