fix: don't expose handler-less TouchableRipple as a disabled control

[lukemorawski]

Motivation

TouchableRipple had const disabled = disabledProp || !hasPassedTouchHandler, so anything without a press handler got announced as a disabled control. Split into two flags:

const isControl = hasPassedTouchHandler || Boolean(disabledProp);
const isInteractive = hasPassedTouchHandler && !disabledProp;

Non-controls now render a plain Animated.View instead of a Pressable.

Worth knowing why it drops the Pressable instead of just passing the caller's disabled through: disabled also gates touch-responder claiming (Pressability.js:448, onStartShouldSetResponder: () => !disabled). Fixing only the announcement turns claiming on, so handler-less ripples start swallowing taps. TextInput wraps its field and icons in <Pressable onPress={focusInput}> (TextInput.tsx:352), so tapping a decorative icon stopped focusing the field. Tests stayed green through that.

Two things kept on purpose, both break stuff if dropped:

• accessible={rest.accessible !== false}, or a checked CheckboxItem with no handler loses its role and state.
• focusable={rest.focusable ?? false}, or on web the icon lands in the tab order, since RNW turns role="button" into a real <button>.

Related issue

Closes #5070

Supersedes #5011, which fixes the same symptom in Chip.tsx only by injecting an empty onPress. That swaps a false "disabled" for a false "enabled" and leaves the other 21 consumers broken.

Test plan

Lint, typecheck and tests pass: 55 suites, 742 tests, 169 snapshots.

The suite can't catch this though. It renders an element tree, never a DOM or a native view, and jest never loads TouchableRipple.tsx at all. So it's checked on device, example app, TextInput screen with "Leading icon" on. Leading magnifier has no handler, trailing clear button does.

	announced disabled	tap reaches field	clear button still works
iOS 18.3	enabled: false -> true	yes	yes
Android 15	enabled="false" -> "true"	yes, 3/3 runs	yes
web	<button disabled> -> gone	yes	yes

Web also keeps tabindex="-1" on the decorative icon.

Snapshots are noisy but mechanical: 80 elements drop the Pressable handlers and the always-undefined a11y scaffolding. Checked every style key/value pair, nothing net-added. Some aria-* show up raw now because View.js does that folding at runtime and the jest preset mocks View.

Two extras, worth a look

TextInputIcon was faking disabled by nulling its own handler, which only worked because of this bug. Now passes disabled through.

IconButton.getIconColor returned on disabled before reading customIconColor, so once TextInputIcon forwarded disabled a disabled field's icon lost its custom and error colour. Reordered so an explicit colour wins, opacity still shows disabled. No snapshot churn, so nothing else passes both, but it is a public component behaviour change and the bit I'd most want checked.

[MikitasK]

what do you think about making it non-accessible when it has no onPress?

Suggested change

	onPress={onPress}
	onPress={onPress}
	accessible={Boolean(onPress)}
	role={onPress ? 'button' : 'none'}

updated snapshot still has accessible={true} & role="button". RN Web maps that role to a native <button>, focusable={false} only removes it from tab order.
that's why screen readers may still announce actionable button that does nothing

[lukemorawski]

yep, RNW does map role="button" to a real , focusable={false} only adds tabindex="-1". Measured before: web , Android Button clickable=true. Same on iOS.
but i fixed in TouchableRipple instead of here. IconButton, Drawer.Item and Drawer.CollapsedItem all set role="button" unconditionally with an optional onPress, so fixing it here would leave two others. AppbarContent already gates its role on onPress.
Only the role is dropped, the element stays. accessible={false} is a noop on web anyway (not in RNW's forwardedProps) and on naitve it kills aria-label, which for an icon-only FAB or IconButton is the only thing it has to announce. dropping the role alone is enough on both platforms
Covers button, imagebutton, link, menuitem and tab. checkbox, radio and switch are kept, they still describe a read-only view.
After fix: web

, Android plain View clickable=false, clear button unchanged on both.

[MikitasK]

what about keeping existing disabled-color precedence here & handling the TextInput.Icon case locally?
moving customIconColor first changes every <IconButton disabled iconColor="......" />.

Button still give disabled colors precedence (link) while IconButton docs list onSurfaceDisabled (link)
however, if this global behavior change is intentional, maybe we can at least document it?

[lukemorawski]

ok reverted IconButton/utils.ts
The reorder was only collateral from forwarding disabled into IconButton. it's now handled locally instead: TextInput.Icon now only forwards disabled when the icon actually has a touch handler. That also fixes the other bug in this PR - a decorative magnifier glass in a disabled field was still rendering as
Default case is unchanged, TextInput's getIconColor already returns onSurface when disabled, same as IconButton's disabled branch.
One real thing: an interactive icon on a disabled field now takes IconButton's disabled colour, so an explicit iconColor or the error colour no longer wins there. matches Button and the docs, so nothing to document