feat(a11y): automatically set `accessible` prop with `role` prop by mdjastrzebski · Pull Request #57633 · react/react-native

mdjastrzebski · 2026-07-22T09:40:54Z

Summary:

Setting role prop (except none/presentation) automatically sets accessible prop on View and Image. This aligns web behavior when setting role attribute is enough to add the element into accessibility tree.

This aligns also with Image alt web-compat prop which also enables accessible when set.

The change skips Text, TextInput, etc as they are implicitly members of accessibility tree by default.

This change also intentionally skips accessibilityRole as legacy, non-web version.

This also helps when using React Strict DOM, as it exposes role prop, but does not expose accessible prop, hence setting role on h.div basically has no effect. I think this changes is better suited for RN repo though.

Changelog:

[GENERAL] [CHANGED] Automatically set acessible prop when role prop is set (except none/presenation)

Test Plan:

Added relevant Fantom tests.

javache · 2026-07-24T11:23:15Z

This seems reasonable, but is there any chance we can do this on the native side instead? We should avoid post-processing props in JS for perf reasons.

mdjastrzebski · 2026-07-24T12:43:31Z

@javache I did some research and it looks like C++ calculation would be fine for iOS, but on Android we need to have duplicated logic in Kotlin since the ViewManagers use the original JS rawProps, not the C++ derived values. Props 2.0 would solve it but it's not enabled atm.

Hence, I would advise to keep it in JS right now, and migrate multiple prop calculation from JS to C++ as a unified effort when Props 2.0 is available on Android.

javache · 2026-07-27T09:00:47Z

  const {
    'aria-busy': ariaBusy,
    'aria-checked': ariaChecked,
    'aria-disabled': ariaDisabled,
    'aria-expanded': ariaExpanded,
    'aria-selected': ariaSelected,
    'aria-hidden': ariaHidden,
    src,
    ...restProps
  } = props;


Extract accessible here (ditto for 'aria-label/accessibilityLabel) - we generally want to extract props once, and avoid passing them both in restProps` and through explicit props.

You'd want to model this like View where we create a single resolvedProps object which we write everything to.

Fine to do this as a follow-up cleanup PR, and overload this one.

I will submit follow-up for not to muddle the scope

meta-codesync · 2026-07-27T09:01:23Z

@javache has imported this pull request. If you are a Meta employee, you can view this in D113754156.

meta-codesync · 2026-07-27T20:58:01Z

@javache merged this pull request in 4043e81.

Summary: This diff reverts react#57633 ## Changelog [GENERAL] [CHANGED] Revert: Automatically set acessible prop when role prop is set (except none/presenation) Differential Revision: D113922297

javache · 2026-07-29T09:30:55Z

This caused some internal failures, so we've had to back it out for now. Let me follow-up to identify the root cause.

…t none/presenation) (#57743) Summary: Pull Request resolved: #57743 This diff reverts #57633 ## Changelog [GENERAL] [CHANGED] Revert: Automatically set acessible prop when role prop is set (except none/presenation) Reviewed By: javache Differential Revision: D113922297 fbshipit-source-id: 705fe67f5f712be5e7baccdd01603915f47893a1

javache · 2026-07-31T08:51:23Z

The reason for the revert is that we had some components already setting role, but not accessible, so this change made them Focusable. This is a breaking change (and we should document it as such) and we should wait until the next breaking changes window to re-land this.

mdjastrzebski · 2026-07-31T12:34:14Z

@javache thank you for your research, could you share some context why components (View, Image) would be setting role without accessible prop? Afaik, these components wouldn't be picked up by screen reader/a11y without the accessible prop.

Q2: when would be next such window?

javache · 2026-07-31T14:56:29Z

@javache thank you for your research, could you share some context why components (View, Image) would be setting role without accessible prop? Afaik, these components wouldn't be picked up by screen reader/a11y without the accessible prop.

We had some accidental usages of this, as previously this was a no-op.

Q2: when would be next such window?

the next branch-cut is September 7.

mdjastrzebski · 2026-07-31T17:43:48Z

To clarify the window is before or after Sep 7?

javache · 2026-08-03T09:29:49Z

To clarify the window is before or after Sep 7?

It's after. We're aiming to not make any breaking changes on main until the next branch cut.

Summary: Two changes to `Image.ios.js` (follow up to #57633): 1. **Extract props once.** Per javache's review comment, props are destructured once in the parameter list and written into a single `resolvedProps` object, spread into `ImageViewNativeComponent` once — modelled on `View`, matching `Image.android.js`. `ImageAnalyticsTagContext.Consumer` is replaced with `use(ImageAnalyticsTagContext)`. 2. **Align `aria-*` vs `accessibilityState`.** `aria-*` state props now take priority per key with fallback to `accessibilityState`, matching `View`, `Text`, `TextInput`, `Pressable` and `Image.android.js`. `Image.ios.js` was the only outlier, where the raw `accessibilityState` object replaced the merged one. Also aligns the `alt` null-check with `Image.android.js` (`alt != null`), so an explicit `alt={null}` no longer forces `accessible: true`. Adds `Image-itest.js` coverage for the `aria-*` to `accessibilityState` mapping, including `aria-checked` as `true`/`false`/`"mixed"`, precedence over the matching `accessibilityState` field, and that `accessibilityState` is not emitted when no state props are given. ## Changelog:  [IOS] [FIXED] - Image: aria-* state props are no longer ignored when accessibilityState is also present Pull Request resolved: #57710 Test Plan: Unchanged tests pass + added new tests Reviewed By: christophpurrer Differential Revision: D114048967 Pulled By: javache fbshipit-source-id: c09647dba932cb747ecab6392e281009e85b8d3f

mdjastrzebski added 2 commits July 22, 2026 11:18

feat: automatically set accessible when setting role prop

37d73ae

tweaks

d72a04b

meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jul 22, 2026

format

59f1947

facebook-github-tools Bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Jul 22, 2026

mdjastrzebski changed the title ~~feat(a11y): automatic accessible with role prop~~ feat(a11y): automatically set accessible prop with role prop Jul 22, 2026

javache reviewed Jul 27, 2026

View reviewed changes

meta-codesync Bot closed this in 4043e81 Jul 27, 2026

meta-codesync Bot added the Merged This PR has been merged. label Jul 27, 2026

mdjastrzebski mentioned this pull request Jul 28, 2026

fix(ios): extract Image.ios.js props once #57710

Closed

rozele mentioned this pull request Jul 28, 2026

Revert D113754156 (#57743) #57743

Closed

javache reopened this Jul 31, 2026

javache closed this Jul 31, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(a11y): automatically set `accessible` prop with `role` prop - #57633

feat(a11y): automatically set `accessible` prop with `role` prop#57633
mdjastrzebski wants to merge 3 commits into
react:mainfrom
mdjastrzebski:feat/automatic-accessible-with-role-prop

mdjastrzebski commented Jul 22, 2026 •

edited

Loading

Uh oh!

javache commented Jul 24, 2026

Uh oh!

mdjastrzebski commented Jul 24, 2026

Uh oh!

javache Jul 27, 2026

Uh oh!

mdjastrzebski Jul 27, 2026

Uh oh!

meta-codesync Bot commented Jul 27, 2026

Uh oh!

meta-codesync Bot commented Jul 27, 2026

Uh oh!

javache commented Jul 29, 2026

Uh oh!

javache commented Jul 31, 2026 •

edited

Loading

Uh oh!

mdjastrzebski commented Jul 31, 2026 •

edited

Loading

Uh oh!

javache commented Jul 31, 2026

Uh oh!

mdjastrzebski commented Jul 31, 2026

Uh oh!

javache commented Aug 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

mdjastrzebski commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary:

Changelog:

Test Plan:

Uh oh!

javache commented Jul 24, 2026

Uh oh!

mdjastrzebski commented Jul 24, 2026

Uh oh!

javache Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

mdjastrzebski Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

meta-codesync Bot commented Jul 27, 2026

Uh oh!

meta-codesync Bot commented Jul 27, 2026

Uh oh!

javache commented Jul 29, 2026

Uh oh!

javache commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mdjastrzebski commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

javache commented Jul 31, 2026

Uh oh!

mdjastrzebski commented Jul 31, 2026

Uh oh!

javache commented Aug 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mdjastrzebski commented Jul 22, 2026 •

edited

Loading

javache commented Jul 31, 2026 •

edited

Loading

mdjastrzebski commented Jul 31, 2026 •

edited

Loading