so I’ve noticed that when a form is submitted there are visual clues that tell a user if they have missed an input field. When going through the survey with a screen reader, these clues aren’t read out on submission if they are missed. I’m not quite sure how you’d go about adding these. I’ve been using Narrator with edge and chrome browser screen reader (sometimes called chromevox). Thanks so much for all your help guys.
Just an aside, I’ve learnt so much in doing these projects. I’m super grateful to the fcc creators and moderators as well as all the well intentioned amateurs with aspirations-of-being-pro-devs like my self.
Here is my project so far
It should read out that the input is required. It should also give the input element with the invalid/missing value focus on a submit where the validation fails. Which would then read out the requirement again (I would think).
You can also add the aria-invalid attribute, but that would require some JS validation.
I’m getting that visual clue for every input which has the required attribute, but i’m not getting the same screen reader service? I guess i’ll have to wait till i know a bit more JS!
Not sure why the extension needs the aria-required attribute but it seems like it does. I would think most screen readers would pick up the HTML5 attribute but I guess you can never be too safe.
Here’s the thing, HTML default field validation is nice in theory but it doesn’t work consistently across all the major screen readers and most accessibility experts will tell you not to rely on it.
Avoid Default Field Validation
I tested your form with JAWS and NVDA, and while NVDA was actually pretty good (it read the error message and indicated that focus shifted to the offending input) JAWS only read the error. And apparently your testing with Narrator wasn’t much better. Also, whenever using the
required attribute you have to manually manage the
aria-invalid attribute as well because screen readers will automatically announce “invalid” as soon as the user focuses on the input before they have even had a chance to type anything (which is annoying) and will often keep announcing “invalid” every time a character is typed until they have met the requirements (which is hella annoying).
Required attribute requirements
Bottom line, don’t rely on HTML default field validation and instead handle errors yourself. Here are a few links to suggested error handling techniques:
Of course if the tests for this project require using HTML default field validation then you have no choice. I’m talking “real world” here
As this example demonstrates, unfortunately, not all HTML is completely accessible out of the box.
HTML: The Inaccessible Parts
Some of these can be fixed with aria attributes and JS and some of it just needs to be forgotten about completely (looking at you
Wow there’s a lot to take on here. Thanks so much for your detailed answer. This kind of nuance is really important to understand. I’ve read a few times now how annoying repetition can be for people who rely on screen readers.
These links are excellent as well. I’ve given the first two a good read. I’ll have to take my time digesting them.
Thanks so much @bbsmooth I’m very grateful for the time you took to respond!
Yes, most aria attributes require JS to be used correctly. Aria attributes don’t cause the browser to behave differently, they merely provide information to assistive technology. So if an aria attribute can have multiple values (eg. `aria-invalid="(true|false)" then JS must be used to change those values as needed.
Thanks for that Bruce. I think I’ll leave it for now as I’ve put a lot of time in and it’d be nice to move on. It passes the tests and is fairly responsive. I think I’ll let other people see it and get a bit more feedback before giving putting on some final touches.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.