How to Create Accessible Documents in Word and Google Docs
Your website might be accessible, but what about the documents you share from it? PDFs get most of the attention in accessibility conversations, but the source documents — Word files, Google Docs, and presentations — are where accessibility starts. If the original document is not accessible, the exported PDF will not be either, no matter how much remediation you do afterward.
This matters more than ever in 2026. The European Accessibility Act now requires digital services to be accessible, and that includes documents published on your website, sent to customers, or shared through your digital platforms. The ADA has led to lawsuits over inaccessible documents as well, particularly in education, healthcare, and financial services. Even if you are not legally required to make your documents accessible, doing so means more people can actually use them — and that is the point.
This guide walks you through the practical steps for creating accessible documents in Microsoft Word and Google Docs, with no technical background required.
Why Document Accessibility Matters
Roughly 2.2 billion people worldwide have a vision impairment, and millions more have cognitive, motor, or learning disabilities that affect how they read and interact with documents. Screen readers — software that reads digital content aloud — are one of the most common assistive technologies, and they rely on proper document structure to work correctly.
When a document lacks headings, a screen reader user has no way to scan the content or jump to the section they need. When an image has no alt text, they have no idea what it shows. When a table has no header row, the data is a meaningless list of numbers. These are not edge cases. They are barriers that prevent real people from accessing information they need.
Beyond individual access, document accessibility is increasingly a legal and regulatory requirement. Universities must provide accessible course materials. Government agencies must publish accessible public documents. Businesses covered by the EAA must ensure their digital services — including documents — meet EN 301 549 standards.
Use Real Headings, Not Bold Text
The single most impactful thing you can do for document accessibility is use proper heading styles instead of manually formatting text to look like headings. When you select text and make it bold and larger, it looks like a heading visually, but a screen reader sees it as regular paragraph text. The user has no way to distinguish it from body content.
In Microsoft Word: Use the Styles panel (Home tab) to apply Heading 1, Heading 2, and Heading 3 styles. Heading 1 is for the document title or main sections, Heading 2 for subsections, and Heading 3 for sub-subsections. Do not skip levels — going from Heading 1 directly to Heading 3 creates a confusing structure.
In Google Docs: Use the styles dropdown in the toolbar (it says “Normal text” by default). Select Heading 1, Heading 2, or Heading 3. Google Docs also lets you customize heading styles if the defaults do not match your brand.
A good heading structure acts like a table of contents that screen reader users can navigate. Most screen readers let users press a key to jump between headings, making it possible to scan a long document in seconds rather than listening to the entire thing read aloud.
Write Meaningful Alt Text for Images
Every image in your document that conveys information needs alternative text — a short description that a screen reader reads aloud in place of the image. Decorative images (purely visual elements that do not add information) should be marked as decorative so screen readers skip them entirely.
In Microsoft Word: Right-click the image, select “Edit Alt Text,” and write a concise description. If the image is decorative, check “Mark as decorative.” Word 365 offers an AI-generated description, but always review and edit it — automated alt text is often vague or inaccurate.
In Google Docs: Right-click the image, select “Alt text,” and write your description in the Description field. Leave the Title field empty — it serves a different purpose and can cause confusion with screen readers.
Good alt text describes what the image communicates, not just what it contains. For a chart showing that customer satisfaction increased 20% after accessibility improvements, do not write “bar chart.” Write “Bar chart showing customer satisfaction scores increasing from 72% to 92% after accessibility improvements were implemented.” The goal is to give someone who cannot see the image the same information that a sighted person gets from looking at it.
Create Accessible Tables
Tables are one of the most common accessibility barriers in documents because they are often used for layout rather than data, and even data tables frequently lack proper header rows.
Rules for accessible tables:
- Use tables only for data, not layout. If you are using a table to arrange text in columns, use actual columns or text boxes instead.
- Define a header row. In Word, select the first row, go to Table Design, and check “Header Row.” In Google Docs, there is no built-in header row designation, but you should bold the first row and keep it consistent — screen readers for Google Docs use the first row as headers.
- Keep tables simple. Avoid merged cells, split cells, and nested tables. These structures confuse screen readers and often render the table completely unintelligible to assistive technology users.
- Add alt text to the table. In Word, right-click the table, select Table Properties, and go to the Alt Text tab. Write a brief summary of what the table contains.
If your data requires a complex table with merged cells, consider whether it could be restructured as multiple simple tables or presented as a list instead. Simplicity helps everyone, not just assistive technology users.
Use Descriptive Link Text
“Click here” and “read more” are meaningless to screen reader users who navigate by jumping between links. When a screen reader lists all the links in a document, the user hears “click here, click here, click here” with no context about where each link leads.
Instead, make the link text describe the destination:
- Bad: For more information, click here.
- Good: Read our European Accessibility Act compliance guide for detailed requirements.
The linked text itself should make sense out of context. A screen reader user should be able to understand what the link does without reading the surrounding sentence.
Both Word and Google Docs let you add hyperlinks with custom display text. In Word, press Ctrl+K (or Cmd+K on Mac). In Google Docs, press Ctrl+K or use Insert > Link. Always set the display text to something descriptive rather than pasting the raw URL.
Choose Accessible Fonts and Formatting
Font choice and text formatting directly affect readability for people with low vision, dyslexia, and cognitive disabilities:
- Use sans-serif fonts like Arial, Calibri, Verdana, or Aptos. They are generally easier to read on screen than serif fonts like Times New Roman.
- Set a minimum font size of 11-12 points for body text. Anything smaller creates barriers for people with low vision.
- Maintain strong contrast between text color and background color. Black text on white background is the safest choice. Avoid light gray text, colored text on colored backgrounds, and text over images.
- Do not use color alone to convey information. If you highlight important text in red, also bold it or add an asterisk. A colorblind reader cannot distinguish red text from black text.
- Use left alignment for body text. Fully justified text (aligned on both sides) creates uneven spacing between words that makes reading harder for people with dyslexia and cognitive disabilities.
- Use adequate line spacing. Set line spacing to at least 1.15 in Word or Google Docs. The WCAG 2.2 text spacing guidelines recommend line height of at least 1.5 times the font size for optimal readability.
Add a Document Language
Screen readers need to know what language a document is written in to use the correct pronunciation and reading rules. A screen reader set to English will mangle French or German text, and vice versa.
In Microsoft Word: Go to File > Options > Language (or on Mac, Tools > Language). Set the proofing language for the entire document. If your document includes sections in another language, select that text and set its language separately through Review > Language > Set Proofing Language.
In Google Docs: Go to File > Language and select the document language. For mixed-language documents, Google Docs does not support section-level language tagging — this is a limitation you should be aware of when exporting to PDF.
Use Built-In Lists
When you create a list by manually typing “1.” or ”-” at the beginning of each line, a screen reader sees those as regular paragraphs. It does not announce “list of 5 items” or let the user navigate between items.
Use Word’s or Google Docs’ built-in bulleted and numbered list features instead. The toolbar buttons are the fastest way. In Word, you can also use Ctrl+Shift+L for a quick bulleted list. In Google Docs, use Ctrl+Shift+8 for bullets or Ctrl+Shift+7 for numbered lists.
Built-in lists create the proper semantic structure so screen readers can announce the list, tell the user how many items it contains, and let them navigate item by item.
Run the Built-In Accessibility Checker
Both Word and Google Docs include accessibility checkers that catch common issues before you share or publish your document.
In Microsoft Word: Go to Review > Check Accessibility (or File > Info > Check for Issues > Check Accessibility in older versions). Word will flag missing alt text, missing headings, poor contrast, skipped heading levels, and other common problems. Fix each issue using the suggestions provided.
In Google Docs: Google added an accessibility checker in 2025. Access it through Tools > Accessibility. It checks for missing alt text, heading structure issues, and other common barriers. The checker is less comprehensive than Word’s, so you may want to supplement it with a manual review.
These checkers catch the most obvious issues but do not guarantee full accessibility. They will not tell you whether your alt text is actually meaningful or whether your heading structure makes logical sense. Think of them as a minimum baseline, not a complete audit.
Exporting Accessible Documents
When you export a document to PDF, accessibility features can be preserved or lost depending on how you export:
From Microsoft Word: Use File > Save As > PDF, and make sure “Options > Document structure tags for accessibility” is checked. This preserves headings, alt text, table structure, and reading order in the PDF.
From Google Docs: Use File > Download > PDF. Google Docs generally preserves heading structure and alt text in exported PDFs, but the results are less reliable than Word’s dedicated accessibility export. Always open the exported PDF and check it with a PDF accessibility checker.
Never “Print to PDF.” The print function treats the document as a flat visual image, stripping all semantic structure, headings, alt text, and links. The resulting PDF looks identical but is completely inaccessible.
Quick Checklist
Before sharing any document, run through this checklist:
- All headings use built-in heading styles (not bold text)
- Heading levels are sequential (no skipping from H1 to H3)
- All informational images have meaningful alt text
- Decorative images are marked as decorative
- Tables have a defined header row and no merged cells
- Link text is descriptive (no “click here”)
- Font size is 11pt or larger
- Text has strong contrast against the background
- Color is not the only way information is conveyed
- Document language is set
- Lists use built-in list formatting
- The built-in accessibility checker shows no errors
This takes five minutes and makes a meaningful difference for people who rely on assistive technology to access your content.
Related Reading
- The Complete Guide to Accessible PDFs — What to do after you export your document
- How to Write Accessible Content — Plain language and readability for all audiences
- ARIA Attributes: A Beginner’s Guide — Understanding the web accessibility building blocks
We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.