Accessible forms

When designing forms on the web, one common pattern is to display each field with the possibility to validates their content and to put the eventual errors next to the fields themselves.
For instance, letâs imagine a login form with an email field, a password field, and a submit button. For each of these elements, there is a set of rules to apply:
The following Codesandbox is an example of such a login form you can play with. Itâs built using Formik.
While this seems to follow the rules set before and that the UI seems to fill the designersâ expectations, there is an issue. Letâs check what happens when using this form with a screen reader in this video.
In this video, Iâm using VoiceOver (the official OSX screen reader). While being able to navigate using it, I donât have direct feedback about the invalid fields. In order to get informed, I need to scan the whole form again and check every text content in it.
With the intent to provide a better experience to screen reader users, we can:
aria-invalid
attribute on fields that are in an invalid state so that screen readers can provide that informationaria-describedby
attribute on the error element (in the example, the one showing âInvalid email addressâ) so that when focusing the input, screen readers also announce the error contentdisabled
attribute on the submit button so that the user can click on it. When pressing it, the browser will focus on the first field that is in an invalid state or submit the data if every field is valid.The following video shows how making these modifications help to provide feedback to screen reader users.
In addition to this video, the following is a Codesandbox providing an example of the login form built in a more accessible way, also using Formik.