Description
While reviewing #1914, I was also looking at Error message describes invalid form field value and feel there are ways we can improve the rule, also following some guidelines we've clarified since it was written…
As far as I remember some discussions, the idea is that the rule should be tested in the snapshot of the page where the error shows (rather than include manipulations of the page to trigger the error). Essentially because ACT rules are designed for static snapshots and we struggle a bit to correctly define interactions and change of states…
From here, I think we can restrict the Applicability to fields with aria-invalid="true" (plus an Assumption that this is correctly used). This would let us get an Expectation that "A form field error indicator is shown" (or we make a new rule just to check that), and the exception in the other expectation make more sense.
"Form field error indicator" cannot really be made objective, so cannot be used in the Applicability. But maybe we could restrict the definition to stuff like: the form field + its programmatic label + nodes used in its accessible name and description + element referred by aria-erromessage. This would be a "programmatic error indicator" or something like than. Then it could be used in Applicability. So we could have this rule targeting form fields that are errored (= aria-invalid) and have a programmatic indicator; then expectations would look at the programmatic indicator and decide whether one of them describe the error or not.
The lack of programmatic indicator might not be a 3.3.1 failure 😞 So we probably can't make a rule to check that (plus, if the label is possibly part of the error indicator, then it is just a subset of not having a label and we don't care…)
Another easy improvement is to use aria-errormessage in the examples rather than aria-describedby.
Ping @carlosapaduarte @WilcoFiers since you wrote the rule.