fix(components): make component's own disabled state win accessibilityState merges

[Chibuzor-Nwemambu]

Summary

• Flips the accessibilityState merge order in Button, IconButton, Input, and TextArea so the component's own computed disabled always wins over a caller-supplied accessibilityState.disabled, instead of the other way around.
• disabled drives real behavior (editable, styling) — letting a caller's accessibilityState disagree with it can mislead assistive technology users specifically (e.g. a screen reader announcing "disabled" on a field that's actually fully interactive, or vice versa). No realistic legitimate use case was found for allowing that disagreement.
• Other accessibilityState keys (selected, expanded, checked, etc.) are untouched and remain fully caller-overridable — this only changes disabled.
• TextField/Search both wrap Input and forward accessibilityState through {...rest}, so they inherit the fix automatically with no changes of their own.
• Input.tsx here is written directly as the final, complete form (merges and the component's disabled wins) — main never had fix(components): Input clobbers a caller-supplied accessibilityState instead of merging it #217's partial fix, only 214-batch-2-tests did, and that partial fix has now been reverted there in favor of this being the single, canonical fix. This PR fully supersedes and closes fix(components): Input clobbers a caller-supplied accessibilityState instead of merging it #217.
• Source-only change, no test files touched — regression tests are being added as a follow-up directly into PR test(components): add tests for Button, Badge, Divider, Link, Typography #216 (Button.test.tsx, currently zero coverage of this) and PR test(components): add tests for Input, TextField, TextArea, Search, EDSProvider #218 (Input.test.tsx/TextArea.test.tsx, currently zero coverage of this after the fix(components): Input clobbers a caller-supplied accessibilityState instead of merging it #217 partial-fix revert) once this PR merges.

Fixes #220. Fixes #217.

Test plan

• pnpm lint — clean
• pnpm check-types — clean
• pnpm build — clean
• Regression tests to be added to PR test(components): add tests for Button, Badge, Divider, Link, Typography #216 and PR test(components): add tests for Input, TextField, TextArea, Search, EDSProvider #218 as a follow-up once this merges (this PR intentionally has no test changes, per the agreed atomic-commit split)

[Chibuzor-Nwemambu]

@claude review

[claude]

Claude finished @Chibuzor-Nwemambu's task in 2m 6s —— View job

---

Code Review

• Gather context (read diff + surrounding code)
• Understand the request
• Analyze the changes for correctness & consistency
• Post review feedback

I reviewed all four changed files against the surrounding prop-spread ordering. The intent — component's own disabled wins the accessibilityState merge while other keys stay caller-overridable — is sound. Three of the four components implement it correctly, but IconButton has a blocking bug that makes the fix a no-op there.

---

🔴 Blocker — IconButton.tsx: the fix never takes effect

In IconButton, the explicit accessibilityState prop is placed before the {...pressableProps} spread:

// packages/components/src/components/Button/IconButton.tsx:44-49
accessibilityState={{
    ...pressableProps.accessibilityState,
    disabled: disabled ?? false,
}}
disabled={disabled}
{...pressableProps}   // ← spreads AFTER, clobbering the computed accessibilityState

accessibilityState is not destructured out of props (only name, tone, size, variant, round, disabled, ref are — BaseButtonProps extends PressableProps, so accessibilityState stays in pressableProps). Because {...pressableProps} comes after the explicit prop, a caller-supplied accessibilityState overrides the entire computed object — the disabled merge is discarded completely.

Concretely, <IconButton disabled accessibilityState={{ selected: true }} /> renders accessibilityState={{ selected: true }} — no disabled key at all. That's the opposite of this PR's goal, and arguably worse than before (a genuinely disabled control announces no disabled state to assistive tech).

Note this is the same JSX ordering the file already had; the PR flipped the inner merge order but the outer spread still wins, so the change has no observable effect on IconButton.

Fix: move accessibilityState to after {...pressableProps}, exactly matching Button.tsx:

<Pressable
    ref={ref}
    style={styles.container}
    accessibilityRole={"button"}
    disabled={disabled}
    {...pressableProps}
    accessibilityState={{
        ...pressableProps.accessibilityState,
        disabled: disabled ?? false,
    }}
>

Fix this →

---

✅ The other three are correct

• Button.tsx — {...pressableProps} comes first, then the explicit accessibilityState, so the merge wins. Inner order (...spread then disabled) is right. ✔
• Input.tsx — {...rest} is spread on line 116, the explicit accessibilityState={{ ...rest.accessibilityState, disabled }} follows on 126–129, so it wins over rest. ✔
• TextArea.tsx — accessibilityState is destructured into userAccessibilityState (line 44), so the trailing {...rest} (line 162) does not re-introduce it; { ...userAccessibilityState, disabled } stands. ✔

---

Notes / non-blocking

• Consistency: once IconButton is fixed, Button and IconButton will finally share the same JSX ordering — worth keeping them identical to avoid this class of bug recurring.
• Test coverage: the PR defers regression tests to test(components): add tests for Button, Badge, Divider, Link, Typography #216/test(components): add tests for Input, TextField, TextArea, Search, EDSProvider #218. That's a reasonable split, but please make sure the IconButton case (caller passes accessibilityState with disabled) is explicitly covered — it's precisely the case that silently regressed here and wouldn't be caught by a Button-only test.

Everything else (scope limited to disabled, other a11y keys left caller-overridable, TextField/Search inheriting via forwarding) checks out.
· branch 220-accessibility-state-merge-order

[Chibuzor-Nwemambu]

Good catch — verified and fixed in 952f426. `IconButton` had `accessibilityState` before `{...pressableProps}` while `Button` had it after; moved it to match `Button.tsx` exactly, so `{...pressableProps}` now spreads first and the explicit `accessibilityState` (with its own inner disabled-wins merge) applies last and actually takes effect.

Noted your point on test coverage too — when the regression tests go into PR #216's `Button.test.tsx` (queued until this PR merges), I'll make sure the `Button.Icon`/`IconButton` case specifically covers a caller passing `accessibilityState` with a conflicting `disabled` key, not just the plain `Button` case — that's exactly the scenario this bug would have slipped through on.