Google Forms accessibility and screen readers

Last updated September 2026 · ~11 minute read

Short answer: Google documents screen reader support for the person building a form — recommended screen readers, how to get out of browse mode, and keyboard shortcuts including Alt + s (Command + Option + s on a Mac) for the More menu. It documents almost nothing for the person filling the form in. And there is no way to give an image in a form a text alternative — a gap Google states outright in its own conformance report. Most of what makes a form usable non-visually is therefore down to how you write the questions.

Accessibility advice that is wrong hurts the people it claims to help, so this page keeps two things apart: what Google actually documents, quoted and linked, and what we recommend on our own authority. Where we are reasoning rather than citing, we say so in the heading.

How we checked

We read Google's own material rather than summarising other people's summaries: the Docs Editors Help page Use Google Forms with a screen reader, the Google Forms keyboard shortcuts page, the Google Workspace user guide to accessibility, and Google's published Accessibility Conformance Report for Google Forms Web. Every factual claim below is attributed to one of those, or labelled as ours.

What Google documents: screen readers

Which screen readers Google names

Google's screen reader page recommends Chrome together with:

• NVDA or JAWS on Windows
• ChromeVox on ChromeOS
• VoiceOver on macOS

No other combination is named. That is a recommendation, not a statement that others fail. What that page does document — and the handful of things it is the only Google page to describe — is the subject of our guide to Google Forms screen reader support.

Turning browse mode off

The step people miss is that Forms expects your screen reader to be out of its document-reading mode, so that keystrokes reach the page instead of the screen reader. Google gives the toggle for each one: JAWS, JAWS + z until you hear “Off”; NVDA, NVDA + Spacebar; ChromeVox, the Search key pressed twice; VoiceOver, the Left and Right arrow keys together.

The More menu

The More menu is the one part of the editor that is genuinely hard to find by keyboard, which is presumably why Google documents it specially. Press Alt + s (Command + Option + s on a Mac) to reach the More menu button, then Down arrow to open it. The menu lists Make a copy, Move to trash, Pre-fill form, Embed HTML, Print and Unpublish form.

Shortcuts worth learning

From Google's keyboard shortcuts page. On a Mac, substitute ⌘ for Ctrl (and Option + Shift + d for deleting an item):

• Ctrl + / — show the list of keyboard shortcuts
• Ctrl + Shift + Enter — insert a question
• Hold Ctrl, press i then h — insert a title and description
• Hold Ctrl, press i then b — insert a section
• Hold Ctrl, press i then p — insert an image
• Ctrl + k / Ctrl + j — move the cursor up / down
• Ctrl + Shift + k / Ctrl + Shift + j — move an item up / down
• Ctrl + Shift + d — duplicate an item; Alt + Shift + d — delete it
• Ctrl + Shift + p — preview; Ctrl + e — settings and the Responses tab; Ctrl + Enter — the Send menu
• Tab / Shift + Tab — next and previous field

If you are reading individual responses, Google notes you “might need to change your screen reader to ‘Forms mode’ or ‘Focus mode’”.

The alt text gap

This is the single most consequential thing on this page. Google Forms has no documented control for giving an image a text alternative. Not on the image, not in the editor, not anywhere in the screen reader documentation — the word “alt text” does not appear on the screen reader page at all.

We are not inferring this from an absence. Google states it, in Google's own conformance report, under WCAG 1.1.1 Non-text Content, where the product is rated Partially Supports:

“Google Forms Web provides a text alternative to non-text content in some places. Exceptions include: Form authors can not define alt text for uploaded images.”

The practical consequence is simple and it is entirely on the author. If a picture in your form carries information, that information has to be repeated in the question text or the question description. A photograph of four sofa fabrics with the options labelled “A, B, C, D” is unanswerable without sight; the same question with “A — charcoal wool, B — cream linen, C — tan leather, D — navy velvet” in the description is answerable by anybody. Treat the image as decoration that some people get a bonus from, and put the meaning in the words.

What Google's conformance report says

Google does publish a VPAT for Forms: a Google Accessibility Conformance Report, International Edition, based on VPAT version 2.5, for the product Google Forms Web, dated 7 October 2024. It covers WCAG 2.0, 2.1 and 2.2 at Levels A, AA and AAA, plus Revised Section 508 and EN 301 549, and it names the test rig: Windows 11, macOS 14.7, ChromeOS, with JAWS 2024, NVDA 2024.3 beta, VoiceOver on macOS 14.7 and ChromeVox.

We are not going to summarise 44 pages into a grade, and we will not assert a conformance level for Google Forms on our own authority — if you need one for a procurement form, read Google's report and cite Google. What is fair to report is that a number of criteria are marked Partially Supports, which in Google's own definition means “Some functionality of the product does not meet the criterion”. Two of those remarks are worth knowing before you write a form:

• 1.3.1 Info and Relationships — “Question titles lack proper heading tags (<h1> to <h6>) or ARIA attributes to identify them as headings” and “Some form fields lack proper labels using the <label> tag, which associates descriptive text with the corresponding input field.”
• 1.3.2 Meaningful Sequence — “Reading order can get confusing with CSS disabled, particularly for multiple choice and complex questions, making the form hard to follow.”

Worth flagging honestly: Google's help page says that “When a Form is published, to make navigation easy, each title, question, and section displays as a heading” — and the same sentence continues, “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.” So heading navigation is documented as a property of the published form, not the editor. Even read in full, the October 2024 conformance report still records question titles lacking heading semantics. We cannot reconcile those two Google statements for you. If heading navigation matters to your respondents, test the published form with a screen reader rather than trusting either sentence.

Our recommendations for form authors

This section is ours, not Google's. Nothing below is quoted from Google documentation. It is what follows, in our judgement, from the documented behaviour above and from ordinary form-design practice. Treat it as advice, not as a compliance checklist.

Put the meaning in the question text

Anything carried only by colour, position or an image is carried by nothing at all for some respondents. “Choose the green option”, “pick the one on the left”, “select the logo shown above” — each of these needs a word-based equivalent in the question or its description. This is the same rule as the alt text gap above, generalised: the question text is the one channel every respondent has.

Required fields and error text

Forms marks required questions and refuses to submit until they are answered, and what that refusal looks like differs by question type. Someone moving through the form linearly with a screen reader meets that refusal as a message somewhere in a long page, potentially after a scroll, and has to work out which question caused it. You can make that much cheaper: keep required questions few and obvious, give each one a title that is unique enough to be recognised out of context (“Email address” beats “Contact”), and if a question has a format requirement, say the format in the description rather than leaving the respondent to discover it from a rejection. Do not rely on a parenthetical asterisk convention that you explained once at the top of the form.

Split large grids

Multiple-choice grids and checkbox grids are the hardest control on a form to operate without sight: they ask somebody to hold a row label and a column label in mind simultaneously while navigating in two dimensions, and the row label is usually announced far from the option they are choosing. A grid is almost always a convenience for the author — it makes a long survey look short. If the grid is more than a handful of rows, we would split it into individual multiple-choice questions, each with its full row wording in the title. The form gets longer and considerably easier to answer.

Use sections and descriptions as navigation

A long form is a long page. Sections break it into stages with their own titles, which gives a respondent somewhere to be and a sense of progress, and section descriptions are a good place for the context you would otherwise put in an image or assume from layout. Write section titles that would make sense read aloud on their own.

Write link text that survives being read alone

Screen reader users frequently pull up a list of the links on a page, stripped of surrounding sentences. “Click here”, “this”, and a bare URL are all useless in that list. “Read the refund policy” is not.

The respondent side is barely documented

This is a genuine finding rather than a complaint. Google's accessibility documentation for Forms is almost entirely about the author: the screen reader page is organised around getting started, navigating the editor UI, completing common tasks and reviewing results, and Google's own Workspace accessibility guide reduces Forms to one sentence — “You can create, edit, and navigate forms with a screen reader and keyboard shortcuts.” We could not find a Google page that teaches a respondent how to fill in a published form with a screen reader, or that tells an author what their respondents will encounter.

That asymmetry matters because the population is lopsided the other way: a form has one author and possibly thousands of respondents. Practically, it means two things. If you are an author, you cannot delegate the respondent experience to Google's documentation, because it does not exist — the recommendations above are the substitute. And you should open your own published form, turn on VoiceOver or NVDA, and try to complete it; ten minutes of that is worth more than any checklist, this one included.

Documented by Google, or down to you?

Forms+ on iPhone: VoiceOver and Dynamic Type

Forms+ is a native iOS client for your real Google Forms, so the accessibility question for it is an iOS one: VoiceOver and Dynamic Type, not WCAG. The app is built with UIKit and ships native accessibility labels on its controls, and its text uses the system's Dynamic Type sizing so that it follows the text size you have set in iOS Settings.

We will not go further than that. A count of accessibility labels in a codebase is not a conformance claim, and we make no WCAG or VPAT claim for the app. Two things to note either way: this is about the editor — your respondents still fill in the form on Google's web page, so the recommendations above are what governs their experience. And the fastest way to know whether an app suits you is to turn on VoiceOver and try it, which costs nothing since the app is free to download.

Frequently asked questions

Is Google Forms accessible to screen reader users?

Google documents screen reader support for building and editing forms, and publishes an Accessibility Conformance Report for Google Forms Web dated 7 October 2024 that rates the product criterion by criterion. That report marks several criteria Partially Supports rather than Supports, so the honest answer is that it depends on the criterion and on how the individual form is written. We do not make a blanket conformance claim on Google's behalf; read Google's own report.

Can you add alt text to an image in Google Forms?

No. There is no documented control for giving an image in a Google Form a text alternative, and Google's own Accessibility Conformance Report states the limitation directly under WCAG 1.1.1 Non-text Content: form authors can not define alt text for uploaded images. The practical consequence is that any information carried only by a picture must be repeated in the question text or the question description.

What keyboard shortcut opens the More menu in Google Forms?

Google documents Alt + s, or Command + Option + s on a Mac, to reach the More menu button, then the Down arrow to open it. The menu it opens lists Make a copy, Move to trash, Pre-fill form, Embed HTML, Print and Unpublish form.

Does Google publish a VPAT for Google Forms?

Yes. Google publishes a Google Accessibility Conformance Report, International Edition, based on VPAT version 2.5, for the product Google Forms Web, dated 7 October 2024. It covers WCAG 2.0, 2.1 and 2.2 at Levels A, AA and AAA, plus Revised Section 508 and EN 301 549, and records the exact browsers and assistive technologies used in testing, including JAWS 2024, NVDA 2024.3 beta, VoiceOver on macOS and ChromeVox.

Are grid questions in Google Forms hard to use with a screen reader?

This is our recommendation rather than Google guidance: a multiple-choice grid asks somebody to hold a row label and a column label in their head at the same time while moving through a two-dimensional control, which is the hardest thing on a form to do without sight. Where a grid is a convenience for the author rather than a requirement, splitting it into separate questions with self-contained wording is usually kinder to respondents.