github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

issue: ​Accessibility: Toggles for Web Search and Tools Do Not Announce State to Screen Readers #6301

New Issue
Open
opened 2025-11-11 16:50:30 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2025-11-11 16:50:30 -06:00
Owner
Copy Link

Originally created by @a328929 on GitHub (Sep 2, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

0.6.22

Ollama Version (if applicable)

No response

Operating System

Ubuntu-24.04.1

Browser (if applicable)

Chrome:139.0.7258.158 Android

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

As a screen reader user, I expect all toggle switches to clearly announce their name and current state (e.g., "on" or "off") both upon focusing on them and after they are activated.

Specifically:

  1. For the Web Search Toggle:

    • When my screen reader focus lands on the web search button next to the "+" icon, it should announce its purpose and current state, for example: "Web Search, switch, off."
    • After I tap the button to activate it, the screen reader should immediately announce the new state, for example: "Web Search, switch, on."

  2. For the Tools Toggles:

    • Similarly, inside the "Tools" selection menu, when I navigate to any tool (e.g., "Enhanced Web Search", "run code"), the screen reader should announce the tool's name and the state of its switch, for example: "Enhanced Web Search, switch, on."
    • Tapping the switch should also result in an audible announcement of its new state (e.g., "off").

This behavior is crucial for blind and visually impaired users to understand and control the feature's status aurally, without needing to rely on visual confirmation or external AI recognition tools.

Actual Behavior

As a screen reader user, the actual behavior of the toggle switches in the UI is not accessible. The screen reader fails to announce their state, making it impossible to know if a feature is enabled or disabled without visual confirmation.

Here are the specific issues:

  1. For the Web Search Toggle:

    • When my screen reader's focus is on the web search button, it only announces "button." It does not provide the current state (e.g., "on" or "off").
    • After I tap the button, the screen reader gives no audible feedback or announcement, so I do not know if the action was successful or what the new state is.

  2. For the Tools Toggles:

    • In the "Tools" selection menu, when I navigate to any tool, the screen reader only reads the name of the tool (e.g., "Enhanced Web Search"). It does not announce the state of the toggle switch next to it.
    • Tapping on the tool name or switch provides no auditory confirmation of the state change.

Because of this, I am forced to take screenshots and use an AI recognition tool to visually check whether a toggle is on or off. This makes the interface very difficult and inefficient to use for blind and visually impaired users.

Steps to Reproduce

Prerequisites:

  • Device: A mobile phone (e.g., Android with TalkBack or iOS with VoiceOver).
  • Software: A web browser with Open WebUI (v0.6.22 or latest).
  • Crucial: The screen reader must be active throughout the test.

Test Case 1: Reproducing the Web Search Toggle Issue

  1. Open the Open WebUI chat interface on the mobile browser.
  2. With the screen reader on, use swipe gestures to navigate to the web search toggle button (the magnifying glass icon located to the left of the "+" button).
  3. Observe: Listen to the screen reader's announcement. It only announces "button," without mentioning its current state (on or off).
  4. Tap the button to change its state.
  5. Observe: Listen again. The screen reader provides no feedback or announcement about the new state.

Test Case 2: Reproducing the Tools Toggle Issue

  1. On the main chat screen, locate and activate the "+" button using the screen reader.
  2. A menu with a list of tools will appear.
  3. Use swipe gestures to navigate through the list of tools (e.g., "Enhanced Web Search," "run code").
  4. Observe: For each tool, listen to the screen reader's announcement. It only reads the name of the tool and does not announce the state of the toggle switch next to it.
  5. Tap on any tool to change its state.
  6. Observe: The screen reader gives no audible confirmation of the new state (e.g., "on" or "off").

Logs & Screenshots

Image
Image
Image
Image

Additional Information

This is a critical accessibility issue that prevents blind and visually impaired users from independently using core features of the application, such as web search and tools.

  • Impact: The current implementation is a blocker for screen reader users. Without audible state announcements, we cannot confidently operate these features.

  • Environment: The issue was observed on a mobile device (Android with TalkBack), but it is likely a general web accessibility problem that affects all screen reader software (including iOS VoiceOver, NVDA, etc.) because it seems to be related to non-standard HTML implementation.

  • Technical Suggestion: A potential solution is to implement proper ARIA (Accessible Rich Internet Applications) attributes for these custom toggle buttons. Specifically, using role="switch" and dynamically updating the aria-checked attribute (e.g., aria-checked="true" or aria-checked="false") would allow screen readers to correctly identify the components and announce their states.

Originally created by @a328929 on GitHub (Sep 2, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version 0.6.22 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu-24.04.1 ### Browser (if applicable) Chrome:139.0.7258.158 Android ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior As a screen reader user, I expect all toggle switches to clearly announce their name and current state (e.g., "on" or "off") both upon focusing on them and after they are activated. Specifically: 1. For the Web Search Toggle: * When my screen reader focus lands on the web search button next to the "+" icon, it should announce its purpose and current state, for example: "Web Search, switch, off." * After I tap the button to activate it, the screen reader should immediately announce the new state, for example: "Web Search, switch, on." 2. For the Tools Toggles: * Similarly, inside the "Tools" selection menu, when I navigate to any tool (e.g., "Enhanced Web Search", "run code"), the screen reader should announce the tool's name and the state of its switch, for example: "Enhanced Web Search, switch, on." * Tapping the switch should also result in an audible announcement of its new state (e.g., "off"). This behavior is crucial for blind and visually impaired users to understand and control the feature's status aurally, without needing to rely on visual confirmation or external AI recognition tools. ### Actual Behavior As a screen reader user, the actual behavior of the toggle switches in the UI is not accessible. The screen reader fails to announce their state, making it impossible to know if a feature is enabled or disabled without visual confirmation. Here are the specific issues: 1. For the Web Search Toggle: * When my screen reader's focus is on the web search button, it only announces "button." It does not provide the current state (e.g., "on" or "off"). * After I tap the button, the screen reader gives no audible feedback or announcement, so I do not know if the action was successful or what the new state is. 2. For the Tools Toggles: * In the "Tools" selection menu, when I navigate to any tool, the screen reader only reads the name of the tool (e.g., "Enhanced Web Search"). It does not announce the state of the toggle switch next to it. * Tapping on the tool name or switch provides no auditory confirmation of the state change. Because of this, I am forced to take screenshots and use an AI recognition tool to visually check whether a toggle is on or off. This makes the interface very difficult and inefficient to use for blind and visually impaired users. ### Steps to Reproduce Prerequisites: * Device: A mobile phone (e.g., Android with TalkBack or iOS with VoiceOver). * Software: A web browser with Open WebUI (v0.6.22 or latest). * Crucial: The screen reader must be active throughout the test. --- Test Case 1: Reproducing the Web Search Toggle Issue 1. Open the Open WebUI chat interface on the mobile browser. 2. With the screen reader on, use swipe gestures to navigate to the web search toggle button (the magnifying glass icon located to the left of the "+" button). 3. Observe: Listen to the screen reader's announcement. It only announces "button," without mentioning its current state (on or off). 4. Tap the button to change its state. 5. Observe: Listen again. The screen reader provides no feedback or announcement about the new state. --- Test Case 2: Reproducing the Tools Toggle Issue 1. On the main chat screen, locate and activate the "+" button using the screen reader. 2. A menu with a list of tools will appear. 3. Use swipe gestures to navigate through the list of tools (e.g., "Enhanced Web Search," "run code"). 4. Observe: For each tool, listen to the screen reader's announcement. It only reads the name of the tool and does not announce the state of the toggle switch next to it. 5. Tap on any tool to change its state. 6. Observe: The screen reader gives no audible confirmation of the new state (e.g., "on" or "off"). ### Logs & Screenshots ![Image](https://github.com/user-attachments/assets/e1c12884-b452-4c5c-b578-5e13382923ce) ![Image](https://github.com/user-attachments/assets/f9b37ecf-2792-4eee-be83-229b75701ed4) ![Image](https://github.com/user-attachments/assets/3b41bfc8-360b-4dde-b298-37f48a8e125b) ![Image](https://github.com/user-attachments/assets/6b43aee3-4f03-494d-8f53-7853257a76eb) ### Additional Information This is a critical accessibility issue that prevents blind and visually impaired users from independently using core features of the application, such as web search and tools. - Impact: The current implementation is a blocker for screen reader users. Without audible state announcements, we cannot confidently operate these features. - Environment: The issue was observed on a mobile device (Android with TalkBack), but it is likely a general web accessibility problem that affects all screen reader software (including iOS VoiceOver, NVDA, etc.) because it seems to be related to non-standard HTML implementation. - Technical Suggestion: A potential solution is to implement proper ARIA (Accessible Rich Internet Applications) attributes for these custom toggle buttons. Specifically, using `role="switch"` and dynamically updating the `aria-checked` attribute (e.g., `aria-checked="true"` or `aria-checked="false"`) would allow screen readers to correctly identify the components and announce their states.
GiteaMirror added the bug label 2025-11-11 16:50:30 -06:00
GiteaMirror commented 2025-11-11 16:50:31 -06:00
Author
Owner
Copy Link

@Flopblopper commented on GitHub (Oct 20, 2025):

Would like to add that I've also noticed a few unlabeled elements in addition to those listed:

  • Account Settings (API Keys):

    • The action buttons for an existing API key in the user account settings are unlabeled.

  • Archived Chats:

    • The "Close," "Delete," and "Restore" buttons within the archived chats list are unlabeled.
    • The "Yes" and "No" buttons in the "Archive All Chats" confirmation dialog are unlabeled.
    • The "Yes" and "No" buttons in the "Delete All Chats" confirmation dialog are unlabeled.

  • Model Creation Screen:

    • All buttons in the "Capabilities" section are unlabeled.
    • All buttons in the "All Features" section are unlabeled.

  • Chat Screen:

    • The "Send" button is unlabeled.
@Flopblopper commented on GitHub (Oct 20, 2025): Would like to add that I've also noticed a few unlabeled elements in addition to those listed: * **Account Settings (API Keys):** * The action buttons for an existing API key in the user account settings are unlabeled. * **Archived Chats:** * The "Close," "Delete," and "Restore" buttons within the archived chats list are unlabeled. * The "Yes" and "No" buttons in the "Archive All Chats" confirmation dialog are unlabeled. * The "Yes" and "No" buttons in the "Delete All Chats" confirmation dialog are unlabeled. * **Model Creation Screen:** * All buttons in the "Capabilities" section are unlabeled. * All buttons in the "All Features" section are unlabeled. * **Chat Screen:** * The "Send" button is unlabeled.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#6301
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?