theoddsock.com

The clocks going back generally isn’t a huge issue for most of us. It happens in the teeny tiny hours of a Sunday morning giving us a whole extra hour in bed - or a whole extra hour to go around and change the time back on the microwave, the VCR( if you still have one), the DVD player, the retro analogue clock in the kitchen, the oven, the microwave, the central heating, the car and eventually you remember your watch. Sometimes its frustrating but it usually it isn’t too bad…
Here in Biggleswade we have a rather nice building in the town centre which is the current home of an ‘Ask’ pizza resteraurant. The exterior, which is really the side as you face it from the market square looks like a baby version - or at the least put me in mind of a baby version of the Town Hall in Back to the Future. However the clock on this building is mounted to the side of the building, overhanging the pavement. And I know now how they set it back or forward depending on the time of the year.

The secret tool?

A piece of bamboo, long and not too bendy, with what looked like a  little L-bracket taped to the top, all of which I suspect came from Goldthorpes which is just next door. With this the minute hands are moved around on one side - this has the effect of turning the hands on the other side.

I am sure that other clocks who are mounted within buildings can be changed from the back but it would be fun to see the clocks on Big Ben changed with a very long and not too bendy piece of bamboo Or perhaps bendy would be good, and get the tourists visiting in October.

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….

A very terse post to accompany my first foray into jQuery plugin authoring. Apologies for the lack of decent documentation of use but I should get my slightly antiquated version of WordPress upgraded soon so I can put HTML listings up.

I was prompted to write this after a co-worker asked for a way to have the correct date included in web pages. This led into a long discussion along the lines of if the site is being delivered via JSP/ASP then we can have the date generated at the server side.

The only way this code would be of any use is if its being used on a completely static site - are there many of those left? And here’s the accessibility bit. If your user has JavaScript disabled for any reason they will not see the date.
Currently supports the following specifiers: %a %A %b %B %d %H %y %Y %m %M
if no formatting is given then it will default to ‘%d/%m/%Y’

$(’#span’).strftime()

The contents of the specified element will be set to the resultant formatted date string.

Code: jquery.strftime.js

Before I start posting up any jQuery stuff I feel compelled first to do my Accessibility public service announcement piece, not least because I know of at least two people who it will make happy.

Before going absolutely crazy with the shininess made possible through the various JavaScript frameworks and effects libraries to bling up your site to the nth degree please please please bear this in mind…

If your user has JavaScript disabled for any reason they will not see what ever it is you are trying to do.

This is a big deal and it does need considering; no matter how shiney you can make your site, remember that not everyone has JavaScript and more importantly for those developing corporate/commercial sites there is legislation in place in a number of countries that means that you can’t over rely on JavaScript for your site’s functionality, such as site navigation that only works if you have JavaScript enabled.

And before you say - well they should turn it on, remember that not every one can turn it on - Screen readers may be able to deal with some JavaScript but they aren’t good at dealing with instances where part of the content is being updated as with AJAX.

Progressive Enhancement rather than ‘Graceful’ Degradation is the way to go - In my experience the degradation has been anything but graceful. Start with a site that doesn’t rely on bells and whistles for a smooth user experience - this isn’t easy, which is why we have information architects and user experience architects to go and do all those time consuming things like talking to users, doing heuristic evaluations - things that just eat into that all precious code-hacking time. Then when you have a site that works well, then you can go and add a little extra polish - and I do mean a little - too much can be distracting and just frustrate your users.