don't know why I can't get this to work properly..
for the links in the gray boxes, I need them to be activated, in addition to onclick, with enter key...
radio buttons also, I need to be able to check them with enter key in addition to traditional "click" way...
but this works intermittently, sometimes when I tab no links get focus... I have set a:focus to border red for easier testing..
in Chrome & Safari links get focus fine, and I can activate boxes with enter key, but FF won't play ball (FF 3, mac 10.6.6; at work FF 3, Win 7, same thing..)
in IE it also worked last time I tested Friday...
now for the radio buttons, even though am setting tabindex for them in same way as for the links (http://mayacove.com/dev/acc/js/myScripts.js), the radio buttons all have the same tabindekx...
would appreciate help w/these issues..
thank you very much..
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
i = ( $('a').size() ) + 1;
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:
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.
As SP said, it should be used sparingly if at all -- usually if you have to use tabindex, there is something horribly wrong with your source order. Looking at your markup -- you've got massive amounts of code and I'm really stuck asking "For what?!?"... non-breaking spaces and a paragraph on what's probably a list of links...
My understanding of tabindex is that it was origiially introduced because it was thought that it would help accessibility. It was then discovered to have the exact opposite effect and one step recommended in making a page more accessible is to remove all the tabindex references from the page.
tabindex should be used sparingly???? I find I can't tab to links at all if I don't have tabindex attr set for the links....
main prob I have now is I can't tab to the radio buttons
I can tab to first one, but not to the rest...
(I set tabindex for links, then for radio buttons, to start at value one higher than for no. of links.. wasn't sure how else to approach this.. basically they want user to be able to tab to links (esp to open & close the boxes) and to radio buttons... is there a better way than my approach???? (and yes I had wrong JS code to set tabindex for the radio buttons....;-)
yes, a lot of code in markup looks extraneous to you (and yes I did correct prob w/"close" img) this is a "bare-bones" of my branded pg at work for this....
and yes, we're doing spacebar for the radio buttons...
would appreciate further help here..
thank you very much..
1) anchors without HREF can't be tabbed to without tabindex in SOME browsers, I suspect that's what's messing with you.
2) given how little content is showing I'm really stuck wondering what the blazes all that markup is for... especially since none of it makes ANY sense semantically.
You seem to be testing incomplete code -- with dozens of DIV for nothing and massive bits of 'required' tags missing... like the lack of form/fieldset around the radio buttons, lack of attributes (like href) that trigger the behaviors you're looking for...
But again, this is where 'cut down' examples and snippets often fall short; though if this is a stripped down bare version, I shudder in horror at what the full version must be code-wise.
) anchors without HREF can't be tabbed to without tabindex in SOME browsers,
IE8 is absolutely one of them
If you don't have a destination then create a token that does not exist on your page. I tend to do
when I need something focusable, and no other element is better. Here, if the user accidentally clicks, they are not sent to the top of the page as with "#", but stay right where they were, because there is no element on my pages with an id or name of "void".
I think I picked that one up from YuriKolovsky.
But you'd rather the first option if you can get away with it, it's less complex. Also, using any of these depends on what you really need to do.
You might get some good ideas/solutions if you can post what you need to end up with. What has to be shown to users, what are users expected to do, and how should the page react to user actions?
there is LOTS of code in "real" one.. where it says "TAB" it's a three-line paragr., same with where it says "open" once boxes are open.. some of them have <ul>'s in there and stuff.. (and a tiny scrollbar appears on the right, in "open" section, done with jQuery tinyscrollbar plugin.....
at any rate: have now added href="#" to all links (and took out setting of tabindex for them)
and indeed w/that tabbing from link to link works fine w/o tabindex set....:-)
HOWEVER: still can't tab to the radio buttons (if I take out tabindex setting for radio buttons (done w/JS) then it tabs FIRST to first radio button, then to the links, if I leave tabindex for radio buttons it goes thru all links, but then can't tab to radio buttons...
here's one w/no tabindex set for radio buttons
Have you tried keyboarding through any webform with the TAB key?
You'll find if the form has one radio button selected (as recommended), then only that selected radio gets tabbed to. If none are explictly selected (not recommended because you'll never be certain what user agents will do) then it depends. Some might focus on the the first one and some might just skip over them or focus on each available one.
Once the user has tabbed to the group of radio buttons (assuming focus sits on the selected one), the user moves to the next ones using arrow keys. Then select one using spacebar.
Edit: here I found a demo form: http://formsmarts.com/registration-form-demo
Found one with unchecked radios: http://www.hscripts.com/tutorials/html/form-radiobutton.php
thank u for yr response..
one thing I just discovered: that radio button that is selected by default, yes I can tab to it (and in fact when a radio btn is selected, and u start tabbing, the FIRST element that gains focus is that selected radio button..) however: I cannot de-select it by hitting the space bar, that's a bit of a bummer...
(but it does get de-selected when u hit the 'right' arrow in keyboard, as that not only moves u to next radio button, but selects it also....;-)
at any rate you guys have been very helpful.. thank you very much..
Radio buttons (the group) shouldn't really be ALL unchecked anyway the whole idea of the radio button is an option must be selected. Even if you have a default "start" position of the checked button of effectively 'none of the above'.
yes, but wait a minute.. user should have the option to select a different button from the one that's selected by default, no?? (also if they select a btn themselves they should be able to change their minds, yes???? I guess what you're saying is at least one button must be selected.. I'm just saying it should be easy for the user to chg which button is selected; thanks to all the help I've gotten from you guys I learned only way to do this w/the keyboard is to use arrow keys (but I wonder how many users know that....;~) again, thank u very much..
user should have the option to select a different button from the one that's selected by default, no??
The way radios work, you unselect something by choosing another instead.
You ever wonder why they're called "radio buttons"?
Long ago, cars had radios with a few "preset" buttons. It wasn't possible to turn on the radio without having a station selected: you can't have a radio that's on that doesn't spit out some frequency from the speakers, even if there's nothing being broadcast on that frequency.
The way these buttons were supposed to work was, you pushed in the one you wanted (and you could set what they referred to). Whichever one had been pressed before that, got popped out. So, at all times, one and only one button was always pressed, and you always had one button pressed.
Now I'll reveal my age to say, as a kid I discovered you could kinda manage to push one button in just enough to make the other one pop out, without pushing completely down, giving you this:
But that's not the manufactured intent.
If you want users to be able to leave everything unselected, or if you want that they can select more than one thing, then you want checkboxes.
But with a radio, play around more with them. You'll see how they work. You don't have to "unselect" one option in order to choose another: simply choosing one automatically "unchooses" the other one.
I learned only way to do this w/the keyboard is to use arrow keys (but I wonder how many users know that....;~) again, thank u very much..
Don't worry, most people who are using keyboard either use it because they like to use it, or because they have to. So they've already gone through this and figured out how it works : ) While I'm always trying to be aware of possible new users to computers and interfaces, frankly you can't build something simple that works if you don't at least assume the users have a basic amount of knowledge. When building for keyboard, assume keyboarders know basic keyboard commands.
But... don't assume they know you have things like a set tab order or access keys, because tab order is not common enough to be expected (that is, most people would assume visual order or source order) and access keys are not discoverable (the browser doesn't announce "HEY this site has accesskeys!" and only Opera will even show the list to you).
Like the Poes said, as a kitten there always had to be one button selected; unless she used both her paws to trick and tamper the radio buttons to only half spring - I have done similar in my youth.
As I mentioned even if you built in a redundant starting place-holder radio button; one of the group of buttons should have a default checked status. There should never be a case where a group of buttons doesn't have; one and only one checked.
There is, use check boxes instead of radio buttons (:.
Those who need to know that will know that, if you see what I mean.
This topic is now archived. It is frozen and cannot be changed in any way.