A few things I notice
- personal data fields must have autocomplete attributes.
- you can use required instead of aria-required.
- the errors should be wrapped in an element that's always in the dom and has an aria-live attribute set to "assertive". That's where the error id should go that's referenced in the aria-desciribedby too. Then you conditionally render the error message inside when needed.
- query type is the legend. You must remove the sr-only legend in this. They are actually breaking the accessibility of this.
- the message does not belong in a fieldset. It's a single form field with a label that's all. Again, the fieldset and legend are making that inaccessible not accessible.
- not accessibility related but input names shouldn't include spaces (including on the button but that actually doesn't need a name attribute at all).
- role alert and aria live should be removed from the errors. You wouldn't ever put both of them on one element as they have related functionality.
Marked as helpful
@dev-paulL
Posted
@grace-snow Thank you so much! I’ve made those changes in the recent commit 🫡. Do you recommend a particular screen reader? I’m currently using Mr. Narrator on Windows, but it’s new to me, and I find it challenging to understand the expectations of visually impaired users.
btw, I’m constantly learning from what you post and share on Discord about accessibility, it’s really interesting!
@dev-paulL use NVDA on windows. It's by far the most popular.
@dev-paulL
Posted
@grace-snow I'm using NVDA now, and it's way better than the Windows Narrator. After testing, I made a few more changes:
- Added back "aria-required" because it works the same for screen readers and doesn't mess with the errors defined in the Zod schema.
- Set the toast message to show for 5 seconds instead of 3, and added
aria-role="alert"to it. - Changed the error message from "This field is required" to more specific ones like "First name is required," "Last name is required," etc..
(I completed the form multiple times with my eyes closed)
@dev-paulL that sounds great, well done! I hadn't actually realised it included a toast notification as I only had a quick look through the code. It sounds good what you've done.
I just tried it out and on mobile I didn't see the toast as I was at the bottom of the screen. Make sure it scrolls into view or something.
It also looked like it was stacked underneath the form content when I briefly saw it after scrolling so check it can definitely be seen on small screens.
A toast that appears then disappears fast would probably fail on the Timing Adjustable WCAG success criterion too. So it may be better to use a dialog, move focus to it (or to a close button within it), include a close button and let it persist until closed. That would allow people to definitely see it, have enough time to read and intentionally dismiss. Much better than something that appears and potentially disappears before they had time to see it.
Marked as helpful
