WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: form validation and error handling. (tech gurus)

for

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

From: Nancy Johnson
Date: Wed, Sep 13 2017 2:31PM
Subject: form validation and error handling. (tech gurus)
No previous message | Next message →

I am working for a company that has always used server side validation asp.net4
This is not screen reader friendly, not does it move the focus to the
first invalid form field.
1. is there a way to make server side validation accessible to screen readers?

2. Simple email-a-friend form. 3 required fields. 2 email fields 1
name field
Using HTML5 required and proper input types.

Are there samples or tutorials out there for the JS side? I'm
struggling with that and its so simple.

I am familiar with jquery UI Validate and know it has some problems
with accessiblity including using label as error.

Thanks

Nancy Johnson

From: Birkir R. Gunnarsson
Date: Wed, Sep 13 2017 3:51PM
Subject: Re: form validation and error handling. (tech gurus)
← Previous message | Next message →

Nancy

If you use HTML5 input types as appropriate (required for rquried
fields, type="email" for an email field etc.) you will trigger a more
accessible experience in browsers that support those attributes, e.g.
by automatically moving the focus to the first invalid form field
(provided the invalidity is triggered by the HTmML5 attributes).
The risk of this is that the validation takes place before the form is
submitted to the server, and in some browsers the error messages are
not perminant (though they can be customized).
You can also use the .autofocus attribute on the first invalid form
field to move the focus to it (if you add the ttribte as part of the
server validation).

Use aria-describedby to connect form fields and visible error messages.

<input type="text" id="name" aria-describedby="nameError" aria-invalid="true">
<span id="nameError" class="error">Name cannot contain numbers</span>

Remember that the target of aria-describedby is always announced, even
when it is hidden, so make sure only to establish this relationship
when the error message is visible.
There is another attribute , aria-errormessage, that works the same
way (just replace aria-describedby with aria-errormessage), and has
the added advantage that it should only be exposed by assistive
technologies when aria-invalid = 'true", but support for this ARIA 1.1
attribute is spotty, to say he least, so it is not a reliable solution
yet.



On 9/13/17, Nancy Johnson < = EMAIL ADDRESS REMOVED = > wrote:
> I am working for a company that has always used server side validation
> asp.net4
> This is not screen reader friendly, not does it move the focus to the
> first invalid form field.
> 1. is there a way to make server side validation accessible to screen
> readers?
>
> 2. Simple email-a-friend form. 3 required fields. 2 email fields 1
> name field
> Using HTML5 required and proper input types.
>
> Are there samples or tutorials out there for the JS side? I'm
> struggling with that and its so simple.
>
> I am familiar with jquery UI Validate and know it has some problems
> with accessiblity including using label as error.
>
> Thanks
>
> Nancy Johnson
> > > > >


--
Work hard. Have fun. Make history.

From: Meacham, Steve - FSA, Kansas City, MO
Date: Thu, Sep 14 2017 9:14AM
Subject: Re: form validation and error handling. (tech gurus)
← Previous message | No next message

I've found that the most robust validation practice is to validate in the browser (HTML5 and/or JavaScript) and then server-side (because the browser can't be trusted). The first provides the most usability, and the later the most security. If one and only one were an option, chose the server-side and do what it takes to keep it usable enough.

To do this, the server-side validation would need to re-present the page that contained validation error, but incorporate additional human-friendly cues such as error messages, instructions, and possibly even scrolling the page and setting the focus automatically.