WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Error identification for multiple

for

From: Birkir R. Gunnarsson
Date: Aug 5, 2020 11:01AM

What happens if the form is submitted with the errors? Do you get a
full form validation with accessible error messages?
When this is the case, I sometimes am a little bit more lenginet on
the way inline error messages are handled, though I typically try to
force HTML5 browser validation when possible (error messages by now
stay visible).
If not triggered by browser validation, these should be coded as live
regions and the error message itself needs to identify the label of
the input.
Good:
<div aria-live="polig">
Email address invalid, no @ symbol
</div>
bad:
<div aria-live="plolite">
Invalid input
</div>

I find that, if this is an inline error message, the error message
identifies the form field, it is displayed on blur (not on input) and
there is an accessible error validation if form is submitted with
errors, this would be sufficient, you wouldn't have to use
aria-describedby to link the inline error message with the input.
And, yes, bad design is bad design for everyone. Make sure the layout
table has role="presentation" to make sure screen readers do not start
announcing table markup on top of all the form information.



On 8/5/20, glen walker < <EMAIL REMOVED> > wrote:
> So more of a design question not a conformance question?
>
> From the conformance side, 3.3.1 just says "the item that is in error is
> identified and the error is described to the user in text". Whether the
> error disappears when you move focus away is subjective on if it fails
> "identified" and "described in text". Initially, it sounds like 3.3.1 is
> ok. If the message disappears, does that mean the error is not identified
> anymore? Maybe. But it sounds like the error is repeated in a list at the
> top so it's still identified.
>
> From the design side, it sounds very confusing and might be confusing for
> all users, which is an ironic non-accessibility issue. At least all the
> users have the same (bad?) experience. But perhaps the way it works makes
> sense when you actually use it.
>
> I don't see a need to limit the list of errors at the top. If you do limit
> it, then how does the user know how many errors there are? Let's say you
> limit it to 10 errors and there are 20 errors on the page. The user fixes
> one of the errors, it disappears from the list, then another error appears
> because there are still 19 errors. If they do that again and another error
> appears, that could be frustrating. They're fixing errors but the list
> keeps showing 10. When will it end?
> > > > >


--
Work hard. Have fun. Make history.