Google NotebookLM Accessibility and Usability Information

Date evaluated: 11/26/25

Overview

This document shares the findings of an accessibility evaluation performed by the Center for User Experience. We evaluate digital content using the Web Content Accessibility Guidelines (WCAG) version 2.1, Levels A and AA as our technical standard using both manual and automated testing methods. Our manual testing methods include checking for keyboard and screen reader support, reflow at high levels of magnification, accessible video and audio content, and sufficient color contrast. We may also identify usability barriers that would impact all users.

Contact the Center for User Experience (centerforux@wisc.edu) with any questions.

Test conditions

Device: Dell Latitude

Operating system: Windows 11

Browser: Chrome

Screen reader: NVDA

Tasks reviewed

• Welcome page

• Create new notebook

• Add/Manage sources

• Chat

This evaluation is not comprehensive and should not be used as a replacement for internal quality assurance of a product. We find patterns of accessibility barriers and show examples of the types of barriers we find.

Accessibility and usability barriers

Welcome page

Summary

The Welcome page includes some screen magnification and visual focus barriers that make the content less perceivable to low vision users. 

Interface does not support magnification up to 400%

Elements on the Welcome page start to clash when the page is magnified at and above 250%.

250%

400%

Expected behavior: Content should reflow at higher levels of magnification (up to 400%) to avoid clipping and clashing. 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

  • Content must reflow as it is magnified or the screen orientation changes. (1.4.10)

Subtle and inconsistent visual indication of focus

The focus indicators on buttons on the Welcome page often have confusing or low contrast focus states. 

Base state:

Focus on Create new notebook:

Focus on Try an example notebook:

Focus also on Try an example notebook:

Expected behavior: Visual indication of focus should be obvious, and ideally consistent, throughout the interface. 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

  • Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (2.4.7)

Create new notebook

Summary

The workflow to create a new notebook contains some buttons with low contrast text. Additionally, the process lacks screen reader announcements of changes in focus that could make it difficult for screen reader users to successfully create a new notebook, and lacks good instructions for the requirements to create a notebook that may make it confusing for all users.

Low contrast buttons

Expected behavior: The changes in context should be consistently announced via screen reader. Additionally, more explicit instructions for the requirements to start a new notebook should be provided to all users.

This barrier primarily relates to the following accessibility guidelines:

• Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

  • Text must have a contrast ratio of 4.5:1 with the background color. (1.4.3)

Unclear workflow to create new notebook, particularly via screen reader 

When the user selects the Create new notebook option from the NotebookLM home page, the new notebook loads with a popup to add sources. Screen reader focus loads on the close button of the Add sources dialog, and the only announcement of the user’s change in context from the home page is the “close dialog” button announcement. It isn’t clear whether they are still on the home page or in the new notebook.

It isn’t explicitly stated to an end user that they cannot create a notebook without adding sources unless they close the popup and see that the chat function is unavailable until a source is uploaded:

The path forward for a screen reader user is unclear if they do not add any sources immediately or understand that is a required step. Selecting the “close dialog” button places the user’s focus on the Google Apps button within the new notebook’s navigation bar, and the inactive chat window is very far down the reading order. 

If the user selects “Discover sources,” the popup closes without alerting the user and places screen reader focus in the Search bar within the new notebook, again without announcing the change in context to the user, so it is still unclear if they’re in the new notebook: 

Expected behavior: Changes in context should be consistently announced via screen reader. Additionally, more explicit instructions for the requirements to start a new notebook should be provided to all users.

This barrier primarily relates to the following accessibility guidelines:

• Understandable - Information and the operation of the user interface must be understandable.

  • Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action. (3.2.2)

• Operable - User interface components and navigation must be operable.Operable - User interface components and navigation must be operable.

  • Descriptive labels help users identify specific components within the content (2.4.6)

Add/manage sources

Summary

The lack of status updates via screen reader makes it unclear what sources have been added, removed, or unselected from the notebook’s responses. The interface also lacks good landmarks for quickly navigating via screen reader. Additionally, the sources section lacks a good explanation of adding and removing sources from the answers that the LLM provides, which may be confusing for all users.

Lack of status updates when uploading and deleting sources

When a user adds or deletes sources in their notebook, there is no confirmation via screen reader that their sources are loading, or have been successfully added or deleted. Additionally, the Chat feature adds a summary of the first sources uploaded, and the user is not alerted of that content loading. 

Expected behavior: Both the loading process and successful addition or removal of sources should be announced via screen reader. 

This barrier primarily relates to the following accessibility guidelines:

• Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

  • Status messages should be coded so assistive technologies can recognize and announce them without moving the user’s focus. (4.1.3)

Purpose of selecting sources is unclear

Users have the option to check and uncheck sources from the Sources pane, but the effect of selecting and deselecting sources is unclear. The only immediate feedback given to a user is that the source count in the Chat pane changes:

Although the screen reader announces selecting and deselecting the checkboxes, it is not clearly announced via screen reader that this is impacting the sources for the LLM’s responses. Since there aren’t strong instructions for use or obvious status updates visually or via screen reader, it might be unclear to many users whether they’re selecting sources to activate, upload, or delete from the notebook.

Expected behavior: There should be some context, either within the label or the surrounding text, for what the impact is of selecting or deselecting sources. 

This barrier primarily relates to the following accessibility guidelines:

• Understandable - Information and the operation of the user interface must be understandable.

  • Provide labels or instructions for inputs. (3.3.2)

Lack of meaningful content landmarks 

Aside from the headings within the generated chat content, there aren’t any headings, skip mechanisms, or content landmarks that allow for quick navigation throughout the interface.

Expected behavior: The platform should include landmarks for users to quickly navigate to different sections of the interface, especially when the interface is so complex. 

This barrier primarily relates to the following accessibility guidelines:

• Operable - User interface components and navigation must be operable.

  • Descriptive labels help users identify specific components within the content (2.4.6)

Chat

Summary 

The Chat feature operates as expected via keyboard and screen reader, as well as with the browser set to high levels of magnification.