WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: "Error feedback MUST be programmatically-associated with the appropriate element"

for

From: Birkir R. Gunnarsson
Date: Sep 25, 2020 8:26PM

This is part interpretation, part what I would term 4.6.2 (3.3.1 + 1.3.1)
The text for 3.3.1 says:

"Error Identification: 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."

So that is required, both identifying the erronious input and
describing the error in text.
Here's where the standard is showing its age, the understanding
document goes on to say:


"The identification and description of an error can be combined with
programmatic information that user agents or assistive technologies
can use to identify an error and provide error information to the
user. For example, certain technologies can specify that the user's
input must not fall outside a specific range, or that a form field is
required. Currently, few technologies support this kind of
programmatic information..."

This was true in 2008 when the specification was published, which is
why the most accessible error message mechanism people could come up
with was to put the error descriptions in a link at the top of the
form. Clicking the link took the user to the erronious input.

Now we have aria-invalid to mark an input as invalid, and
aria-describedby to programmatically associate the error message with
the invalid input. Both conditions are required by 3.3.1.
So I think this argument actually holds, that aria-invalid +
aria-describedby are required for an error message to pass 3.3.1.
Mind you, HTML5 validation lets the browser do both these things, if
an input fails browser validation it will do the equivalent
association e.g. type="email" or using the pattern attribute, a new
favorite of mine for form validation, though I had to brush up on
regular expressions.


Then there is 1.3.1. If you identify the error input visually and
place the error message next to it you've created a visual association
between the two. 1.3.1 says that information that is communicated
visually must also be made available programmatically or described in
text.
Describing it in text is tricky, unless you stuff the form field
label, which makes for a bad user experience, or resort to exposing
errors as links at the top of the form, which is worse usability for
low vision users and people with cognitive impairments.

So I say 4.6.2 covers it. ;)






On 9/25/20, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> On 25/09/2020 21:27, Jared Smith wrote:
>> This would instead generally fall under 1.3.1. If a visual association
>> between the error information and the relevant input is present, this
>> should also be programmatically defined - probably via aria-describedby
>> (and aria-invalid is a good idea too).
>
> A quick drive-by +1 from me on this - in the common cases where the
> error appears right next to/underneath/above the form field, I'd
> generally fail it if it's not associated (either via aria-describedby,
> or somehow part of the <label> for the field, or replicated verbatim in
> aria-label or similar).
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.