E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Wing Kuet
Date: Wed, Aug 05 2020 3:50AM
Subject: Error identification for multiple
No previous message | Next message →

Does anyone have a view of how inline form validation messages should be displayed for 5 input text boxes that are displayed side by side to each other in a horizontal row in a layout table. In the row there is only one row label but for each input box there is also an accompanying column label. In addition,
the client's website I am testing has a layout table where there is multiple rows of these input boxes that are side by side to each other. When an incorrect value is entered into any of the input boxes and the focus is moved away from any of them there is validation message that appears below the input boxes in the same row and spans the width of the whole layout table. The form validation message is specific in terms of the error message to each input box but only appears one at a time and when focus is moved away the validation message disappears. There is no attribute such as an aria-describedby to identify the error message if read by a screen reader if they go back to read the error message again once it disappears. A blank value does not trigger an validation message as well.
At the top of the page there is also a summary list of the errors for the entire page of all the inline error messages that have been produced for each row and input box with a link to the specific input box that has caused the validation message to appear.

Should there be a limit of validation messages that are listed for each input boxes at the top of the page? I would imagine if there are multiple errors, it can be difficult for the user to remember, find, and address all of them. Is have all 5 inline form validation messages appearing persistently, if triggered, in each row for the input boxes that are displayed?

My view is that the inline error messages should appear persistently and all five errors appear in the same row within the same proximity of the input boxes for which can be read. As for the summary of errors that appear at the top of the page that I think should appear if the amount of errors is small. However, if it is a very long list of say more than 10 errors then I am not sure how that should be displayed?


Regards,

Wing Kuet
Accessibility Consultant & Software Tester
Test Partners Ltd
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

From: glen walker
Date: Wed, Aug 05 2020 9:19AM
Subject: Re: Error identification for multiple
← Previous message | Next message →

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?

From: Birkir R. Gunnarsson
Date: Wed, Aug 05 2020 11:01AM
Subject: Re: Error identification for multiple
← Previous message | No next message

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 ADDRESS 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.