In this part of the quick audit series, I’m covering basic form testing for accessibility. The basics that I’ll cover include:
- Check the focus state and tab through the form to ensure accessibility.
- Each form field should have a clear and visible label.
- Make sure to indicate required and non-required fields clearly.
- Inspect the code for proper form markup, including form tags and label IDs.
- Verify that the form passes the 4.5 to 1 contrast ratio requirement.
- Ensure proper hover states for buttons, with a minimum 3 to 1 contrast ratio on the change.
Transcript
Welcome back to the Accessibility Quick Audit Series. I’m Gen Herres from the Easy A11y Guide, and in this video, I’m going to show you how to do some simple form testing.
Use your focus state and tab through the form
The first thing I’m going to do is I’m going to put my focus state just before the form and I’m going to use the tab key to tab through the form. Here I am in the username field. I can see a blinking cursor. That’s great. The border became thicker, and it also got a secondary yellow outline. This means that it’s visible.
The password field as well. The forgot password link is fine. The remember me on this computer looks fine, and the login button looks fine.
Look at the form visually
Now, I’m going to go ahead and look at this form visually. First, each field needs to have a label that’s clear in It’s easy for me to read. I see that there’s a username, and it tells me that this is a required field. That is great. You always want to tell people what fields are and are not required.
We have a password field and we have a label here for the button. You can see that when I hover with my mouse over this Remember Me, the link on the left with the checkbox is highlighted. This tells me as a sighted user that I could just click here and it will check and uncheck the box.
Check the button hover states
Now, I’m going to bring my mouse down over the Login button, and there is almost no color change or any other visual indication when I’m hovering on the Login button. Here you can see when I’m hovering on and off of the Remember Me, it’s very, very clear. But when I hover on the Login, it’s not. I would fail the Login button for Color on Hover.
Enter content into each of the fields
Next, I’m going to go ahead and put my cursor in here and just enter a little bit of content into each of the fields. Here, I just want to make sure that the content is rendered so that I can actually read it.
This needs to be a 4.5 to 1 or level AA. Ideally, it would be a 7 to 1 contrast ratio, which is the AA requirement. This is an essential function being able to fill out a form. You want to make sure that people can easily do it, even if they have poor vision.
Inspect the code for the form
Now, I’m going to go ahead and inspect the code for the form. This does require the ability to read HTML and understand what is and is not semantic HTML. This typically requires a bit more training, and in order to be able to give suggestions to correct issues, you need a lot more training in accessibility and code.
The first thing I’m looking for is that this is a form tag. Not all websites actually mark up their forms with form tags, and they should. The next thing I want to look for is a label. This says label for equals, open quotes, username, close quotes. That username needs to match the input ID, ID equals open quotes, username, close quotes. That’s great.
Moving on to the next one, label for password, and we have an input ID equals password. You also want to make sure that the type makes sense. For a username, a type of text makes sense. For a password field, a type of password makes sense.
This link is marked up nicely. It has an href value. Next, we see a field set. This is what is normally expected for checkboxes and radio fields. I have my checkbox item. This is an input type equals checkbox. It has an ID value of “remember me,” and I see the accompanying label for it, and that label is marked up to match the ID.
Since that is not a required field, it does not have the descriptor required on it. I can clearly see which fields are and are not required by just visually glancing. I see required with the username and password, and I don’t see it with the remember me.
Finally, I’m going to take a look at the Submit button for the form. This is using button type equals submit. Input type equals submit is also perfectly valid. It is recommended that it has an ID, but it’s not actually required for all situations.
Determine how accessible the form is
Overall, this form went very, very well. The only issue I have with it is the hover state of the login button. I would want that changed to something that clearly indicates when a user is hovering and not hovering. That means a change of at least three to one contrast ratio when it’s in the non-hovered versus the covered state.
Thanks for watching. I’m Gen Herres from the Easy A11y Guide, where we try to make accessibility easier to implement through done-for-you services, tools, and processes. If you enjoyed this video, please give it a thumbs up. It really helps our channel.
You can subscribe to our channel for more accessibility tips and to be notified when new videos are released. For more information on web accessibility, including services, tutorials, and more, please visit easya11yguide.com. Thank you so much again for watching, and I look forward to seeing you in the next video.