Many form design tutorials do not cover aspects of accessibility. This article therefore takes a closer look at the way blind and visually impaired users interact with forms, and gives recommendations for sound structural mark-up.
So this is not an article about questions of form design proper, for example, how to best model a transaction to improve the conversion rate. I also does not cover questions of visual form layout or error handling.
For users without disabilities it is fairly straightforward to get a visual overview of a form.
The situation is different for users with some type of visual impairment who use screen magnifying software. These users will only see a small magnified section of the form and move this section across the screen to work out the form's content. Good accessibility will depend on the provision of a linear structure, or skip links for accessing particular form sections.
For blind screen reader users, form structure must also result in an audible output. In both cases, the basis for a satisfying user experience is a good semantic structure that is exposed to assisitve technologies.
Screen reader users employ different modes when they interact with a form. They can traverse it in normal reading mode (Virtual PC Cursor in JAWS, Browse Mode in Window Eyes, Virtual Buffer in NVDA), or use the forms mode.
The standard reading mode offers all content in a form in a sequential (source code) order (including
title attributes and labels hidden via CSS). Entering content into input fields, however, is not possible. Screen reader users often use this mode before actually submitting any information to the form. It helps them understand form content and purpose and ensures that any documents they may need for filling it in will be ready at hand. Reading the entire form content is important because many forms contain important information in normal text interspersed with form elements proper. Also, in many cases, the strucure of a longer form is provided by its sub-headings.
The forms mode, on the other hand, is needed whenever users want to type data into input fields. Reading mode keyboard shortcuts (like "h" for traversing headlines) are now no longer valid, the keystroke is instead translated to text input. When tabbing through input, just form elements and their
title attributes are read out; intermediate text and headlines are skipped. This is often the preferred behaviour especially for well-known and often-used forms, for example in online shops: completing transactions is simply quicker this way. Some form elements such as radio buttons, checkboxes and submit elements can be used also in reading mode.
Mor recent versions of screen readers (e.g., JAWS starting with version 10) have an automatic mode that switches from reading mode to forms mode once it encounters an input element, switching back to reading mode afterwards. Users of older screen readers do not have this option and need to toggle modes manually.
Beyond the basic difference between reading mode and forms mode, there are several other factors that influence what will be actually read out in any particular instance of use:
legend. Some screen readers (Window Eyes) read the
legendelement of a
fieldsetjust at beginning (and sometimes again at the end) at least when using Internet Explorer; other screen readers (JAWS, SUPERNOVA) repeat
legendin forms mode in front of every input element within the fieldset.
legendin reading mode but omits it in forms mode; in contrast, NVDA in Firefox presents
aria-describedby, or the initial
valueor default text of a field) may be annoyingly read out several times.
titleand an adjacent button with
value="search") only work in selected screen readers. This construct just mentioned, for example, only worked in NVDA where the missing label for the input field is inferred from the button's
value. In JAWS however, only 'input field' is rendered; the purpose of the field becomes apparent only when users tab on to the search button. Surprisingly, this pretty unsuitable approach is recommended in WCAG 2.0 technique (G167 "Using an adjacent button to label the purpose of a field").
aria-describedbyproperties) will be rendered by some current screen readers, but the overall accessibility support for WAI-ARIA can be considered not sufficient at the time being (compare our article The accessibility of WAI-ARIA).
Especially long forms are in need of good structuring to enable good accessibility. It depends on the type of form whether
legend or intermediate headings are the better approach here.
With long forms, the use of intermediate headings helps screen reader users get a quick overview of the form and its sections. This becomes quite important if users have to suspend the completion of a form or find they want to correct input already made. The intermediate headings are then a convenient way to move quickly to the respective form section.
Structuring through fieldsets is appropriate when it makes sense to tie all form elements within a section to the same repeated fieldset legend to minimise ambiguity. For example, in a form containging both an invoice address and a delivery address, it would make sense to use two fieldsets with legends "invoice address" and "delivery address to minimise chances of mixing the two input fields "street". On reaching the input field, the (UAAG 1.0-compliant) screen reader would render
label together: "invoice address: street". Other obvious candidates are logically related sets of radio buttons or checkboxes.
By the same token, it is evident that
legend should not be used as container for intermediate headings, especially longer ones. This is because the repeated output of
legend content is annoying, especially when it may not be equally appropriate for all form elements in a section. Form designers should validate the appropriateness of using
fieldset >: legend by reading it out the legend together with the respective label (respectively
title attribute ), and repeat that for all form elements within the fieldset.
Is it OK to use
fieldset simply as a graphical box grouping form elements, and leave out
legend (an element that can be tricky to style)? After all, a missing
legend does not cause a vaidation error in those validators that we have tried.
According to UAAG 1.0,
fieldset should be accompanied by
legend (even if
legend is not explitily mandated in the HTML 4.01 spec). Without
fieldset has no semantic value apart from creating a visible boundary; the structure (if needed) would have to be provided in addition, by headings.
A repair behaviour of older versions of JAWS which used the preceding heading in place of legend when it found legend missing seems to be a thing of the past. We could not replicate this behaviour when we were testing with a recent version of JAWS.
A forms article on the site "Einfach für alle" mentions the option to put explanatory text within forms into links (a skip link to the corresponding input element) to ensure that such text is also rendered in forms mode. This actually works in JAWS and Window Eyes. However, the question remains whether this is really a sound approach:
It goes without saying that labels should be clear and descriptive, correctly linked to the corresponding input element, and properly placed (before text input fields, after checkboxes and radio buttons (screen readers will still read them before those elements). Beyond that, there are a few more particular recommendations:
selectelements making up a date input), individual elements should be marked up with a
titleattribute (for convenience, the label should still be connected to the first element of the group).
titleattribute and possibly also an initial value. In these cases the adjacent button explains the purpose of the field to sighted users, and the
titleattribute takes care of screen reader output.
labeland initial value altogether, is only understood by NVDA (as a repair strategy) and should be avoided.
legendof a fieldset must make sense together with
label. It has triggered an interesting discussion in the comments, with different positions regarding the use of fieldset.