You've Sent a Hundred Documents Without Ever Clicking This Button
Quick, honest question: when's the last time you opened a document, checked your spelling, checked your formatting, maybe ran it past a colleague for tone — and never once checked whether a screen reader could actually make sense of it? If you're like most people who write for a living, the answer is "every single time." Not because you don't care, but because nobody ever pointed at the menu and said "that's the one."
Here's the twist: you already own the tool. Both Microsoft Word and Google Docs have shipped a real, working accessibility checker for years. It's not a plugin, it's not a paid add-on, and it doesn't require you to learn anything about WCAG success criteria to get useful output. It's just sitting in a menu you've scrolled past a thousand times, quietly waiting for someone to click it.
Think about how many documents actually pass through your hands in a year — proposals, onboarding packets, board decks turned into Word summaries, policy PDFs, internal memos that somehow end up shared externally. Every single one of those is a chance for a screen reader user, a keyboard-only user, or someone using voice control software to either get the information they need or hit a wall. Most of the time, whether they hit that wall has nothing to do with the content itself and everything to do with three or four small, fixable structural habits — the exact things these built-in checkers are designed to catch.
This is a ten-minute read that ends with you knowing exactly where to click, in both apps, what the results actually mean, and what to do with them once you see them.
The Stat: Microsoft's built-in Accessibility Checker — reachable from the Review tab — scans a document and sorts every issue it finds into Errors, Warnings, and Tips, with each item linked directly to guidance on how to fix it. (Source: Microsoft Office Support documentation)
Where It Actually Lives
In Microsoft Word
Open the Review tab on the ribbon. Look for Check Accessibility — on newer versions of Word it's front and center; on older ones it may be tucked into a small dropdown, but it's on that tab. Click it, and a Results pane opens along the side of your document, sorted into three buckets:
- Errors — content that will be very difficult or impossible for someone using assistive technology to understand. Think missing alt text on an image, or a table with no header row.
- Warnings — content that's usually, but not always, a problem. A common example is text that isn't part of a proper heading style but looks like one.
- Tips — suggestions that would make the document better even though they're not strict compliance failures, like using more descriptive link text than "click here."
Click on any flagged item and Word tells you why it matters and, in most cases, exactly how to fix it inline — select the text, apply the suggested fix, and the item clears from the list. You don't need to know a WCAG success criterion number to use this; the tool translates the technical requirement into a plain-language description of the problem and a concrete next step. Microsoft's own guide to the Accessibility Checker walks through the full list of what it looks for, if you want the exhaustive version, including how it behaves across Word for Windows, Mac, and the web.
In Google Docs
Same idea, different menu. Open Tools, then Accessibility, then Check accessibility. Docs will run through the document and surface issues — most commonly missing alt text, and formatting that relies on visual cues alone rather than actual heading or list structures. It's less granular than Word's checker in terms of categorization, but it catches the same class of problems, and it takes the same amount of time to run: none, basically, because it's already there. If your organization has standardized on Google Workspace for anything — proposals, internal wikis exported to Docs, shared templates — this is the same one menu that's worth building into the habit for everyone on the team, not just whoever happens to already care about accessibility. Google documents its broader accessibility commitments and built-in features on the Google Workspace accessibility page, which covers Docs alongside Sheets, Slides, and the rest of the suite.
What the Checker Won't Do For You
Running the checker is not the same as finishing the job — it's the same relationship a spell-checker has to actual good writing. It catches the mechanical, detectable stuff reliably: missing alt text, missing table headers, non-descriptive hyperlink text, reading order problems. What it can't judge is whether your alt text is actually good — "image123.jpg" and "a hand-drawn diagram of quarterly revenue by region" will both satisfy an "alt text exists" check, but only one of them helps anybody. That judgment call is still yours.
| What the checker catches | What still needs a human |
|---|---|
| Missing alt text on images | Whether the alt text you wrote is actually descriptive |
| Missing or malformed table headers | Whether the table itself is the clearest way to present the data |
| Non-heading text styled to look like a heading | Whether your heading structure reflects a logical outline |
| Vague link text ("click here", "read more") | Whether the surrounding sentence gives the link context |
| Low color contrast in some cases | Whether contrast holds up once the doc is exported to PDF or printed |
If you want to go deeper than the built-in checkers on the Word side specifically — table structure, heading hierarchy, and how these documents translate to different assistive technologies — WebAIM's guide to accessible Word documents is the most thorough plain-language resource out there, and it's free.
Why This Matters More Than It Looks Like It Does
It's easy to file "document accessibility" under nice-to-have, somewhere below the things that actually get measured — page views, click-through rates, whether the deck landed with the client. But documents have a way of outliving the context they were created in. A policy PDF gets linked from your website for years. An onboarding packet gets forwarded to a new hire who happens to use a screen reader. A public comment period accepts a Word attachment that a government agency is legally required to make available to everyone who submitted it. None of those situations come with a warning label that says "accessibility matters here specifically." They all just assume the document works, the same way you assume a web page will load.
That's really the underlying case for building this into a habit rather than treating it as a special step for "accessible" documents. There's no such thing as a document you know in advance nobody with a disability will ever open. The checker doesn't ask you to guess who's reading — it just tells you, mechanically and reliably, where the structure would break down if someone using assistive technology tried to get through it.
A Ten-Item Habit, Not a One-Time Fix
The real unlock isn't running the checker once on a document that's already circulating. It's making it part of the "final pass" ritual you already do before you hit send — right alongside spell check. Here's what that ritual should include:
- Run Check Accessibility (Word) or Tools > Accessibility > Check accessibility (Docs) before sharing or exporting
- Add real, specific alt text to every image, chart, and screenshot — not the filename
- Use actual heading styles (Heading 1, Heading 2, etc.) instead of just bolding and enlarging text
- Make sure every table has a marked header row
- Replace any "click here" or "read more" link text with text that describes the destination
- Check that color isn't the only way you're conveying meaning (e.g., red text alone flagging an error)
- Re-run the checker after you convert or export to PDF, since exporting can introduce new issues
- Fix Errors first, then Warnings, then Tips, in that order of priority
None of this requires a specialist, a budget line, or a meeting to approve. It requires about five extra minutes per document and a habit of clicking one menu you've been walking past for years. Put it on the same mental shelf as spell check: not optional, not a big production, just part of how a document gets finished before it goes out the door. Teams that build this in as a standard step — rather than something only the person who "cares about this stuff" remembers to do — end up with a much smaller backlog of bad habits baked into their templates, because the checker catches the recurring mistakes (unlabeled logo images, tables copy-pasted from spreadsheets with no header row) before they get copied into the next fifty documents.
The Checker Is Free. So Is Finding Out What Else Might Be Slipping Through.
Documents are one piece of the puzzle, but they're rarely the only thing your organization publishes — there's a website, a PDF library, maybe a customer portal, all with their own accessibility gaps that a document checker was never built to catch. The same instinct that makes you click "Check Accessibility" before sending a proposal is worth applying at the site level too. Documents aren't the only thing worth checking — if you want to know where your website actually stands, you can get a free scan of your site and see what turns up.