This PR fixes an accessibility issue where a password input field was associated with multiple labels, violating WCAG (1.3.1).
The issue was identified using IBM Accessibility Checker and resolved using A11YRepair by removing a redundant screen-reader-only label rendered by SensitiveInput.svelte when an external visible label is already present.
This is a small, non-breaking accessibility bug fix.
Issue Details
Reproduce Steps
This accessibility issue was identified while starting the Open WebUI frontend development server using:
npm run dev
On the login page, an accessibility checker reported a form_label_unique violation, indicating that a form control is associated with more than one <label> element.
Specifically, the password input field was linked to both a visible label and an additional screen-reader-only (sr-only) label, resulting in multiple labels referencing the same form control.
Accessibility Impact
Having multiple labels associated with a single input can negatively impact users of assistive technologies:
Screen readers may announce the field label multiple times, causing confusion and reducing form usability.
Users relying on non-visual navigation may receive redundant or conflicting context when interacting with the input.
Resolving this issue ensures that the password field has a single, clear accessible name, improving the login experience for screen reader users without changing any visual behavior.
Soluation Details
The A11Y Bug Report indicates a form_label_unique violation, stating "Form control has more than one label" for the password input field. The snippet provided in the report, <label for=\"password\" class=\"sr-only\">, points to a screen-reader-only label as one of the culprits.
Bug Scenario and Root Cause:
The webpage screenshot and the DOM inspection reveal that the password input field has two associated labels:
A screen-reader-only label: <label class=\"sr-only\" for=\"password\">Enter Your Password</label>
The root cause is that the SensitiveInput.svelte component, which is used for the password input, unconditionally renders an sr-only label. When this component is used in a context where a separate, visible label is already provided (as seen in the screenshot), it results in two labels being associated with the same input field. This redundancy confuses assistive technologies and violates WCAG 1.3.1 (Info and Relationships).
Proposed Fix:
Since a visible label "Password" is already present and correctly associated with the input, the sr-only label generated by SensitiveInput.svelte is redundant and should be removed. The placeholder attribute on the input itself can still provide a visual hint within the input field.
Testing
Manually verified the password input behavior in the browser
Confirmed via A11YRepair that the form_label_unique violation is resolved
Verified screen readers announce the field only once
Fix Before
1 Violation
Fix After
0 Violation
Additional Info
The patch submitted in this PR was generated by A11YRepair, an automated Web Accessibility repair tool that I developed to address common accessibility violations in web applications. The generated fixes were manually reviewed and validated before submission.
Contributor License Agreement
By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.
Note
Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/open-webui/open-webui/pull/20963
**Author:** [@huangkevin-apr](https://github.com/huangkevin-apr)
**Created:** 1/27/2026
**Status:** ❌ Closed
**Base:** `dev` ← **Head:** `my-feature`
---
### 📝 Commits (1)
- [`d335a10`](https://github.com/open-webui/open-webui/commit/d335a10ef52b9805fa080f03c2b058e462390fde) Fix a11y bug
### 📊 Changes
**1 file changed** (+0 additions, -1 deletions)
<details>
<summary>View changed files</summary>
📝 `src/lib/components/common/SensitiveInput.svelte` (+0 -1)
</details>
### 📄 Description
## Description
This PR fixes an accessibility issue where a password input field was associated with multiple labels, violating WCAG (1.3.1).
The issue was identified using [IBM Accessibility Checker](https://github.com/IBMa/equal-access) and resolved using [A11YRepair](https://sites.google.com/view/a11yrepair/home) by removing a redundant screen-reader-only label rendered by `SensitiveInput.svelte` when an external visible label is already present.
This is a small, non-breaking accessibility bug fix.
## Issue Details
### Reproduce Steps
This accessibility issue was identified while starting the Open WebUI frontend development server using:
```bash
npm run dev
```
On the login page, an accessibility checker reported a `form_label_unique` violation, indicating that a form control is associated with more than one `<label>` element.
Specifically, the password input field was linked to both a visible label and an additional `screen-reader-only` (sr-only) label, resulting in multiple labels referencing the same form control.
<img width="2560" height="923" alt="screenshot-1769510067051" src="https://github.com/user-attachments/assets/b9b80919-c51b-4c6b-893d-ef94fe7c808c" />
### Accessibility Impact
- Having multiple labels associated with a single input can negatively impact users of assistive technologies:
- Screen readers may announce the field label multiple times, causing confusion and reducing form usability.
- Users relying on non-visual navigation may receive redundant or conflicting context when interacting with the input.
This behavior violates [WCAG Success Criterion 1.3.1 (Info and Relationships)](https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships), which requires that form controls have clear and unambiguous programmatic labels.
Resolving this issue ensures that the password field has a single, clear accessible name, improving the login experience for screen reader users without changing any visual behavior.
## Soluation Details
The A11Y Bug Report indicates a `form_label_unique` violation, stating \"Form control has more than one label\" for the password input field. The `snippet` provided in the report, `<label for=\"password\" class=\"sr-only\">`, points to a screen-reader-only label as one of the culprits.
**Bug Scenario and Root Cause:**
The webpage screenshot and the DOM inspection reveal that the password input field has two associated labels:
1. A visually present label: `<label for=\"password\" class=\"text-sm font-medium text-left mb-1 block\">Password</label>`
2. A screen-reader-only label: `<label class=\"sr-only\" for=\"password\">Enter Your Password</label>`
The root cause is that the `SensitiveInput.svelte` component, which is used for the password input, unconditionally renders an `sr-only` label. When this component is used in a context where a separate, visible label is already provided (as seen in the screenshot), it results in two labels being associated with the same input field. This redundancy confuses assistive technologies and violates WCAG 1.3.1 (Info and Relationships).
**Proposed Fix:**
Since a visible label \"Password\" is already present and correctly associated with the input, the `sr-only` label generated by `SensitiveInput.svelte` is redundant and should be removed. The `placeholder` attribute on the input itself can still provide a visual hint within the input field.
## Testing
- Manually verified the password input behavior in the browser
- Confirmed via A11YRepair that the `form_label_unique` violation is resolved
- Verified screen readers announce the field only once
**Fix Before**
1 Violation
<img width="2560" height="923" alt="screenshot-1769510067051" src="https://github.com/user-attachments/assets/639e8b57-0f98-48ef-a8be-3d0389fea844" />
**Fix After**
0 Violation
<img width="2560" height="924" alt="image" src="https://github.com/user-attachments/assets/eb83e566-2bcc-4fd6-a8a7-195955e2e52c" />
## Additional Info
The patch submitted in this PR was generated by [A11YRepair](https://sites.google.com/view/a11yrepair/home), an automated Web Accessibility repair tool that I developed to address common accessibility violations in web applications. The generated fixes were manually reviewed and validated before submission.
### Contributor License Agreement
By submitting this pull request, I confirm that I have read and fully agree to the [Contributor License Agreement (CLA)](https://github.com/open-webui/open-webui/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT), and I am providing my contributions under its terms.
> [!NOTE]
> Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in.
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/open-webui/open-webui/pull/20963
Author: @huangkevin-apr
Created: 1/27/2026
Status: ❌ Closed
Base:
dev← Head:my-feature📝 Commits (1)
d335a10Fix a11y bug📊 Changes
1 file changed (+0 additions, -1 deletions)
View changed files
📝
src/lib/components/common/SensitiveInput.svelte(+0 -1)📄 Description
Description
This PR fixes an accessibility issue where a password input field was associated with multiple labels, violating WCAG (1.3.1).
The issue was identified using IBM Accessibility Checker and resolved using A11YRepair by removing a redundant screen-reader-only label rendered by
SensitiveInput.sveltewhen an external visible label is already present.This is a small, non-breaking accessibility bug fix.
Issue Details
Reproduce Steps
This accessibility issue was identified while starting the Open WebUI frontend development server using:
On the login page, an accessibility checker reported a
form_label_uniqueviolation, indicating that a form control is associated with more than one<label>element.Specifically, the password input field was linked to both a visible label and an additional
screen-reader-only(sr-only) label, resulting in multiple labels referencing the same form control.Accessibility Impact
This behavior violates WCAG Success Criterion 1.3.1 (Info and Relationships), which requires that form controls have clear and unambiguous programmatic labels.
Resolving this issue ensures that the password field has a single, clear accessible name, improving the login experience for screen reader users without changing any visual behavior.
Soluation Details
The A11Y Bug Report indicates a
form_label_uniqueviolation, stating "Form control has more than one label" for the password input field. Thesnippetprovided in the report,<label for=\"password\" class=\"sr-only\">, points to a screen-reader-only label as one of the culprits.Bug Scenario and Root Cause:
The webpage screenshot and the DOM inspection reveal that the password input field has two associated labels:
<label for=\"password\" class=\"text-sm font-medium text-left mb-1 block\">Password</label><label class=\"sr-only\" for=\"password\">Enter Your Password</label>The root cause is that the
SensitiveInput.sveltecomponent, which is used for the password input, unconditionally renders ansr-onlylabel. When this component is used in a context where a separate, visible label is already provided (as seen in the screenshot), it results in two labels being associated with the same input field. This redundancy confuses assistive technologies and violates WCAG 1.3.1 (Info and Relationships).Proposed Fix:
Since a visible label "Password" is already present and correctly associated with the input, the
sr-onlylabel generated bySensitiveInput.svelteis redundant and should be removed. Theplaceholderattribute on the input itself can still provide a visual hint within the input field.Testing
form_label_uniqueviolation is resolvedFix Before
1 Violation
Fix After
0 Violation
Additional Info
The patch submitted in this PR was generated by A11YRepair, an automated Web Accessibility repair tool that I developed to address common accessibility violations in web applications. The generated fixes were manually reviewed and validated before submission.
Contributor License Agreement
By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.