Google Forms screen reader support: what Google documents, and what it leaves out

Last updated September 2026 · ~10 minute read

Short answer: Google publishes one screen reader article for Forms, and it is written entirely for the person building the form — Google also lists it as Edit forms with a screen reader. It covers the recommended screen readers, switching browsing mode off, the order of the controls across the top of the editor, and shortcuts that nearly all share one precondition. It documents nothing about filling in a published form, and unlike Docs, Sheets and Slides, Forms has no Turn on screen reader support setting at all.

This is a survey of the documentation rather than advice: everything below is either quoted from a Google page and linked, or flagged as an absence we looked for and did not find. For our own recommendations to authors, see Google Forms accessibility and screen readers.

Where the documentation actually is

There is one article, published at two addresses: in Docs Editors Help and in Accessibility Help. Its heading reads Use Google Forms with a screen reader, but Google also lists it as Edit forms with a screen reader, and that verb is the most accurate word about its scope. Beyond that: the keyboard shortcuts page, one sentence in the Workspace user guide to accessibility (“You can create, edit, and navigate forms with a screen reader and keyboard shortcuts”), and Google's Accessibility Conformance Report for Google Forms Web. That is the whole corpus.

What Google documents for the author

There is no “Turn on screen reader support” setting

Google's Use Google Docs Editors with a screen reader documents an in-product switch (Tools → Accessibility settings → Turn on screen reader support, or Ctrl + Alt + z, Command + Option + z on a Mac) and names Docs, Sheets, Slides, Vids and Pics. Forms is not on that page, and the Forms article has no equivalent step. If you have been hunting the Forms menus for that checkbox, it is not hiding; it does not exist.

Browsing mode has to go off, and Google names the toggle

Forms expects to be driven “as a web application” rather than read as a web page, so your screen reader's document-reading layer has to be out of the way. Google gives each toggle with the phrase you should hear:

• JAWS, “virtual cursor”: JAWS + z until you hear “Off.”
• NVDA, “browse mode”: NVDA + Spacebar until you hear a click.
• ChromeVox, “sticky mode”: Search twice quickly, until “Sticky mode disabled.”
• VoiceOver, “quick nav”: Left and Right arrows together, until “Quicknav off.”

Google adds a caveat worth keeping: “Sometimes, you should use Forms as a web page and use screen reader browser commands.” It is not a setting you flip once per session. Google names two such places: on the Individual responses tab, “you might need to change your screen reader to ‘Forms mode’ or ‘Focus mode,’” and to browse the shortcut list you “Toggle your screen reader to Virtual/Browse/Sticky/QuickNav mode,” read the table, then toggle back.

The documented order of the controls at the top

The most useful part of the page, and the part most summaries drop, is Google's written-out order for the controls above every form: Forms Home, the title edit field, Move to folder, the Star check box, Help me create a form, Customize Theme, Preview, Undo, Redo, Copy responder link, Share, Publish, the More menu button, the Google Account button, then the Questions, Responses and Settings tabs. Knowing that Share sits two stops before More is what makes Google's own instruction — Alt + s for More, then Shift + Tab twice — comprehensible rather than arbitrary.

Nearly every shortcut has the same precondition

One instruction repeats before almost every entry in Google's shortcut list: “Tab to a non-edit field.” It precedes the More menu, the Settings tab, reordering questions, inserting and duplicating items, the theme panel, preview, publish and the shortcut list itself. The reason is structural: “Each item in the form starts with an edit field with the text of the title, question, or section,” so a keystroke fired while focus sits in one is text input, not a command. If Forms shortcuts seem dead, check that first.

Headings exist — but only in the published form

Google's sentence here is usually quoted with its second half removed. In full: “When a Form is published, to make navigation easy, each title, question, and section displays as a heading. However, when you edit each of these, these become edit fields instead of headings. So, use your screen reader commands to navigate by edit fields.”

Two consequences. Heading navigation is documented as a property of the published form, not the editor, so an author moving by headings while building finds nothing to move between. And because sections are one of the three things named, section structure is documented navigation rather than decoration — a reason to use section headers that has nothing to do with how the form looks. Google also warns that edit fields which are not titles, sections or questions carry generic names such as “Option value.”

The theme panel, and the stop that is not in it

Google documents opening the theme panel with Alt + t — the Mac variant given here is Ctrl + Option + t, not the Command-based pattern used elsewhere on the page — and lists what Tab moves through: fonts for headers, questions and text; Header image; theme colour and background. Read that as a closed list. There is no stop for a text alternative on the header image you pick there, nor for images inside questions, and Google does not document how a custom theme's colours interact with the form's own text.

What the shortcuts page does not do

Google's keyboard shortcuts for Google Forms lists shortcuts by platform under headings such as navigation, file commands, menus, form actions, editing and grading. We checked it for two things and found neither: it never mentions screen readers, and it does not separate editor shortcuts from shortcuts for someone filling in a form — every entry is an authoring command. Our keyboard shortcuts guide covers the list itself. One discrepancy: it calls Ctrl + Enter the Send menu, while the screen reader page calls that keystroke “Publish the form.”

The responder side is not documented

We looked for a Google page teaching somebody to complete a published form with a screen reader, and did not find one. The article's contents are all authoring tasks — quick start, recommended browser, setting up your screen reader, opening a form, the UI, adding and editing items, the More menu, settings, publishing, reviewing results, creating a quiz. Its “Related resources” are the Sheets and Drive screen reader guides plus Publish & share your form with responders, which is not an accessibility page.

This is an absence, not a verdict: a published form is ordinary HTML and people complete them with screen readers every day. What is missing is Google telling an author what their respondents meet — so wording, structure and whether a picture carries meaning are covered by no Google guidance.

What Google's own conformance report concedes

Google publishes an Accessibility Conformance Report (International Edition, VPAT 2.5) for Google Forms Web, dated 7 October 2024 and tested with JAWS 2024, NVDA 2024.3 beta, VoiceOver and ChromeVox. Five entries bear on screen reader use:

• 1.1.1 Non-text Content — Partially Supports. The stated exception: “Form authors can not define alt text for uploaded images.” If a picture in your form carries information, the only place that information can live is the question text or its description.
• 1.3.1 Info and Relationships — Partially Supports: “Question titles lack proper heading tags (<h1> to <h6>) or ARIA attributes to identify them as headings,” and “Some form fields lack proper labels.” Read that next to the help page's heading sentence above; we cannot reconcile the two.
• 2.4.1 Bypass Blocks — Does Not Support: “The current version of Google Forms Web does not offer a specific bypass blocks feature.”
• 1.3.5 Identify Input Purpose — Does Not Support: Forms “does not mark up native input fields or fields created by form authors with the required information to programmatically identify their purpose.”
• 2.4.3 Focus Order — Partially Supports: “The dropdown menu for each question when editing is not in the focus order, requiring keyboard users to navigate back to the form's beginning to access it.”

We make no conformance claim. Nothing here says that Google Forms, or a form you build with it, meets WCAG, Section 508, EN 301 549 or the European Accessibility Act. Those are Google's self-reported ratings about its own product, and whether any obligation applies to you depends on your jurisdiction, your sector and who your respondents are. If you need a position, read Google's report and take advice for your own context.

What is left to the author

Where Google is silent, the wording is the whole remedy. Grids are the hardest control to operate without sight, because a row label and a column label must be held in mind at once — read up on multiple choice grids and checkbox grids before committing to one. Instructions belong in a question description — but Google does not document whether a description is announced with its question, so put nothing there the question would fail without. And anything an image conveys must be repeated in words, because the conformance report says you cannot attach a text alternative to it.

Forms+ on iPhone

Forms+ is a native iOS editor and response client for your real Google Forms, so its own accessibility question is an iOS one. Its controls carry native accessibility labels, traits, values and hints, it posts VoiceOver notifications when the screen or layout changes, and its text uses Dynamic Type. That describes how the app is built; it is not a conformance claim, and it applies to the app you edit in — your respondents still fill in the form on Google's web page. The honest test is to turn VoiceOver on and try it.

Frequently asked questions

Does Google Forms have a Turn on screen reader support setting?

No. Google documents that setting for Docs, Sheets, Slides, Vids and Pics — Tools → Accessibility settings → Turn on screen reader support, or Ctrl + Alt + z — on its Docs Editors screen reader page, and Forms is not named there. The Forms article has no equivalent step. It documents turning your screen reader's own browsing mode off instead, so keystrokes reach Forms.

Are Google Forms questions headings for a screen reader?

Google's help page says that when a form is published, each title, question and section displays as a heading, but that while you edit them they become edit fields instead, so you navigate the editor by edit field rather than by heading. Separately, Google's conformance report records under 1.3.1 that question titles lack proper heading tags or ARIA attributes. We report both and reconcile neither; if heading navigation matters to your respondents, test your published form.

Does Google document how to fill in a Google Form with a screen reader?

We could not find a Google page that does. The article is organised entirely around authoring tasks, and Google also lists it as Edit forms with a screen reader. Its related resources point to Sheets, Drive and a page about sharing a form with responders, none of which is a guide to completing one. The Workspace accessibility guide reduces Forms to one sentence about creating, editing and navigating.

Why do the Google Forms keyboard shortcuts do nothing when I press them?

Most likely because focus is in an edit field. Google states that every item in a form starts with an edit field holding the text of the title, question or section, and prefixes almost every shortcut with the instruction to tab to a non-edit field first. A keystroke sent while focus sits in one of those is treated as typing rather than as a command.

What does the Google Forms VPAT say that matters for screen reader users?

Google's report for Google Forms Web, dated 7 October 2024, marks 1.1.1 Non-text Content as Partially Supports with the exception that form authors cannot define alt text for uploaded images, marks 2.4.1 Bypass Blocks and 1.3.5 Identify Input Purpose as Does Not Support, and notes under 2.4.3 Focus Order that the per-question dropdown is not in the focus order while editing. Those are Google's self-assessed ratings; we do not translate them into a compliance verdict.