Motion / Spring transition — accessibility

spring.ts is a motion primitive, not a control — it has no DOM node, no role and nothing to focus. This page covers the one accessibility surface it does have: motion itself.

Keyboard

• Not applicable — the module renders nothing and owns no keyboard behaviour. Whatever element a consumer animates (a dialog panel, a button) keeps its own keyboard handling untouched; the spring only ever changes a numeric CSS property on it.

ARIA

• Not applicable — no element, no role, no announcement. Any ARIA implication of a state change belongs to the consumer (see multi-step-dialog.a11y.md, morph-text.a11y.md).

Focus

• The spring never moves focus and never traps it; it runs alongside whatever focus management the consumer already does (Dialog's focus trap keeps working unchanged while its panel resizes).

Contrast

• Not applicable — the module has no visual rendering of its own.

Known limits

• prefers-reduced-motion: reduce is the only accessibility control: springAnimate returns null and the consumer must apply the end state immediately with no animation. Every current caller (Dialog, MorphText) does this; a new caller that forgets to handle the null return will silently keep the old, un-morphed layout for reduced-motion users, which is the safe failure mode but should still be tested.
• Content that is meant to appear only once a motion has essentially finished should key off SPRING_ARRIVE_MS, not SPRING_MS — using the full duration means the final ~170 ms of overshoot/settle delays that content for no reason a screen-reader or keyboard user would perceive as a wait.
• The motion carries no information on its own — nothing is communicated by the spring that isn't also present in the before/after state of the element itself.