Validation error notification?

Hi luckster99,

It’s good to hear from another person that takes accessibility seriously.

I’m currently preparing a online forms system (application forms) that’s built around Gravity Forms and wrote this plugin as a way to get around the WCAG errors that the automated checks found.

So far it only focuses on a handful of fields, but I’m certain other fields that I haven’t needed to use have issues as well.

What you’ve raised is a very valid issue – it’s also a good example of where the automated accessibility checkers can’t say if it’s good accessibility or not. It’s also a great way to improve usability for all users.

I’m keen to know the specifics you found that were a problem with the validation so I can start working on a solution. Are you able to detail the issue – was it that the screen reader couldn’t access parts of the validation messages, or that it was hidden amongst the page content which screen reader users would typically not see when using forms (that is, the normal usage for a screen reader user would be to jump from one field to another – skipping past the text outside of the fields).

After reading the advice by WebAIM on Usable and Accessible Form Validation and Error Recovery I’m thinking a better, more accessible (and usable) validation would involve:

* the ‘errors on top’ style of validation
* a message that includes the number of errors, e.g. ‘ the form has 3 errors that need correcting’
* a list of errors that links to the field with the error
* when the page loads, if the page has errors the browsers focus is set to the error message – meaning for a screen reader user the first thing they should hear is ‘the form has 3 errors that need correcting’

I would also like to include the HTML5 ‘required’ attribute and aria-required attribute on the the required input fields.

Let me know if you have any thoughts or can provide any advice.

Thanks for your response!

What my tester wrote was:

“GravityForms do utilize labels, but when submitted with missing input, no feedback is provided that is detectable by a screen reader user. There is no alert spoken and the focus is not moved to an intelligent location on the screen, such as the location of the first error. “

He said he could hear the validation error text IF he moved backwards through the form after submitting but who would do this unless they knew there was a problem. There was no alert that told him he missed a required field or had other problem. He thought the form was successfully submitted. We almost missed this problem – we only realized it when he mentioned a form he submitted and I said I never got it.

What you write sounds like the right answer. I’m not very familiar with the technical solutions. The other thing that jumped out at me from WebAIM was: “Regardless of the mechanism used to identify and recover from form errors, aria-invalid=”true” should generally be set on each invalid form control. This attribute causes screen readers to identify the control as being “invalid” or in need of attention.”

Thank you so much for thinking about accessibility for forms. We were struck as to how many of them fail to account for accessibility in any meaningful way. Unlike some accessibility problems that might be just an annoyance for a screen reader user, this problem was a deal breaker for us. I could just see a student applying for a position in a lab, trying to submit a homework assignment, or make an appointment and never knowing that it wasn’t even submitted. The ramifications could be pretty terrible.

Contact Form 7 can do a lot but it requires the form creator to know how to manually add some html….our users would never in a million years do this consistently. If we could get Gravity forms up and running, it would be fantastic.

Let me know if you need any other information. My tester is on retainer and I could get a little of his time perhaps. However, he is not a programmer and doesn’t typically tell us how to fix our problems….just that we have them.

Hi,

I did some more research on accessible form validation – what as it turns out is a complicated topic with many different approaches.

The advice here https://www.karlgroves.com/2011/10/10/accessible-form-labeling-instructions and https://www.nczonline.net/blog/2013/02/12/making-an-accessible-dialog-box/ were valuable.

I’ve made a whole bunch of changes to the validation message, should be must improved.

I had a go at testing a few of my forms using JAWS 16 and it was much easier to navigate through the form and work through validation errors – but I’m not sure it’s perfect yet.

If you still have a Gravity Forms I suggest you install the latest version and have a look at the changes to the validation process.

I’ll also get in touch with a screen reader user to have them test my forms to get some more feedback.

Let me know how you go and what you think.

Cool – we do still have Gravity Forms installed.

Did you update your plugin or are you saying that Gravity Forms updated and had improved validation errors??

Hey,

I updated the plugin, and once again today to version 1.2.1.

This is probably going to be an ongoing process, which I hope results in something I can pass onto the Gravity Forms developers for it can be done in the core version. (imagine that – a forms software that can claim 100% accessible – would be a real selling point for them!)

I noticed my multi-page forms still don’t pass the automated checks, something about duplicate ID’s. – I think each page DIV (including the hidden pages that aren’t being displayed, hidden using css) have duplicate ID attributes .. not sure if a plugin can fix that, potentially something worth raising with the developers if there’s no real reason why it’s done like that.

This is really cool. I”ll be checking it out soon. I had written to gravity forms developers re: this and they simply responded that they don’t guarantee accessibility. didn’t seem that interested but if you do all the work for them….I do think this issue is gaining traction and would be a good selling point.