29 March 2022 | Ted Page
It is a convention of form design that you should use radio buttons when the user is permitted to choose only one option, and that you should use checkboxes when the user can choose multiple options. Although generally there are good reasons for adhering to form design conventions, there may be times when a particular rule or convention may make a form less usable, not more so.
For example, I recently came across the following layout in a PDF form. It conformed to convention in that it was using radio buttons for a question for which the user should only be able to choose a single option, in this case, to specify ethnic origin.
Tab order problem
In the above, the presence of several “Other, please specify” text fields placed in between the radio buttons creates a problem with the tab order. This is because a group of mutually exclusive radio buttons constitutes just a single item in the tab order.
The tab order for this group of fields consists of all 13 radio buttons as a single item, followed by the five “Other, please specify” fields, reading from top to bottom. This clearly does not constitute a coherent tab order. The only alternative layout option of having a single “Other, please specify” field after the thirteenth radio button would not be as clear: having separate “Other, please specify” fields, one for each section, makes more sense for the end user.
Mutually exclusive checkboxes
In this case, a better option would have been to use a set of 13 mutually exclusive checkboxes. The reason for this, and one of the vital differences between radio buttons and checkboxes, is that each individual checkbox constitutes a single item in the tab order.
If checkboxes had been used, the user could have tabbed through the first two options and then tabbed to the first “Other, please specify” text field (with a tooltip/description of “Other White, please specify”). The user could then tab to the next checkbox (“White and Black Caribbean”) and so on, through the form in the correct sequence.
The attempted workaround
The author of the original form seems to have been aware of the problem because he or she had inserted a line of invisible text at the beginning of the form advising screen reader users to use the down arrow to navigate through the form rather than the tab key.
However, using the down arrow in this way is not a solution for a form that includes any check boxes, as the original of this form did. This is because you can’t escape ‘forms mode’ from a check box in JAWS by using the down arrow (you can in NVDA, by the way). JAWS users will be obliged to use the tab key to exit a checkbox, so the instruction is problematical.
Also note that using invisible text in this way is not a great idea as assistive technologies other than screen readers will still read it. For (sighted) literacy software users, invisible text which is read out loud is likely to be confusing.
Conclusion
In this particular example, a set of mutually exclusive checkboxes solves all the problems and would make more sense than rigidly sticking to the convention of using only radio buttons when just a single option should be selected.