nextcloud-libraries / nextcloud-libraries/nextcloud-image-editor

Accessibility: annotations are mouse-only, and four smaller gaps

Open
#17 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

AI assisted type: enhancement
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 in useEditorShortcuts only 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 neither aria-label nor title, and it is the only unnamed control in the editor.
  • Sliders announce a bare number. They are labelled and carry min and max, but none of them set aria-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.8 on 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.