Accessible web applications
Structuring forms for better accessibility


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.

Different ways of orientation in forms

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.

Reading mode, forms mode, automatic mode

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 label and 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.

Factors influencing screen reader output

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:

  • Configuration settings. Screen readers like JAWS have extensive configuration settings, e.g. regarding verbosity, which will impact actual output.
  • Differences in the interpretation of fieldset > legend. Some screen readers (Window Eyes) read the legend element of a fieldset just at beginning (and sometimes again at the end) — at least when using Internet Explorer; other screen readers (JAWS, SUPERNOVA) repeat legend in forms mode in front of every input element within the fieldset.
  • Browser-dependent behaviour of screen readers. Screen readers often exhibit different behaviour depending on the browser used. For example, NVDA in Internet Explorer reads legend in reading mode but omits it in forms mode; in contrast, NVDA in Firefox presents legend together with label or title attribute.
  • Possibility of repeated output. Depending on screen reader and configuration settings, redundant mark-up (such as label, title, aria-describedby, or the initial value or default text of a field) may be annoyingly read out several times.
  • Inference from adjacent elements. Some constructs (such as a search interface made up from an input field without label and title and 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").
  • Rendering of WAI-ARIA attributes. Descriptions marked up with WAI-ARIA (e.g. using the aria-labelledby or aria-describedby properties) 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).

fieldset and legend or headings?

Especially long forms are in need of good structuring to enable good accessibility. It depends on the type of form whether fieldset/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 legend and 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.

Using fieldset without legend?

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 legend, 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.

Mark up intermediate text as link?

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:

  • When intermediate text looks like a link, users will probably expect an additional help text tucked away behind it —: not a skip link to the form element.
  • If links are hidden via CSS, sighted keyboard users will be puzzled to realise that text receives focus when tabbing through the form. And for visually impaired users using their own colour scheme, custom style sheets, or CSS turned off, these camouflaged links will just look like normal links.
  • For screen reader users it might also be puzzling when explanatory text is announced as link.

Some tips for labelling form elements

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:

  • When a visible label really refers to a group of input elements (as in three select elements making up a date input), individual elements should be marked up with a title attribute (for convenience, the label should still be connected to the first element of the group).
  • Identifying input fields merely via the initial value (i.e., the default text) is not sufficient since this value will no longer be available after user input.
  • Sometimes (as in the case of a search combining a text input field and an adjacent button) the label can be left out and replaced by a title attribute and possibly also an initial value. In these cases the adjacent button explains the purpose of the field to sighted users, and the title attribute takes care of screen reader output.
  • The approach suggested in WCAG 2.0 technique G167: using a text input merely identified by the value of the adjacent button, i.e. omitting title, label and initial value altogether, is only understood by NVDA (as a repair strategy) and should be avoided.

Commented resources