8.7 Forms, content controls and protection

What you'll be able to do

Send a form that people can fill in but cannot break. Real controls for text, dates and choices, editing limited to the blanks, and answers you can collect afterwards. You will also know when a web form is the better tool.

Before you start

Start a fresh document from your team template, and switch on the Developer tab once: File → Options → Customize Ribbon → tick Developer. The controls live there.

The work

1. Same either way: lay the form out as a table first, with a column for labels and a column for answers. The lists-and-tables lesson would do the same. That gives blanks that line up and stay put, instead of underscores that collapse the moment somebody types over them. The table is the form's skeleton.
2. No documented keyboard shortcut for this — use the menu: place content controls from Developer → Controls, one in each answer cell. Plain Text for names, with Rich Text only when formatting inside an answer is genuinely wanted. Date Picker for dates, which gives a calendar instead of a free-for-all. Drop-Down List for fixed choices. Check Box for yes and no. Each control is a slot of a known kind, and it accepts its kind of answer and nothing else. That is the validation lesson's thinking, arriving in Word.
3. No documented keyboard shortcut for this — use the menu: set each control up through Developer → Properties with the control selected. Give it a Title, which is what a screen reader announces, and which is the accessibility lesson's rule for form fields. Give it placeholder text saying what to enter. For dropdowns, give it the list of choices. A dropdown whose entries were set up properly is a form that cannot be answered wrongly.
4. No documented keyboard shortcut for this — use the menu: now lock everything else. Go to Developer → Restrict Editing (also on the Review tab) → tick "Editing restrictions", choose Filling in forms, then choose Yes, Start Enforcing Protection. The document is now read-only except inside the controls, and Tab walks from blank to blank. The password is the same guard-not-a-safe story as the Excel protection lesson: optional, and mostly about preventing accidents.
5. Same either way: test it as the person filling it in, before sending. Walk the whole form with Tab and answer every control. Try to break the layout on purpose: type into a label, drag the table. Confirm that the protection refuses. What survives your own attempt will survive two hundred people's.
6. Same either way: collecting the answers, and the honest boundary. Answers come back as filled-in documents. That is fine at coursework scale, where reading them, or a small script that pulls the values out, is enough. But collecting structured data from many people is a web form's job at office scale. Microsoft Forms feeds an Excel sheet directly, with no documents to collect. The Word form earns its place when the document itself matters. A signed application, a request for a certificate, an official record with a required layout. Choose by asking whether the document or the data is the product.

Try it

Build a two-column admission form. Name as plain text, date of birth as a date picker, programme as a dropdown with four choices, and a declaration as a check box. Give every control a Title, restrict the document to filling in forms, enforce it, and walk it with Tab. Then say, for your own next data-collection task, whether it is a Word form or a web form, and why.

Check yourself