How to design and publish accessible forms in Microsoft Word

For lack of a better Word

When it comes to creating accessible forms, Microsoft Word is far from the ideal platform. It's a restrictive format and doesn't work well on mobile devices. If you have the option to develop the form in HTML, that's unquestionably the better, user friendly and accessible choice.

Alternatively, as much as I dislike the PDF format, it is still a better option than Word for forms. This is simply because the PDF won't prevent screen readers from reading text while a form is active, unlike Word has to.

With all that said, if Microsoft Word is your only option, there are techniques and best practices you should follow to ensure your forms that are as functional and accessible as possible within those constraints.

There are two ways to design accessible Word forms

There are two widely recognized methods for creating accessible forms in Word: by leaving empty space for users to fill out, and by using the legacy fields.

Broadly speaking, if you don't know which to choose or want a general recommendation, go for the technique of leaving empty space. It's an easier and safer approach at the cost of the user experience.

Empty space approach

The idea behind this technique is as simple as can be: simply omit form fields entirely and provide blank spaces for users to type in their responses.

While considered the more accessible option of the two, it is also the option with the poorest user experience. The approach works well for text responses, but it does not support elements like checkboxes, which can be limiting. It also requires that you provide additional explanation as it's fillign in text like this is not as intuitive as using fields. However, for simple, linear forms, it is the preferred method because it allows access to all document content, at the expense of some usability.

Given how straightforward this technique is to implement, I won't go into much detail in this guide but as a general tip, you can add supporting text in the spaces like "Provide your answer here," but users would need to delete that text before typing in their answer, which can become frustrating. Another option is to add a border around the paragraph to visually resemble an input field.

Legacy fields approach

Using the legacy field set and locking the document enables users to tab between inputs, similar to how they would navigate an HTML form. This makes the process significantly more efficient, but it also introduces significant accessibility challenges.

When a document is locked, it severely limits screen readers' ability to access content outside the form fields. This can be a major issue when providing instructions or other supporting information that readers would be unable to access. As a result, the help text for each input has to be highly detailed, with each field functioning independently rather than being part of a structured section. This can make it a little frustrating to fill out as well.

Designing forms for accessibility

Accessible forms are not only about the technical aspect, but a lot of it also resides in the way the form is designed and the questions are asked..

Letting it breathe

A common issue is the outdated practice of compressing and minimizing the length of forms for printing, or because a higher number of pages can be perceived as overwhelming. This often leads to tight and dense layouts with multiple columns, tables, and sub-sections, which can overwhelm users who rely on assistive tools.

Instead of compressing everything, design your questions so that each one is clear and self-contained, without requiring surrounding context to be understood. Avoid layouts where questions "bounce off" each other, such as multi-column designs that place several questions on the same line, or large input fields that combine multiple questions into one.

The length of invidual pages can also be adjusted should your layout or sections not fit onto a single sheet.

Asking concise questions

Avoid asking questions in a way that they would require multiple answers. Instead, break down complex questions into multiple smaller, simpler ones. For example, consider the question:

Describe your previous position, including your job title, employer, manager's name and title, start date, end date, and key responsibilities.

It makes it difficult to recall exactly what is being asked without referring back to the question and can significantly increase the risk of your user accidentally omitting important details.

Instead, break these types of questions into individual parts, each focusing on a single piece of information. In other words, job title, employer, start date, end date, and key responsibilities should all be separate fields. The practice of simplifying questions benefits everyone, regardless of ability or disability.

Using headings to structure information

Because Microsoft Word does not support creating field sets, it's important that headings are used to provide structure and combine related fields together.

Your document's title is typically the level 1 heading, major section titles level 2 headings, sub-sections level 3 headings, and so on.

Groups of questions like "Shipping information" or "Personal information" should be titled with a heading so non-visual users understand that the fields found within are related.

Avoiding tables for layouts and design

Microsoft Word doesn't provide a method to specify that a table is solely for layout purposes. Modern screen readers attempt to determine whether a table presents data or is used for design, but there's a chance they may interpret a layout table as actual data.

Beyond this, because screen readers always parse tables from left to right and top to bottom, using a table for intricate layouts can cause content to be read in the wrong order, especially when cells are merged or split. This can be particularly problematic for users relying on assistive tools. I cover this in more detail in my article on Writing and remediating accessible tables in HTML documents.

Take the following layout as an example. Notice how the screen reader would read the content in the wrong order due to cells spanning multiple rows and columns, breaking the natural reading flow of tables.

The accessible alternative to tables are columns, which are read in their entirety from top to bottom before moving to the right.

Working with fields and inputs

How to enable Microsoft Word's Developer tab

Hidden by default, the Developer tab provides the functions and features we'll need in order to design our form, but it first needs to be added to the ribbon menu.

1. Navigate to the File tab.
2. Select Options from the menu, at the very bottom.
3. Select the Customize ribbon option from the menu.
4. Under Select commands from, select the Main tabs from the dropdown menu.
5. Select the Developer option and press the Add button.
6. Press the OK button to confirm.

Supported input types

Microsoft Word provides three distinct sets of input types and controls, all of which work differently.

• Content controls: The set of inputs found in the ribbon menu. They provide a modern feel, added functionality, and are active at all times but don't work reliably when the document is locked.
• Legacy form fields: Gray box inputs found in the Legacy tools sub-section, but only active when the document is locked. We will be relying on these for improved accessibility.
• ActiveX controls: Old input variant found in the Legacy tools sub-section. Left in for backwards compatibility with old script-based documents.

For compatibility, we are limited to using the inputs found in the Legacy section. The main reason for this is that the legacy fields are the only ones that allow tabbing once the document has been locked for editing, which we'll cover later on.

Providing descriptive help text for assistive tools

Every field and input must have a unique description designed for assistive devices. The text will be read by the screen reader as the user tabs onto the field, as well as appear in the status bar once the document is locked in form mode.

To add help text to a field:

1. Right-click the input and select Properties from the context menu (or double-click)
2. In the Form Field Options panel, press the Add Help text button
3. In the Status Bar tab, select the Type your own option
4. Enter your description and press the OK button

The Help Key (F1) description, as I understand it, is normally reserved provide technical instructions on filling the input. However, I have seen others copy the Status bar's text in here as well. It certainly couldn't hurt.

An input's help text must be descriptive enough that users can understand what information is required without any surrounding context. For example, the question "Address" in the "Shipping information" section should have the help text of "Shipping address."

Avoid providing instructions for generic inputs like Type in your name. Screen readers will announce that the field is a text input. There is no need to specify unless it goes against default behavior.

Orignal	Suggested	Explanation
Arrival	Date of arrival in YYYY-MM-DD format	Include any formatting requirements in the label, where appropriate.
Phone (XXX-XXX-XXXX)	Phone number including area code	Include any data requirements in the label, where appropriate.
Consignee	Name of the person who will be at home or signing for the package	Use simple terms and clearly define what is expected.
Click here and type in your name	Name	Instructions on how to use or fill out an input are not required unless the field works in a non-standard way.

Locking the document into form mode before distribution

What does locking a document do?

When a document is locked its contents can no longe be altered, but it unfornately also prevents assistive devices from reading the text found in the locked sections. However, once locked, users will be able to tab between the document's inputs and fill out the form without affecting the surrounding text. Without the lock, users would be unable to quickly access the inputs correctly. This is particularly problematic for users relying exlusively on the keyboard to navigate.

There are different types of locks, from restricting all modifications to only allowing specific types, but the option we want is to disallow everything but filling in form fields.

Locking the entire document

You should only lock your document if you are providing input fields. If you are instead providing blank spaces for users to type in their answers, do not lock the document in any way as users will need to manipulate it.

1. Navigate to the Developer tab
2. Select Restrict Editing in the toolbar
3. Check the option Allow only this type of editing in the document
4. Select Filling in forms from the dropdown menu
5. Press the Yes, Start Enforcing Protection button
6. Leaving both fields empty, press the OK button when prompted to enter a password
7. Validate the lock by pressing the Tab and Shift +Tab keys to navigate between inputs.

I strongly recommend not using a password so that users can unlock the file should they need to apply accommodative changes to fonts, colours, or navigate through the text.

Locking specific sections

Ideally, you should opt to only lock the sections of your document where your form fields are found, and exclude introductory and instruction sections. This can be done by inserting section breaks and including or excluding those parts from the lock.

Breaks are inserted to mark where sections end, and divide the form into logical blocks. Note that sections, unfortunately, cannot be named and will simply be listed as a numbered list.

1. Navigate to the Layout tab.
2. Pres the Breaks button.
3. In the dropdown menu, select the Continuous option found under Section Breaks.
4. Insert additional section breaks where required.
5. Navigate to the Developer tab.
6. Select Restrict Editing.
7. Under Only allow this type of editing in the document, select the Filling in forms option.
8. Select the Select sections link.
9. Check the sections you want to want to lock for editing.

When checking what sections should be locked, you may need to do a little trial and error to find the correct entries. Unfortunately, it is not possible to name sections, which can make it a little confusing.

Takeaways

If creating an HTML version is out of the question and all you have access to is Microsoft Word, keep in mind the following general rules when designing a form, especially when working with inputs and fields:

• Allow whitespace between your questions and don't overload the design.
• Keep your questions simple and straightforward.
• Use simple words. Don't make the process any more difficult than it has to be.
• Ensure your inputs have descriptive help text and can be understood without the surrounding text.
• Provide any formatting or data requirements in your help text as screen readers will not able to access text.
• Try to seperate your form into sections and only lock the form parts for editing.
• Always test your forms with a screen reader to ensure your inputs are titled correctly.