feat: unify platform specific high contrast APIs to AccessibilityInfo.isHighContrastEnabled

[Saadnajmi]

Summary:

Every platform has some form of "high Contrast", with a separate React Native API to access it. These all do the same thing, query the OS to see if its version of "high contrast" is enabled, and report it back to AccessibilityInfo. Sadly, each platform (Android, iOS, macOS, Windows) used their own platform specific name to read this in JS.

• On Android, it's isHighTextContrastEnabled, introduced in RN 0.77 with d4ea147
• On iOS, it's isDarkerSystemColorsEnabled, introduced in RN 0.77 with af3bee6
  • Sidenote: this API natively seems to be superseded by accessibilityContrast. Luckily, inspecting UIKits headers tells me the two should report the same info most of the time.
• On macOS, we chose isHighContrastEnabled which is at least as old as RNM 0.66 but probably older
• On Windows, it's AppTheme.isHighContrast, which I'm not sure how old it is.
  • Sidenote: The inspiration for this PR was to introduce an API to AccessibilityInfo upstream of React Native macOS and Windows so they both could implement it and in the new architecture, we would have a simpler API.

This leads to real divergences in product code, where we must fork our JS per platform to do essentially the same thing (see microsoft/react-native-gallery#470 for an example).

Let's unify the APIs under a single isHighContrastEnabled API. A bit cheeky I chose the API name from the fork of React Native I maintain (React Native macOS), but I do think it's the most coherent name.

To help migration, I added a deprecation warning to the iOS and Android APIs. The idea being

• RN 0.79: Add the new API, deprecate the old ones
• RN 0.80+: Remove the old ones
  so that users have time to migrate

Changelog:

[GENERAL] [ADDED] - Add isHighContrastEnabled to AccessibilityInfo

Test Plan:

I updated the AccessibilityExample page on RNTester with both the old and new API.
On both Android and iOS, the new API matches the old API when high contrast is enabled through system settings

Screen.Recording.2025-03-12.at.5.02.11.AM.mp4

[facebook-github-bot]

@jorge-cab has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[Saadnajmi]

Hi @jorge-cab , is there anything I can do to help this PR land? I see it's failing some stuff internally, not sure if it's anything on my end

[jorge-cab]

Hi @jorge-cab , is there anything I can do to help this PR land? I see it's failing some stuff internally, not sure if it's anything on my end

Hey @Saadnajmi sorry I left you in the dark there for a bit. We are having some conversations internally about the direction in general we want to go with Accessibility APIs which also encompass this change.

We want to find a nice way to both unambiguously expose the subtleties of each platform and offer a unified abstraction. So ideally we offer both approaches in a systematic and explicit way about which part is platform dependent and which is crossplatform.

We have some work on Accessibility Hooks which might become the crossplatform solution in which case we might want to keep AccessibilityInfo clearly platform dependent but there's nothing set in stone yet.

Also these AccessibilityInfo APIs should be refactored to be synchronous to take advantage of the new architecture TM but we have to go for some workarounds since it would break backwards compatibility

I'll lyk as soon as possible what changes might be needed if any, sorry for the non-responsiveness