Editor label does not give the contenteditable textbox an accessible name
Nobody has claimed this yet.
- Dominant language
- Blade
- Stars
- 977
- Forks
- 112
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 21
Description
### Flux version
v2.17.1
### Livewire version
v4.4.2
### Tailwind version
v4.3.3
### Browser and Operating System
Google Chrome 151.0.0.0 on macOS 27.0
### What is the problem?
`flux:editor` applies its visible field label and the default `aria-label="Rich text editor"` to the outer `ui-editor` custom element. That element has no role, while the generated `contenteditable` element has `role="textbox"` but neither `aria-labelledby` nor `aria-label`.
The browser accessibility tree exposes an unnamed textbox. axe 4.12.1 reports the serious `aria-input-field-name` rule on the actual editing surface. The naming attributes on the role-less outer custom element do not name the nested textbox.
### Code snippets to replicate the problem
```blade
```
Steps:
1. Complete the standard Flux Pro installation and include the documented Flux assets.
2. Render the snippet without published component overrides.
3. Build the assets and clear compiled Blade views.
4. Wait for the Editor's lazy-loaded JavaScript to initialize.
5. Inspect `[role="textbox"][contenteditable="true"]` in the browser accessibility tree and run axe with WCAG A and AA tags.
6. Observe an unnamed textbox and `aria-input-field-name`.
Relevant rendered output:
```html
```
axe 4.12.1 reports:
```text
aria-input-field-name (serious)
ARIA input fields must have an accessible name.
```
### Screenshots/ screen recordings of the problem
Not applicable. This accessibility defect is not visually observable; the relevant DOM, accessibility tree and exact axe result are included above as searchable text.
### How do you expect it to work?
The generated textbox should receive the visible field label through `aria-labelledby`, falling back to the Editor's localized `Rich text editor` label when no visible label is provided. If the outer custom element retains ARIA naming or description attributes, it should expose compatible semantics; the actual editing surface must always have its own accessible name.
Toolbar commands, lazy loading, content binding and focus behavior should remain unchanged.
### Please confirm (incomplete submissions will not be addressed)
- [x] I have provided easy and step-by-step instructions to reproduce the bug.
- [x] I have provided code samples as text and NOT images.
- [x] I understand my bug report will be closed if I haven't met the criteria above.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the flux:editor component and inspect the generated [role="textbox"][contenteditable="true"] element, comparing it with the outer ui-editor attributes shown in the report. Verify the fix by rendering the provided Release notes example, checking the accessibility tree, and rerunning axe's aria-input-field-name rule; the textbox should receive the visible label or the localized fallback without changing toolbar, lazy-loading, binding, or focus behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- tailwindcss
- Domain
- accessibility, frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100