Closed FalseLobster closed 6 months ago
An aside, we'll want to eventually also implement for Fabric, but not blocking for 0.73
Q: Would it make sense for our main
branch version of the PR to use the aria mappings for the accessibilityRole slot, rather than the legacy mappings we defined? I I can imagine we keep the legacy mappings for one version (0.73) and disable it in the next (0.74). Alternatively, maybe put it behind a Feature flag via this JS file or this native file ?
Q: Would it make sense for our
main
branch version of the PR to use the aria mappings for the accessibilityRole slot, rather than the legacy mappings we defined? I I can imagine we keep the legacy mappings for one version (0.73) and disable it in the next (0.74). Alternatively, maybe put it behind a Feature flag via this JS file or this native file ?
Maybe, I'm open to it. I kinda suspect at some point Meta will drop accessibilityRole like they did accessibilityTraits (even though our impl still has accessibilityTraits). I think we run the risk internally of breaking partners who are using accessibilityRole if we silently change some mappings for them, whereas only applying the new mappings to the new values to the new prop feels safe, which is worth considering, but I suppose that's why you're calling out the feature flag :)
Summary:
Prior to 0.73, the new
role
prop was remapped toaccessibilityRole
on the JS-side. Starting with #37304, the work needs to be completed on the native side. Since the new prop is ARIA inspired, the mappings are taking from the ARIA Core AAM which disagrees with some of the mappings used in the oldaccessibilityRole
prop. Users of the old prop are unaffected, but the new prop will take the mappings from the spec.Test Plan:
Tested a variety of permutations of accessibilityRole and role to confirm the behavior looks correct in Accessibility Inspector