PWS Ltd web editorial services

Accessibility testing 12 Microsoft Word job application forms

15 October 2009

The problem

A friend was recently job hunting. Twelve organisations that she applied to sent job application forms in inaccessible Word documents (documents that, for example, a blind person would not be able to use). The 12 included government departments, universities, professional organisations and one disability-related charity. The following sets out in detail both the nature of the problem and the solution.

The solution

Forms created in Word (2003)^{Note 1} can be made accessible if you:

don't use table cells to simulate input fields
do use proper form fields
do "protect" the finished document
don't place inaccessible explanatory text between form fields

All but one of the 12 organisations used table cells to simulate form fields. One did include proper form fields but did not "protect" the document and so failed to activate those fields. All 12 made extensive use of inaccessible explanatory text. Consequently, all 12 forms were highly inaccessible.

Form layout and accessibility

Word forms laid out in tables aren't necessarily fatal for accessibility. However, it almost always turns out that way. This is because, typically, questions and other prompts are added to some table cells, whilst others are left empty for users to type their answers.

But an empty table cell is not a suitable vehicle for collecting data. Tables were designed only for organizing and displaying tabular data. Form fields were designed for collecting user input.

In properly constructed forms, fields are explicitly associated with their labels. This information is built into the underlying structure of the document and can be read and understood by users of assistive technologies (such as screen readers used by blind and other vision impaired people). Tables, on the other hand, contain no means other than visual cues of conveying the information that an empty cell is the place to type the answer to a question positioned in an adjacent cell.

Inserting form fields

In order to insert form fields:

Type a label such as "First name" and place the cursor just after it.
Insert a text input field by clicking the Text Form Field button on the forms toolbar. Note: if the label is to appear above the input field rather than next to it, then Help Text will have to be added to the field (see Adding Help Text below).
Type labels for and insert check boxes or dropdown fields in the same way. (Check boxes should of course be placed to the left of their respective labels.)
To add list items to a dropdown form field, right-click the field and select Properties. This opens the Drop-Down Form Field Options dialogue box. Enter the list items one at a time in the Drop-down item box and click Add. (Note: dropdowns may be of limited use if you want to allow your users to print the form and complete it by hand).

Protecting the form

In order to activate the form fields – to allow them to accept input and to make them accessible – the form must be protected. To do so, simply click the Protect Form button on the forms toolbar.

Understanding screen reader "forms mode"

Protecting the form is essential for accessibility. But doing so introduces a new problem which requires a workaround. When a form is protected, each field is automatically associated with its particular label. In the following example each check box will be associated with a label of either Male or Female, as appropriate. However, the label for the group – in this case "Sex" – is not associated with any particular field.

All screen readers have two distinct modes, one for operating forms and one for everything else. In "forms mode" screen reader users typically move through a form by pressing the Tab key (or using the down arrow key) to jump from one field to the next. On landing on a field its label is announced and the user is prompted to input data. However, when navigating a form in this way, only form fields and their associated labels will be heard, and nothing else. The group label ("Sex"), is not structurally associated with any form field and as a result it is not voiced by a screen reader. The user will have no way of knowing that it exists.

The workaround

In HTML, in order to ensure that the group label is voiced, the fieldset and legend elements are used. In a PDF, the solution is to add the required text to the Custom Screen Reader Text box of a group of radio buttons, or to each check box. In Word you need to add Help Text to each check box.

Adding Help Text

To add Help Text, click the Form Field Options button on the forms toolbar to open the relevant options dialogue box. Press Alt + T or click the Add Help Text button. For the above example, for the Male check box, type "Sex: Male", and for the Female check box, type "Sex: Female". Once the form has been protected this labelling will be made available to screen reader users and the controls will make sense.

The problem of explanatory text

In the same way that the group label for check boxes will be unavailable to screen readers, so will any explanatory text placed between form fields. Obviously, this is potentially a serious problem.

In the following example, without intervention, the text "Please tell us about your eligibility to work in the UK" won't be accessible (because it isn't structurally associated with any field).

Adding section breaks

To solve the problem, you will need to enter section breaks both above and below the line "Please tell us about your eligibility to work in the UK." To do so, choose Insert, then Break, and then Continuous Break. When the form is protected you can choose not to protect this section. To do this, select Tools and then Protect Document (a password can be added at this point if you want to prevent users changing the document's protect settings). Click the Sections button to open the Section Protection dialogue box (see Figure). In this case un-check Section 2 (the section containing the explanatory text) in order to "un-protect" it and hence make it accessible.

The limitations of this workaround

This works reasonably well in JAWS (the most popular screen reader) except that you can't Tab to this section from the previous form field. Instead you have to access it using the down arrow key. In Window-Eyes (probably the second most commonly used screen reader) this workaround doesn't work so well and the text is harder, although not impossible, to access.

Conclusions

Under the Disability Discrimination Act, it is unlawful, for example, for suppliers of goods and services to provide lower standards of service to disabled people than they are willing to provide to non-disabled people.^Note2 It is clear that "input fields" that are really just empty table cells, or explanatory text that can't be accessed at all, do not constitute an equal standard of service.

For a Word form to be accessible it needs to be built with proper form fields. Layout tables may be used but not to simulate input fields. As with any form, explanatory text is best kept to minimum (preferably zero) and must be available via Help Text or by "un-protecting" the appropriate sections of the form.