You need to be very careful, because you’re breaking a lot of rules here.
Tabindex in general should be used very lightly if at all.
Here’s one problem:
the Enter key can and will submit forms in most browsers… IE is the only know I know of who wants you to first have your focus on the submit button (and frankly, I feel IE is the only browser doing this right). In other words, hitting Enter for most users is for the expected action of form submission. People don’t hit Enter anywhere else except within the safe confines of a textarea.
Also: the most common keyboard action to select a radio button is hitting the space bar, not Enter. Users who use keyboard will be hitting space most of the time to get those radios selected. Also, be aware the specs for radio buttons states that one should always have a default “selected” state. If you don’t set that yourself, you cannot count on the behaviour of user agents: most of them that I’ve tested seem to allow a page to load without showing ANY radios as selected, but a UA (browser) may come along later who selects one of them by default. This is completely within the specs and if you don’t want that one selected by default then you’re stuck.
Are you planning on having a tab path that’s DIFFERENT from what you now have? Because right now you’re setting a rigid tabindex that pretty much already follows source. For the footnotes, I’m not sure what you’re planning there because if you’re going to take users out of the form over to a footnote, webkit (Safari and Chrome) users will be in a pickle: a long-standing webkit bug that still exists is, visual focus will move when clicking on an in-page link (links with #someID), but keyboard focus remains where you last where. This might be exactly what you want in this form, however all other browsers will move the user out of the form and over to the footnote. Their next tab would start from there, though maybe that’s why you have tabindex everwhere. Instead you might want something like Derek Featherstone’s Accessible Modal Dialogues (I’ll see if I can find his link) where the user clicks on a link in a form and gets some help text. Hitting the close button takes them right back to where they were, so they don’t get lost.
Re your radio buttons tabindex: I wonder if this loop is running through all the radios first:
// add tabindex to radio buttons
$('input:radio').each(function(i) {
i = ( $('a').size() ) + 1;
$(this).attr('tabindex',i);
i++;
});
I can’t read jQuery but in plain Javascript there’s a known danger of looping through stuff and adding functions to them.
Hm, I can’t find the really good article I read once about it where it showed these very nice, clear loops and showed the value of the iterator and the function in each iteration, but this page I found seems to explain it similarly:
http://www.mennovanslooten.nl/blog/post/62
and this one seems to explain it in a more complex way: http://blog.jbrantly.com/2010/04/creating-javascript-function-inside.html
But basically you’re not really adding a new tabindex to each radio button. I’m not sure what the jQuery equivalent would be to do that… you might need to post that bit of code in teh Javascript forums.
Anyway, if the big graph things are supposed to open up when the user gets to the input, and need to close when the user hits close, why not have them open when the user focusses on the input? onfocus is a valid event to show/hide things with. Your close button isn’t actually labelled close: what do people do if your image doesn’t load? Or people using a screenreader? You ought to have alt=“close” at the least.
Ah well here is a transcript of the talk by Derek Featherstone, go to 31 minutes in and he starts talking about Contextual help dialogues. He shows a keyboardable way to show/hide things in a form (I assume the boxes that open up are showing something, and are not very interactive). I can’t see the video now but I remember the talk.
http://fronteers.nl/congres/2011/sessions/accessibility-for-the-modern-web-derek-featherstone
