Layer naming conventions versus Accessibility panel metadata with symbol overrides

Short answer

Treat the Accessibility panel as the authoritative source for semantics (role, label, description) and layer names as an organizational aid for designers. When an instance overrides accessibility metadata, the instance-level value is the intended semantics for that instance and should be what downstream consumers read. Layer naming conventions are useful for navigating the Layers list, but they are freeform text with no semantic guarantee and should never be the contract your handoff pipeline depends on.

What is confirmed vs. likely

Confirmed by design intent: Sketch's Accessibility panel fields exist specifically for handoff — they are structured annotation, not decoration. Symbol instances support per-instance overrides, and an override represents deliberate local customization, so the overridden value is by definition the correct one for that instance.

Likely, but verify in your version: the exact way Sketch Cloud inspect merges master metadata with instance overrides, and whether an override can fully hide a master value versus falling back to it, has varied across Sketch releases. Do not assume the merge behavior — test it (steps below). The same applies to whether your export or codegen tooling reads the panel fields at all; many pipelines only surface layer names, which silently drops authored semantics.

Why names lose as a source of truth

• Names are unconstrained: duplicated, auto-generated ("Rectangle 42"), or renamed layers break any convention silently.
• A naming convention only works if enforced — via linting plugins or review checklists — and even then it encodes semantics as a side channel that tooling must parse heuristically.
• Nested symbols compound this: a name on an inner layer inside a nested instance tells you nothing reliable about what an assistive technology should announce.

Recommended governance for nested symbols

1. Author metadata on the master for every component in the shared library. Treat a missing role/label on a master as a defect, the same way you'd treat a missing variant.
2. Override only at the instance level when context demands it (e.g., an icon button whose label depends on where it's placed). Document in your contribution guidelines that instance overrides are intentional and reviewed.
3. Pair the panel with a naming convention, don't choose one. Names keep the Layers list scannable ("icon/close", "btn/primary"); the panel carries the contract. Drift between them is a review finding, not a tooling problem.
4. Gate library updates on a metadata check. Before publishing a library version, run a plugin or script that flags masters with empty accessibility fields and instances whose overrides reference removed inner layers. Visual changes to a component should trigger re-review of its label and description in the same PR-style review.
5. Verify the pipeline, not just the file. Confirm your actual handoff path (Sketch Cloud inspect, or any codegen plugin) reads panel metadata. If it only reads names, that is the real source of "names winning" — fix the pipeline or export a metadata report alongside it.

Quick verification test

1. Create a symbol with role and label set on the master.
2. Place two instances; override the label on one only.
3. Open the document in Sketch Cloud inspect and record what each instance reports: master value, overridden value, or nothing.
4. Repeat with a nested symbol (symbol inside a symbol) and an override on the inner layer.

The result tells you your version's actual merge behavior. If inspect shows nothing for overridden inner layers, that is a tooling gap to route around — for example by flattening critical metadata onto the top-level instance — not a reason to demote the panel below layer names.

One caveat

Accessibility panel behavior and Cloud inspect output change across Sketch releases, and third-party readers vary widely. The recommendation above (panel as canonical, instance override wins, names as navigation aid) is stable design practice; the specific merge and surfacing details should be re-verified after each major Sketch update before you codify them in team guidelines.