Problem
Found while testing Edit Profile for accessibility (#4914).
On the Edit Profile page, the form labels for the Website and Description fields are not programmatically connected to their corresponding input fields. The <label> elements use for attributes, but the inputs are missing the corresponding id attributes. This prevents screen readers from announcing the field names when users navigate to them via keyboard.
Relevant URL: https://openlibrary.org/people/firecrack?m=edit
Reproducing the bug
- Go to your Edit Profile page.
- Inspect the "website" input element (which has
name="website#0").
- Inspect the "Description" textarea (which has
name="description").
- Expected behavior: Form inputs should have
id attributes that exactly match their label's for attribute so they compute an accessible name correctly.
- Actual behavior: The inputs lack
id attributes, breaking the connection to their labels.
Context
- Browser (Chrome, Safari, Firefox, etc): [Insert your browser, e.g., Chrome]
- OS (Windows, Mac, etc): [Insert your OS, e.g., Windows]
- Logged in (Y/N): Y
- Environment (prod, dev, local): prod
Breakdown
Implementation Details (for maintainers)
Update the HTML templates for these fields to make them accessible:
- Description Field: Add
id="description" to match the label's for attribute.
- Website Field: Since this is a repeating field (unique=False branch in the macro), we need to ensure valid HTML. The first input (
i==0) should get id="website" to match the <label for="website">. Any dynamically added subsequent inputs (i>0) should get an aria-label="Website" to remain accessible without duplicating the ID.
Requirements Checklist
Related files
openlibrary/templates/type/user/edit.htmlopenlibrary/macros/UserEditRow.html
Stakeholders
Instructions for Contributors
- Please run these commands to ensure your repository is up to date before creating a new branch to work on this issue and each time after pushing code to Github, because the pre-commit bot may add commits to your PRs upstream.
Problem
Found while testing Edit Profile for accessibility (#4914).
On the Edit Profile page, the form labels for the Website and Description fields are not programmatically connected to their corresponding input fields. The
<label>elements useforattributes, but the inputs are missing the correspondingidattributes. This prevents screen readers from announcing the field names when users navigate to them via keyboard.Relevant URL:
https://openlibrary.org/people/firecrack?m=editReproducing the bug
name="website#0").name="description").idattributes that exactly match their label'sforattribute so they compute an accessible name correctly.idattributes, breaking the connection to their labels.Context
Breakdown
Implementation Details (for maintainers)
Update the HTML templates for these fields to make them accessible:
id="description"to match the label'sforattribute.i==0) should getid="website"to match the<label for="website">. Any dynamically added subsequent inputs (i>0) should get anaria-label="Website"to remain accessible without duplicating the ID.Requirements Checklist
id="description"to the textarea inopenlibrary/templates/type/user/edit.html.openlibrary/macros/UserEditRow.htmlso the first website input getsid="website".openlibrary/macros/UserEditRow.htmlso subsequent website inputs getaria-label="Website".Related files
openlibrary/templates/type/user/edit.htmlopenlibrary/macros/UserEditRow.htmlStakeholders
Instructions for Contributors