How Can I Make My Forms A Little More Accessible?
Whenever the topic of accessibility, specifically screen readers, comes up, I always hear, “Just write the markup in a semantic way and it’ll be fine.” Why do we say that? Because the whole field of accessibility stuff is so broad and dense that we want to write it off. Is it true though? Can just semantic markup cover it? I care, but I can’t change my title to Accessibility Wizard and spend hours and hours casting spells and reading obscure tomes to figure out how to make my sites perfectly accessible.
So my question is, what can we do, besides just semantic markup, that’s easy to implement and remember and will give us the most improvement for only a small amount of effort?(Keep in mind that this is what I want to do instead of doing nothing.)
In trying to answer that question, I decided to start in the obvious place, forms.
Screen readers
First things first, how am I going to try this out with a screen reader? How will I test if what I do is an improvement or not?
So here are my choices. The top choice for me to check out would be JAWS, obviously, but as I’m on a Mac, and it’s Windows only, its out.
Number two is NVDA, but same story there, Windows only.
I have no choice but to use the third highest, which happens to be the Mac VoiceOver. At 37% its still highly relevant and will do for this experiment.
A basic, semantic form
I marked up a very basic sign-in form for the purpose of this article. It looks like this:
<form>
<label for="name">Username</label>
<input type="text" id="name">
<span class="validation-message"></span> <label for="password">Password</label>
<input type="password" id="password">
<span class="validation-message"></span> <input type="submit" value="Sign In">
</form>
So what I’ve got there is just a couple labels, inputs, and some placeholders to hold validation messages, whether its validated on the front or on the backend doesn’t matter here.
What happens when VoiceOver reads over this?
When you focus into the username field, VoiceOver says:
“Username, edit text”
moving into the password field:
“Password, secure, edit text”
It reads it this way because of the for attributes that pair the labels to the ids. This seems fine so far, right? Its reading the label so that the user has some context, and tells them when they can type. It even says ‘secure’ on the password field.
What’s Missing?
This screenshot shows the invalid username field lined in red with Javascript after the page was loaded, indicating a problem with the field, for sighted users. But what does VoiceOver read when you focus into the username field now?
“Username, edit text”
So it isn’t indicating that there’s something wrong at all.
What I’d like to have happen is that there would be some kind of message, when the field is focused into, that it’s not right. Even better, read to the user why it’s not right.
What’s the Answer?
Ok, so there’s these aria roles we can use to get some improvement. First, to indicate that the field is messed up, we can use a role and it will read like this instead:
“Username, invalid data, edit text”
That’s much better because now the user can tell which field has the mistake in it.
Its easy to implement and remember, just apply:
aria-invalid=”true”to the <input> that gets invalidated. The Javascript or whatever that does the validation can handle this part of it too.
What about WHY its invalid?
Another thing that’d be nice to have is, if, when the field is invalid, VoiceOver read what was actually wrong with it.
What you can do, thats easy, is just add your validation message to the ‘Helper text’. Anything that has been idenfified on an input with this role:
aria-describedby=”<some element's id>”Will be read aloud as the ‘Help Tag’ for that particular input. For example,
Focusing into the password field, with invalid data and a validation message, it will read:
“Password, invalid data, secure, edit text”
Which is all well and good, but where’s my validation message?
Well, it turns out that if you use aria-describedby, its read after lingering in the field for a bit. So, after staying in the invalid password field here for a second, it reads:
“The Help Tag is: Passwords are supposed to be a secret.”
That’s helpful. Is it what users expect from this kind of thing? No clue. It makes sense though, if the help text is usually read in that way and they already know that the field is wrong, it stands to reason that they will linger for a clue as to how to fix it, which is what we give them.
Getting the Javascript to handle this part is also fairly easy, since the fields already all have a unique id, you can just prepend something like ‘error-’ to it to make a new unique id and set it on the validation message.
That’s It?
Yeah, this is all I have so far, but there’s nothing here that should slow one of us down for long enough to make it not worth doing. Especially if we care about an open web for everyone.
P.S. If I’m missing anything easy here or you want to send similarly easy things to do to improve accessibility on a website, please do.
