Hey everyone. Josh here with Online ADA, and in this video we’re covering Article 3.3.1–Error Identification. This is a level A requirement and I’ll jump into the description.
“If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.” This is because relying on audio or visual cues alone is not enough to let the user know where the error has happened. When we use text instead–or in addition to–visual or audio cues, the users can more easily identify where the problem is, especially if it’s on some sort of form. And forms a lot of different behaviors.
For instance, sometimes validation errors can happen as soon as you click the button. Other times they happen after the page refreshes. And if we don’t provide multiple ways for them to identify the error, it can be really confusing and the assistive technology may not indicate to them right away where the problem is, relying instead on the user going all the way back through the form to find the individual fields. If the user isn’t aware that there’s some sort of input error before they attempt to submit the form, they may find that–or they may think that the form is not behaving correctly or that the form is broken, instead, not realizing that they need to in fact to go back to the form input fields, specifically, to find that information.
So there are a couple of best practices here. Number one–a good strategy is to make sure that your validation errors on your forms are firing either on the click event of the form or like right after the form click event so that you’re not actually submitting the form, you’re showing the errors ahead of time. This is because if you refresh the page and then show the form again with its errors, the screen reader, the assistive technology, may read that the page did, in fact, submit correctly, and we’re on a new page and start reading from the top again. The user, meanwhile, is unaware that there was a problem with the form. So we wanna make sure that we get these errors to the users as quickly as possible.
Another good practice is to put the error in the title of the page so that when the screen reader reloads–this is, for instance, if you’re refreshing the page– you would have it in the title so that when the title is read, it would indicate that that page did not in fact, submit correctly and that there are errors that require attention.
In addition, we want to try using ARIA attributes as well on our forms to indicate that there is something that needs to happen with this form, specifically, when the user approaches it the first time. We wanna get these warnings to our users as soon as possible, so adding an attribute like Aria required equals “true” is going to let the assistive technology know, and thus the user know, that this field is required. You can also put things like (Required) after the label of the form input and this will just further give them information.
Another really good technique is to use the role of alert on your form itself so that when you submit the form and validation errors are found if, you’re inserting text–which I’ve seen a lot in my audits and I think it’s really good idea–you insert text underneath the input or above or beside or some image or cue, then when that image, rather when that text gets added to the form the role of alerts will actually read it out loud to the user. That is not mandatory for this article, but it is a good idea because it tells the user something’s wrong without them even having to move around the form again. Just reads it right out loud to them.
So, the big take away from this article is to make sure that we’re not just using audio or visual cues–we need text in addition. it’s a great idea, in fact, to use both together. That when we submit the form or when we click the submit button, we are indicating to the user what things are wrong.
It’s also important to note that if we have a number or a range field, that if the user enters a number that’s too high and we have some sort of logic that automatically sets the number back down–let’s say we have a range of one to ten in a number box and they enter fifty and the automatic filter that we have in place brings it down to ten, which would be the maximum range for that box, we would need an indication there as well of what the user did wrong. There’s an error identification that the user is aware of what’s happening and they don’t just blissfully move on thinking that their fifty took place.
So, with that said, that’s really all there is to this article. Thank you so much for joining me and I’ll see you in the next one.