Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

a11y: keyboard access for interactive spatial views (atlas, square, latent space)

Aperta
#100 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
42/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
typescript

Direzione di ricerca

Inizia con apps/smartem/src/components/spatial/AtlasMap.tsx, SquareMap.tsx e LatentSpacePanel.tsx, quindi esamina biome.json e i problemi di lint elencati. Decidi un modello di interazione per mappe SVG dense prima di implementare il focus da tastiera, l’attivazione, la navigazione e gli indicatori di focus visibili. Il lavoro è completato quando i componenti supportano l’accesso da tastiera e tramite screen reader e le regole Biome corrispondenti possono essere abilitate senza problemi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

smartem-frontend

Retargeted. This issue originally listed three findings, all in app/routes/squareLR.tsx in
the legacy front end. That app was removed in smartem-frontend#136 and the file no longer
exists, so the original findings are moot. Reviewing them against the current front end
(per the earlier comment: "see if any of this applied to the new f/e, recycle or dismiss"),
one of the three carries over.

Dismissed - now structurally prevented

Missing alt text and SVG without <title> cannot recur silently. biome.json sets
recommended: true with the a11y group active, lint is enforced in CI, and
biome lint apps/smartem/src packages currently passes with zero findings. There are no
<img> elements without alt in the codebase.

Recycled - interactive elements without keyboard support

The original third finding (interactive SVG elements reachable only by mouse) has reappeared in
the new spatial components. Running the full a11y rule group reports:

apps/smartem/src/components/spatial/AtlasMap.tsx:318          noNoninteractiveElementInteractions
apps/smartem/src/components/spatial/SquareMap.tsx:481         noNoninteractiveElementInteractions
apps/smartem/src/components/spatial/AtlasMap.tsx:371          useSemanticElements
apps/smartem/src/components/spatial/SquareMap.tsx:550         useSemanticElements
apps/smartem/src/components/spatial/LatentSpacePanel.tsx:143  useSemanticElements

The practical consequence: the atlas and square maps are the primary navigation surface, and
grid squares are selected by clicking SVG shapes. Those targets cannot currently be reached or
activated by keyboard, so keyboard-only and screen-reader users have no route into the
per-square views at all.

Why CI does not catch this

Neither rule is active under the current configuration:

  • noNoninteractiveElementInteractions is not part of Biome's recommended set, so it never
    runs unless explicitly enabled.
  • useSemanticElements is explicitly switched off in biome.json.

Worth confirming whether disabling useSemanticElements was a deliberate decision for the
spatial components (where a semantic element may genuinely not fit inside an SVG) or was
inherited. If deliberate, the exception is better expressed narrowly than globally.

Scope

  • Make grid squares and foil holes focusable and activatable by keyboard in AtlasMap and
    SquareMap, with a visible focus indicator that works against the underlying imagery.
  • Decide the interaction model for a dense SVG map before implementing - tabbing through
    several hundred foil holes individually would be worse than no keyboard access. Roving
    tabindex over squares, with arrow-key traversal within a square, is the likely shape.
  • Apply the same treatment to LatentSpacePanel.
  • Once the components conform, enable the corresponding rules in biome.json so the class of
    problem stays fixed rather than recurring.

Priority

Real but not urgent, and honestly assessed: the enforced rules already cover the common cases,
and this affects an internal scientific tool with a small known user base. It is recorded here
so the gap is known rather than rediscovered.

Lingua principale
TypeScript
Stelle
0
Fork
0
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DiamondLightSource/smartem-devtools

Tutte le issue di DiamondLightSource/smartem-devtools

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.