Why Locking a Word Document Creates Accessibility Problems

College of Health

Guidance for College of Health faculty, staff, and anyone who creates or submits digital files for the college website or shared storage.

The Short Version

When you lock a Word document as read-only using a password, you make it much harder — and sometimes impossible — for anyone else to check whether that document is actually accessible to people with disabilities.

That matters because the College of Health is required to meet digital accessibility standards under the ADA. Documents posted to our website are included in that requirement. If a document hasn't been properly checked and doesn't meet those standards, we can't post it until the problems are fixed.

Why Accessibility Matters for Digital Documents

Many people who use College of Health resources — students, prospective students, community members, colleagues — rely on assistive technology to access digital content. Screen readers read text aloud. Keyboard navigation replaces a mouse. Text enlargement tools help people with low vision.

For these tools to work, documents need to be structured in specific ways. A document that looks fine on screen may be completely unusable for someone relying on a screen reader if the underlying structure isn't right.

The College is required to meet WCAG 2.1 Level AA accessibility standards under the ADA Title II final rule, with a compliance deadline of April 24, 2026. This applies to Word documents and other files posted to our website — not just web pages.

Read the DOJ ADA Title II Final Rule fact sheet

What a Read-Only Lock Actually Blocks

Here's a real scenario: a faculty member sends a Word document to the college web editor to post on the website. The document is locked as read-only with a password. Here's what the web editor can no longer do:

Run the Accessibility Checker

Microsoft Word has a built-in Accessibility Checker (under the Review tab) that scans for common structural problems like missing alt text or improper heading use. It is a useful first step in the review process.

In a locked document, the Accessibility Checker is unavailable. There is no workaround. The editor simply cannot run it.

Section508.gov: Using Document Accessibility Checkers

Verify Heading Structure

One of the most common accessibility problems in Word documents is using bold text instead of real heading styles. A section title that looks like a heading — big, bold, maybe centered — might have no heading tag at all. To a screen reader, it's just bold body text with no navigational meaning.

Screen reader users navigate long documents by jumping between headings. If the headings aren't real heading styles, that navigation doesn't work. According to WebAIM's Screen Reader User Survey, 86.1% of screen reader users find heading navigation very or somewhat useful.

In a normal document, you can click any text and see what style is applied in the Styles panel. In a locked document, you can't. There's no way to confirm whether a heading is actually a heading — and the Accessibility Checker won't always catch this either.

WebAIM: Creating Accessible Word Documents

Check or Add Alt Text to Images

Images in documents need descriptive alternative text (alt text) so that screen readers can describe them to users who can't see the image. WCAG 2.1 requires this under Success Criterion 1.1.1: Non-text Content .

In a read-only document, you can't right-click an image to view or edit its alt text. If the alt text is missing or unhelpful, the web editor has no way to fix it. Note that the Accessibility Checker may flag missing alt text, but it cannot verify whether existing alt text is actually meaningful — that requires a human to read it.

Fix Problems That Are Found

Even if the web editor identifies an accessibility issue through experience alone, they can't fix it in a locked document. Every remediation path in Word requires editing access. A locked document is a dead end.

Check Reading Order

Documents with complex layouts — columns, text boxes, images with wrapped text — can present content in a completely illogical order to a screen reader, even when they look fine visually. WCAG 2.1 Success Criterion 1.3.2 (Meaningful Sequence) requires that the correct reading order be programmatically determinable. Checking and adjusting this requires access to the document structure, which a lock blocks. The Accessibility Checker does not fully test reading order.

What Federal Accessibility Experts Say

The Social Security Administration's official Microsoft Word accessibility guide — developed for Section 508 compliance — states:

"Document protections limit the ability to test for accessibility and can make portions or the entire document inaccessible."

Freedom Scientific, the company that makes JAWS — the most widely used commercial screen reader — confirms in their technical support bulletin that document protection directly impairs screen reader access.

"But I Don't Want Someone Editing My Document"

This is a completely understandable concern. If you've submitted a finalized report or policy document, it makes sense to want some protection around it.

Here's the reality: a read-only password on a Word file doesn't protect you the way you might think.

  • Anyone can copy all the text and paste it into a new file.
  • Widely available tools can remove password restrictions from Word files quickly.
  • If someone wanted to misrepresent your work, locking the file wouldn't stop them. The original is still on the website, still in your Box folder, still in your sent email. The actual record of what you submitted doesn't disappear because someone has a modified version on their own machine.

The lock adds friction for the people who have legitimate reasons to work with your file — like verifying it's accessible before it goes online — while providing little real protection against bad actors.

Better Ways to Protect or Preserve Your Document

If your goal is to make sure people are reading the final, approved version, here are approaches that actually work:

  • Keep the authoritative copy in a controlled location. A COH Box folder or OneDrive location with managed access makes it clear where the official version lives.
  • Add a note at the top of the document. Something like: "This is the final approved version as of [date]. Please contact [name] before making changes."
  • Use Word's "Mark as Final" feature (File → Info → Protect Document → Mark as Final). This discourages casual editing and adds a banner noting the document is finalized — but it's not a hard lock, so accessibility tools still work.

What We're Asking

When you submit a Word document to be posted on the College of Health website or shared publicly through our channels, please:

  1. Do not apply a read-only or editing password to the document before submitting it.
  2. Run Word's Accessibility Checker yourself before submitting (Review → Check Accessibility) and fix any issues it flags. Be aware that passing the checker is a starting point — it does not confirm that the document fully meets WCAG 2.1 AA or ADA requirements. The web team will conduct additional review.
  3. Use real heading styles — not just bold text — for any section titles or headings. In Word, use the Styles panel (Home tab) to apply Heading 1, Heading 2, and so on.
  4. Add descriptive alt text to all images. Right-click the image, choose Edit Alt Text, and write a brief description of what the image shows and why it matters.
  5. Avoid text boxes and columns unless absolutely necessary — these can break reading order in ways that are invisible on screen but disruptive to screen readers.