Problem
The editor toolbar currently exposes five export/share entry points that all call the same onOpenExport() function. The IMG/UML/{} controls do not select or execute different export behavior; they only open the same ExportModal.
ExportModal currently offers SQL DDL, SVG, PlantUML, Mermaid, DBML, Prisma, data-dictionary CSV/Markdown and share-link actions. It does not expose a JSON export action. Therefore changing the three accessible names to 이미지 내보내기 모달 열기, UML 내보내기 모달 열기, and JSON 내보내기 모달 열기 without changing behavior creates a false accessible affordance, especially for JSON.
PR #1082 demonstrated this failure mode and has been repaired back to zero effective delta rather than merging inaccurate labels.
RED
Add a realistic interaction test that proves the toolbar does not advertise an action that the resulting dialog cannot perform. The test should fail against the current duplicate shortcuts, not merely snapshot label strings.
At minimum cover:
- every toolbar control whose accessible name names a concrete export format must either execute/focus that concrete export action or be removed;
- a JSON-labelled control is forbidden unless a real, contract-defined JSON artifact exists in the modal/export domain;
- keyboard activation and pointer activation have identical semantics;
- disabled state remains truthful when there is no diagram/project data.
GREEN
Choose one coherent product model and implement it end-to-end:
- Prefer a single
공유 및 내보내기 toolbar entry point when the modal is intentionally a chooser; remove duplicate format-looking affordances, while preserving availability when either share or diagram export is meaningful; or
- Make format shortcuts real: pass a typed export target into the modal, focus/select the matching artifact, and define JSON as a real versioned export contract before exposing a JSON shortcut.
Keep the visible label, accessible name, modal state and eventual action semantically aligned. Add current-head interaction/a11y evidence and update the product gap baseline/CHANGELOG if the buyer-visible toolbar changes.
Acceptance
- No duplicate toolbar button exists solely to open the same chooser while claiming a different concrete action.
- No JSON affordance exists without a real JSON export artifact and contract.
getByRole(..., {name}) tests assert behavior, not only unique strings.
- Pointer, Enter/Space, disabled, empty-state and focus behavior are covered.
- Exact-head frontend tests/build and browser accessibility evidence are GREEN before promotion.
Problem
The editor toolbar currently exposes five export/share entry points that all call the same
onOpenExport()function. The IMG/UML/{}controls do not select or execute different export behavior; they only open the sameExportModal.ExportModalcurrently offers SQL DDL, SVG, PlantUML, Mermaid, DBML, Prisma, data-dictionary CSV/Markdown and share-link actions. It does not expose a JSON export action. Therefore changing the three accessible names to이미지 내보내기 모달 열기,UML 내보내기 모달 열기, andJSON 내보내기 모달 열기without changing behavior creates a false accessible affordance, especially for JSON.PR #1082 demonstrated this failure mode and has been repaired back to zero effective delta rather than merging inaccurate labels.
RED
Add a realistic interaction test that proves the toolbar does not advertise an action that the resulting dialog cannot perform. The test should fail against the current duplicate shortcuts, not merely snapshot label strings.
At minimum cover:
GREEN
Choose one coherent product model and implement it end-to-end:
공유 및 내보내기toolbar entry point when the modal is intentionally a chooser; remove duplicate format-looking affordances, while preserving availability when either share or diagram export is meaningful; orKeep the visible label, accessible name, modal state and eventual action semantically aligned. Add current-head interaction/a11y evidence and update the product gap baseline/CHANGELOG if the buyer-visible toolbar changes.
Acceptance
getByRole(..., {name})tests assert behavior, not only unique strings.