nextcloud-libraries / nextcloud-libraries/nextcloud-image-editor
Accessibility: annotations are mouse-only, and four smaller gaps
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2
- Forks
- 0
- Avg merge
- 1h 46m
- Merged PRs (30d)
- 58
Description
Going through the editor with the keyboard and the accessibility tree after #16, mostly to see what we would have to fix before calling this done. Writing down what I found so it does not get lost.
The good news first, since it is most of it: every control has an accessible name, nothing focusable is hidden behind aria-hidden, the focus outline shows up everywhere, the canvas carries role="img" and a label in all six modes, the rail exposes the active mode through aria-pressed, the live region already announces mode switches and annotations appearing and disappearing, and animation respects prefers-reduced-motion. Tab also leaves the editor instead of trapping, which is right for something embedded in a page.
What is missing:
- Annotations cannot be reached with a keyboard at all. The canvas has no
tabindex, annotations are not focusable, and the selection toolbar only exists once something has been selected with a pointer. Drawing, selecting, moving and deleting are mouse-only, and the arrow-key nudging and Delete inuseEditorShortcutsonly work after a pointer selection, so they are unreachable too. Same for stickers, redaction and text. This is the limitation we already listed in the beta.1 changelog, it just has evidence now. It is also the only finding here that blocks a whole feature rather than degrading it. - The colour input has no name.
input[type=color]in the annotate panel has neitheraria-labelnortitle, and it is the only unnamed control in the editor. - Sliders announce a bare number. They are labelled and carry
minandmax, but none of them setaria-valuetext, so exposure reads "0" and not "0 stops". The range is -100 to 100 and that scale means something we are not saying. - No headings or landmarks. Not an issue when a host page provides its own structure, but there is nothing to navigate by in the fullscreen case.
- Contrast on the chrome is not guaranteed. The zoom readout is at
opacity: 0.8on a translucent pill over whatever photo is loaded, so the ratio depends on the image and cannot be asserted. Worth deciding on rather than leaving to chance.
The first one is the one worth doing. The rest are small enough to take in one pass.
👾 The audit behind this was run with Claude Code.
Contributor guide
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 by tracing the editor canvas and annotation selection flow, then inspect useEditorShortcuts and the annotate panel's color input and sliders. The main goal is keyboard access to drawing, selection, movement, deletion, stickers, redaction, and text; also address the listed naming, value-text, landmark, and contrast gaps. Verify the result with a keyboard pass and accessibility-tree check.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- accessibility, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100