Forms are notorious places for accessibility compliance to fall apart. If you religiously make sure that all your input fields, be they input tags, radio/check box or text aress have associated label tags then well done - but you are using the for attribute aren’t you?
If you are then you probably know why you are adding label tags and why you are linking them to their inputs by using the input’s id as the value for the for attribute.
If you don’t and that previous sentence made absolutely no sense whatsoever then you are missing an important part of making your site accessible.
Now, do bear in mind that with the advent of web2.0 and user-provided content yadda yadda, you want, and may encourage, your audience to interact with your site; this boils down to filling in and submitting a form of some kind.
Labeling is a pretty straight forward concept - you want people to know what information you expect/want in which fields. This becomes especially important if you are having some automatic process deal with the information - such as sending a confirmation email back to that person - doesn’t really work if they mistakenly put their email address in the wrong field; they might do it on purpose but we will assume not.
Now you might wonder why you need a specific label tag to do this - a bit of text in a strong tag before the field in question generally achieves the same effect.
Visually this may be the case.
For screen readers and other assistive technologies however you can’t make such an assumption.
By using the label tag with the for attribute you are creating a logical link between and input field and its label which screen readers understand and are able to relay to the user.
Also in terms of semantic markup and styling you are in fact doing yourself, and anyone else who might come cold to your code, a big favour.
Firstly you can see easily what is a label. You can style all your labels in one go. And regardless of whether you place your labels to one side or above their associated input fields, users relying on assistive technologies will know which inputs have which labels.
And now time for a bit of naming and shaming.
Who uses Facebook? I do, and I know a fair few usability and accessibility experts who do too.
And for a site that driven by people filling in forms with information about themselves, messages to friends, the whole shooting match; how does Facebook fair with labeling their forms?
Before I tell you, here’s something that might give you a clue.
Go to your ‘edit profile’ link and view source…
Yes, folks, they are using a table for laying out their form. Now I don’t think that’s tabular data, do you?
And for those labels? td with a class of…. wait for it it’s highly original….
label
At this point I must say that I felt like banging my head against the wall, but my husband was worried that this might have a bad effect on our unborn child. I am a bit worried about I am bringing a child into the world where people still use tables like idiots.
textinputfeedback Plugin
Now after all that I do have another little plugin with a long name to share. One drawback of text input fields, in particular those with a maximum length - the maxlength attribute - is that you can soon loose track of how many characters you have used, and I’m not sure that I’ve seen consistent labeling in terms of the number of characters that the field will accommodate.
The maxlength attribute should be specified especially when the value of the input field is to be inserted into a database, since unless you are doing some checking and either error reporting or slicing on the server side you are likely to cause your database to complain alot when you try to insert the data. It also helps protect against buffer over run type exploits. You might also want to check for dodgy SQL in the data to avoid something like this: http://xkcd.com/327/ . Your server-side lanuage of choice may delimit the SQL code for you but it helps to get in a good habit in case you have to use another language that isn’t quite so forgiving.
(My husband, the security expert, points out, very rightly that you should not assume that people will submit data to the handler via your form - but through some nefarious form of their own, so you should also sanity check and santise your inputs in your handler script. I will post up on security issues relating to form intercepts at a later time.)
This plugin will insert a span tag immediately after your input tags. If you have a maxlength specified it will show you number of character in the field and the total number, if maxlength doesn’t have a value or isn’t there it will just keep track of the number of characters in the field. The plugin attaches a keyup event to the inputs so that the count is updated after each keyup. The demo page lets you see this in action.
Remember though, users with JavaScript disabled will not have the benefit of seeing the feedback; however the form will still be usable - this is an instance of enhancing something that is perfectly functional and accessible in its vanilla state.
Code: jquery.textinputfeedback.js
Demo: http://www.theoddsock.com/jQuery/textinputtest.html
The following jQuery will select all inputs of type text. This is handy as it means you can attach the functionality to all your inputs with one line of code.
$(’input[type=”text”]’).textinputfeedback()
Now I’m off to update date this to also handle textareas….
