CodeForPhilly / CodeForPhilly/codeforphilly-ng

Form error ids should derive from useId (hardcoded title-error/slug-error collide across screen + modal)

Offen
#164 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
TypeScript
Sterne
1
Forks
1
Ø Merge
5 T. 3 Std.
Gemergte PRs (30 T.)
9

Beschreibung

Follow-up from PR #155 (ARIA correctness).

The form error wiring in that PR gives every error `

` an id and points the control at it with `aria-describedby`. Several of those ids are hardcoded string literals — `title-error`, `slug-error`, and siblings in ProjectEdit, ProjectBuzzNew, TagEditModal, etc. When a screen and a modal that both use one of those ids are mounted at the same time (e.g. ProjectEdit with PostHelpWantedModal open), the ids collide and `aria-describedby` can resolve to the wrong element.

Derive the ids from `useId()` (as SearchBox and TagPicker already do) so each mounted form instance owns unique ids. Consider a tiny helper so the `${id}-error` convention stays in one place.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01RdRwHvDupRLV8GuJpYKzEr

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Rechercherichtung

Start by locating the form error wiring in ProjectEdit, ProjectBuzzNew, TagEditModal, and related components, then compare the existing useId usage in SearchBox and TagPicker. Centralize or consistently derive each error id from the form instance, and verify that simultaneously mounted forms have unique ids and matching aria-describedby references.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
typescript
Bereich
accessibility, frontend
Issue-Typ
Bug
Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Aktivitätsstatus
Aktiv
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
72/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.