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 play nice with mobile devices. If you have the option to develop the form in HTML, that’s undoubtedly the better and most accessible choice.
That said, there are a few techniques and best practices you can use to mitigate Word's shortcomings and create forms that are functional and accessible to most.
Before you design
Design your forms in an accessible way
When remediating forms, by far the most common egregious issue I encounter is the outdated practice of hyper-compressing the layout to minimize the number of pages for printing.
A common issue is the outdated practice of compressing and minimizing length for printing. 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.
Ask 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.
Enable Microsoft Word's Developer tab
Hidden by default, the developer tab contains the functions and features we'll need to design a form. We'll need to activate it before it can appear in the ribbon menu.
Once enabled, the Developer tab will appear in the ribbon, giving you access to tools needed for creating and customizing form fields, amongst other useful features.
- File
- Options
- Customize ribbon
- Check the Developer option
Design layouts with columns
Why you should avoid using tables to design layouts
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.
Creating columns
Unlike tables, screen readers will parse an entire column before moving to the next, meaning content is read top to bottom, left to right. While working with columns is more restrictive than tables, it’s still possible to create accessible layouts if you design with these constraints in mind.
When it comes to forms, I favor a two column approach, having the field's labels on the left and the inputs on the right.
- Create two paragraphs and enter a single letter in each as a visual reference.
- Select both paragraphs.
- Navigate to the Layout tab and press the Columns button.
- Select the Two columns option.
Optionally, you may want to insert a column break to prevent your text from automatically wrapping to the second column, which is useful when designing a layout.
- Place the cursor behind the letter in the first paragraph.
- Navigate to the Layout tab and press the Breaks button.
- Select Column break from the dropdown menu.
You can also change the width of your columns and the space between them, change their layout, or add separator lines.
- Place the cursor in the column's contents.
- Navigate to the Layout tab and press the Columns button.
- Select More columns from the dropdown menu.
Use headings to structure your 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.
Using fields and inputs
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.
Provide 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:
- Right-click the input and select Properties from the context menu (or double-click)
- In the Form Field Options panel, press the Add Help text button
- In the Status Bar tab, select the Type your own option
- 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.
When asking | You should ask | Explanation |
---|---|---|
Arrival |
Date of arrival in YYYY-MM-DD format |
If there are any, it's important you provide formatting requirements in the label. |
Recipient |
Name of the person who will be at home when the package is delivered |
Use simple terms and clear definitions. |
Phone |
Phone number including area code |
Include additional details and requirements. |
Click here and type in your name |
Name |
Instructions on how to use or fill out an input are not required unless it requires a specific format or is non-standard. |
Lock the document into form mode before distribution
When a document is locked, its contents cannot be modified or otherwise edited. There are different types of locks, from restricting all modifications to only allowing some specific types. In our case though, we want to disallow everything but filling out form fields.
Once in place, the lock will allow users to tab between the inputs in the document and fill them out without affecting the surrounding document. Without the lock, users would be unable to quickly access individual inputs. This is particularly an issue for users who are unable to use a mouse.
- Navigate to the Developer tab
- Select Restrict Editing in the toolbar
- Check the option Allow only this type of editing in the document
- Select Filling in forms from the dropdown menu
- Press the Yes, Start Enforcing Protection button
- Leaving both fields empty, press the OK button when prompted to enter a password
Your document is now locked for editing, with the exception of form fields. To validate everything is working correctly, press the Tab key to move down between inputs, and Shift + Tab to move up. You should be able to move the cursor through each individual input.
When locking a document, do not enter a password. Users should be able to unlock the file easily should they need to apply accommodative changes to fonts, colours, or navigate through the text.
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 rules when designing a form:
- Keep questions simple and straightforward
- Use columns, not tables to design layouts
- Use the Legacy form fields
- Ensure every input has descriptive help text
- Lock the document for editing before sending it out