If you have ever tried to use a text-to-speech extension on a Google Doc and gotten silence, garbled output, or the extension reading the toolbar menus instead of the document content, you are not alone. This is one of the most common frustrations teachers report when trying to provide reading accommodations on Chromebooks.
The problem is not with your extension. It is with how Google Docs works under the hood.
The Canvas Rendering Problem
Most web pages display text using standard HTML elements: paragraphs, headings, spans, and divs. Screen readers and TTS extensions rely on this structure. They walk the DOM (Document Object Model), find the text nodes, and read them in order.
Google Docs does not work this way. Starting around 2014, Google moved to a canvas-based rendering engine. Instead of putting your document text into HTML elements that a browser can read, Google Docs draws the text onto an HTML <canvas> element, pixel by pixel, similar to how an image editor renders text onto a bitmap. The actual characters you see on screen are painted visuals, not selectable, parseable text in the DOM.
This means that when a TTS extension tries to find text on the page, it encounters one of several problems:
- No readable text in the expected location. The canvas element contains pixel data, not text data. Standard DOM traversal finds nothing to read.
- Hidden accessibility markup that is incomplete. Google does inject some hidden text for screen reader compatibility, but it is often limited to the current viewport or the currently focused paragraph, not the full document.
- Toolbar and UI text gets read instead. Since the menus, buttons, and toolbar labels are real DOM elements, some extensions end up reading "File Edit View Insert Format Tools" instead of the document content.
This is not a theoretical concern. In classrooms where Google Workspace is the default platform, students with IEPs or 504 plans who need text-to-speech accommodations frequently cannot use those accommodations on the documents their teachers assign.
What Google Offers Built-In
Google has added some accessibility features to Docs over the years, but they have significant limitations for struggling readers.
Screen Reader Mode (Tools > Accessibility Settings): Enabling this option makes Docs inject more accessible text into the DOM and announce changes via ARIA live regions. It is designed for users of full screen readers like ChromeVox or JAWS. For students who just need TTS read-aloud, it adds unnecessary verbosity: reading out formatting changes, cursor positions, and collaboration notifications.
Select-to-Speak (Chrome OS built-in): Chrome OS has a system-level TTS feature where students can highlight text and hear it read. This works in Google Docs to a limited degree, but the text selection behavior on canvas-rendered content is inconsistent. Students must precisely select text first, which is difficult for younger students or those with motor challenges. There is also no word-level highlighting to help with tracking.
Google Read Along: This is a separate app designed for early readers and does not integrate with Docs at all.
None of these solutions provide the seamless experience that a struggling reader needs: open the document, press play, and follow along as each word highlights in sequence.
Why API-Based Text Extraction Works Better
The reliable way to get text out of a Google Doc is through the Google Docs API, not by scraping the page. The API returns the full document content as structured data, including paragraphs, headings, lists, tables, and formatting information.
When a TTS tool uses the API approach, the workflow looks like this:
- The student opens a Google Doc in their browser.
- The extension detects it is on a Google Docs page (based on the URL pattern
docs.google.com/document/d/). - Instead of trying to read the canvas, the extension calls the Google Docs API with the document ID extracted from the URL.
- The API returns the full document text with structural information.
- The extension renders this text in a readable panel and applies TTS with word highlighting.
This approach has several advantages. The text is complete and accurate. It includes paragraph structure so the TTS engine can insert appropriate pauses. And because the extension controls the text rendering, it can apply word-level highlighting that stays perfectly synchronized with the audio.
How ReadingVox Handles Google Docs
ReadingVox uses the Google Docs API integration approach described above. When a student opens a Google Doc, the extension does the following:
Step 1: Document Detection. The content script detects the docs.google.com/document URL pattern and activates Google Docs mode instead of standard page mode.
Step 2: API Text Extraction. Using the document ID from the URL, ReadingVox calls the Docs API to retrieve the document content. The student's Google account (already signed in on their Chromebook) provides the necessary read permissions.
Step 3: Reading Panel. The extracted text is displayed in a Reading Panel that slides in from the side of the screen. This panel contains real, styled HTML text, not canvas pixels. The text is formatted to match the document structure: headings, paragraphs, lists, and other elements are preserved.
Step 4: Synchronized TTS with Word Highlighting. When the student presses play, ReadingVox generates TTS audio with word-level timestamps using AWS Polly's speech marks feature. Each word in the Reading Panel highlights in real time as it is spoken, giving students a dual visual-auditory input that supports reading comprehension.
Step 5: Accessibility Tools. All of ReadingVox's other tools work in the Reading Panel: font switching (including OpenDyslexic), font size adjustment, page themes for contrast, the screen mask for line focus, and vocabulary simplification.
The Reading Panel approach also works for Google Slides, where the canvas rendering problem is even more pronounced since slides contain a mix of text, images, and shapes.
Practical Tips for Teachers Using Google Docs with Struggling Readers
Even if your school has not yet adopted a TTS tool with API integration, there are steps you can take to make Google Docs more accessible.
Use Google Docs Headings properly. When you structure documents with Heading 1, Heading 2, and Heading 3 styles instead of just bolding text, screen readers and TTS tools can navigate by section. This also helps students who need to re-read specific sections.
Keep formatting simple. Multi-column layouts, text boxes, and heavily formatted documents are harder for any accessibility tool to parse. Stick to single-column layouts with clear paragraph breaks.
Provide the same content in a secondary format. If your school's TTS extension does not support Google Docs, consider also sharing the content as a simple web page or PDF that the extension can read. This is not ideal since it creates extra work, but it ensures the accommodation is available.
Enable accessibility settings at the domain level. Google Workspace admins can enable accessibility features for all users in the Admin Console under Apps > Google Workspace > Settings for Docs. This ensures screen reader mode is available without students needing to find it in menus.
Test the student experience yourself. Open one of your assignments in a guest Chrome profile with the same TTS extension your students use. Try to read the document. If it does not work for you, it does not work for your students.
The Bigger Picture
Google Docs is the most-used writing and reading platform in K-12 education. The canvas rendering architecture, while delivering better performance and richer editing features, created a significant accessibility gap that has persisted for over a decade.
The good news is that API-based approaches provide a reliable workaround. If your school is evaluating TTS tools, make sure to ask specifically: "Does this tool work inside Google Docs?" Then test it yourself on a real document. Not a demo page, not the vendor's test site, but an actual Google Doc that your students would use.
The difference between a tool that works on web pages and a tool that works on web pages and Google Docs is the difference between an accommodation that covers half of a student's school day and one that covers all of it.