You can go a long way to making a web form accessible by making sure every input field has a label. But with a set of radio buttons this ain’t enough. Use labels for each of your radio buttons and the various options will be read out, but how does a screen reader user get the question they’re supposed to be answering? Easy. Use fieldset and legend HTML tags, a simple – yet underused – way of getting your forms to make sense for screen reader users.
How the JAWS screen reader deals with forms
When JAWS comes across a form element on a page, it announces it – the user then needs to go into ‘Forms mode’ in order to start putting things in the fields (by hitting the ‘Enter’ key). (JAWS users can also choose to get a list of all form controls on a page, and jump straight to them.) Once in Forms Mode, JAWS will only recognise form controls (labels, input fields, submit buttons etc.). When the user’s filled out one input field, they can tab to the next item and JAWS will jump straight to the next form control it finds – regardless of how much other HTML there is in between.
So in other words, if you have headings, paragraphs and lists – no matter how semantically marked up – JAWS is going to ignore them in Forms Mode.
Forms with sets of radio buttons
If you mark up text and textarea input fields with associated labels, then you can make the screen reader user’s journey pretty painless. But that comes a bit unstuck when you have a set of radio buttons. You can easily make each radio input accessible for screen readers by providing an associated label, but first the screen reader user needs to know the question they’re supposed to answer.
Here’s some typical markup for a set of radio buttons:
<form name="noFieldset">
<p><strong>How much do you love Twitter?</strong></p>
<label for="twitt1">So much it hurts</label>
<input id="twitt1" type="radio" name="twitter" value="1" />
<label for="twitt2">It's OK</label>
<input id="twitt2" type="radio" name="twitter" value="2" />
<label for="twitt3">I'm not convinced</label>
<input id="twitt3" type="radio" name="twitter" value="3" />
<label for="twitt4">Twitter?</label>
<input id="twitt4" type="radio" name="twitter" value="4" />
</form>
If a JAWS user in Forms Mode comes across this set of radio buttons, they’ll get all the options to choose from, but they won’t get the question – since it’s marked up in a <p> tag and not a form element. Your JAWS user is simply going to hear ‘So much it hurts’ and be asked whether they want to select it. Bit disconcerting, no?
The way to make this more accessible is easy. Since the radio buttons are all part of a group, we can wrap them in fieldset HTML tags – specifically designed to allow you to group a set of fields together. Within the fieldset, you can then use the legend tag – basically a heading specifically for use in forms – for your question. Being a form element, JAWS will read the contents of the legend tag before reading out the radio options.
The markup would look like this:
<form name="fieldset">
<fieldset>
<legend>How much do you love Twitter?</legend>
<label for="twitt1">So much it hurts</label>
<input id="twitt1" type="radio" name="twitter" value="1" />
<label for="twitt2">It's OK</label>
<input id="twitt2" type="radio" name="twitter" value="2" />
<label for="twitt3">I'm not convinced</label>
<input id="twitt3" type="radio" name="twitter" value="3" />
<label for="twitt4">Twitter?</label> <input id="twitt4" type="radio" name="twitter" value="4" />
</fieldset>
</form>
This time, JAWS reads ‘How much do you love Twitter?’ ‘So much it hurts – option one of four. To change the selection…’ etc.
Why <fieldset> and <legend> aren’t always used
My suspicion is that the fieldset and legend HTML tags are sometimes left out because they are such a bitch to style. IE and FireFox treat the legend tag differently by default, and even if you’re using a reset CSS file getting them to obey CSS rules can be a pain. But, clearly, they are tags that can make all the difference for a screen reader user.
I haven’t tested with other screen readers yet, but looking at the Window Eyes manual ![[external link]](/images/exLink.gif){kind=small}
it would appear that this screen reader will read both form and non-form elements together (there is a Browse Mode but not a specific Forms Mode), so it may be less of a problem for its users. If anyone has used Window Eyes – or any other screen reader – to test forms and knows different, I’d be interested to hear.
Written by: Andy Bryant
Published on: 25 Jul 2009
Tags: Accessibility, assistive technology, HTML, JAWS, screen readers, web forms
Great Post,
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!
Look forward to it! The thing that I find time consuming is lining up labels and fields purely in CSS. I’ve heard the argument that forms should be marked up in tables and still be semantically valid, but I’m not entirely convinced.
Hi,
IT is right information. could we use use legend tag for content also if i want give a name paragraph of content. I want legend tag such a way it will give a name to a content. Is it SEO friendly?. What is best tag i can use.
Pankaj
@Pankaj Not entirely sure what you mean. The
With regular content you just need your usual formatting tags (lists, paragraphs etc.), and as far as SEO is concerned I’d suggest making good use of the heading tags, which will also help screen reader users get an understanding of the structure of the content – and help them navigate the page too.
Of course f I’m off-track and that wasn’t what you meant, let me know!
[Sorry for the repost. Should have know the angle-brackets around html tags would get stripped. Hope this works.]
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.
@Ned That’s a good question. To my knowledge (and I currently only have acces to Jaws 9, not the latest release), when it comes across a group of radio buttons it does exactly what you describe – lists each label and says whether the radio button is checked or unchecked. When you then check a radio button, JAWS will announce you’ve made the change and also tell you how many other radio button options are in the group, and where the selection you’ve made falls in the order (e.g. ‘It’s OK’ radio button checked – 2 of 4, to change the selection use the up or down arrow keys’).
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.