With a long list of radio button options it might seem unwieldy to have every single option read out one after another with the checked/unchecked status announced too. But when you think about it, there’s no other way for an unsighted user to know a) how many options there are to choose from and b) what those options are.

My experience of screen reader users is that they operate the controls fast (mind-blowingly fast!) and will be used to navigating quickly around sets of form fields, whether they be inputs, radios or select lists.

If you have the budget/resource, I’d always recommend getting a day or so of accessibility consultancy from an organisation who can get unsighted users to test your site fully. it’s never cheap, but always extremely insightful.

As for further resources, give the Accessify Forum a look (http://www.accessifyforum.com/) – you can read through existing discussions or ask a question, there’s bound to be someone on there who can help you out (and may tell you something different from me!).

Hope that helps.

Hi there,

I’m working to make a slew of html forms compatible with screen reading software. Many rely heavily on radio buttons, so your posting was quite helpful. I have a question. If I understand right, JAWS recites the <legend> value before each and every radio button’s <label> value. So with your example, JAWS says, “How much do you love Twitter? So much it hurts. Radio button not checked. How much do you love Twitter? It’s OK. Radio button not checked. How much do you love Twitter? I’m not convinced. Radio button not checked. How much do you love Twitter? Twitter? Radio button not checked.” I imagine the repetition of the <legend> value could get very annoying. At the moment, I’m working on a 20+ item survey where the prompt for each item is a longish sentence (something like: “The activity you had us do strengthened my ability to perform the task we were to learn”), followed by an agreement scale (strongly disagree, disagree, neutral, agree, strongly agree). Does the typical JAWS user get used to completing forms tagged in this way? By item 3, say, do they have the 5 responses memorized, and know to interrupt the JAWS voice and quickly move to the option they want by typing F/SHIFT-F to move to the next/previous form field? Or do they get frustrated and abandon the survey all together? If the latter, what’s the best workaround? Switch to <SELECT> tags?

Thanks for any and all advice. Pointers to other useful sites discussing the issue are also appreciated.

Forms are one of the most difficult elements of clientside development in my opinion.

They are hard to style, hard to make totally accessible and there is so much conflicting opinion over how forms should be layed out.

hmm maybe i have a new post idea!