Accessible Client-side Form Validation with HTML5, WAI-ARIA, & the jQuery Validation Plugin
Adding the jQuery Validation Plugin
jQuery Validation Default Settings
There are some issues with the default settings. It stops the native HTML5 validation. The other big accessibility issue is that by default the error messages are placed in a second <label>. So there are two labels pointing to one input. This is a problem for some screen readers. VoiceOver will not announce the second label when the user tabs through the form. Steve Faulkner (@stevefaulkner) wrote a recent blog post titled, Notes on applying multiple labels for a control using the label element, and created a test case, multiple labels for a control using the label element, where you can see where multiple labels fail in certain AT. aria-labelled by is a better solution than using multiple labels.
So we have two problems so far with default settings. HTML5 validation is disabled and two labels are pointing to one input. The third problem is that the error message is being placed below the input. So we need to move that into the original label and use CSS to position it where we choose.
Tweaking jQuery Validation
There are many options to change the default settings of the validation plugin. We want to change the errorPlacement and errorElement. We also want to remove the novalidate attribute that is applied to our form by default.
Change the code in the <head> to this:
To change the errorPlacement I found some code on Stack Overflow to select the associated label element of an input field and append the error message to that. Then I changed the errorElement to be an <em> rather than another <label>. And then used jQuery to select the form on the page and remove the novalidate attribute.
Now this is the behavior we want. Modern browsers like Chrome and Firefox will first run HTML5 validation and then other browsers with less HTML5 support like Safari on Mac an iOS will use jQuery Validation.
It even works in IE6! Check out the two demo links in different browsers to see the differences.
Forms Can be Painful & Inaccessible!
Let’s change this problem with data entry on the web!
These three posts have been based on a talk I did at CSUN 2012. I hope you enjoyed the series!
Links to all three posts in this series:
- Accessible Client-side Form Validation with HTML5
- Accessible Client-side Form Validation with HTML5 & WAI-ARIA
- Accessible Client-side Form Validation with HTML5, WAI-ARIA, & the jQuery Validation Plugin
So what do you think about these three layers of accessibility we’ve added to our form? I got a comment in my talk at AccessU 2012 that this seems like a lot of extra work to make an accessible form. I think it’s totally worth it to make a very usable form that is universally accessible on all devices that support accessibility.
Let me know if you have any suggestions for improvement or find any mistakes.