Proposal for various cross platform a11y improvements. #56

marcmulcahy · 2018-11-15T21:43:00Z

This proposal describes various cross platform improvements supported by most platforms.

necolas

Happy to see others thinking about how to add more accessibility features. I've been coming at this same problem from the perspective of web, where there are perhaps greater constraints on what is possible in some cases, and clearer standards in others.

necolas · 2018-11-16T19:51:09Z

proposals/0000-a11y-cross-platform.md

+Properties only available on iOS include:
+
+* accessibilityViewIsModal
+* accessibilityElementsHidden


This is similar to Android importantForAccessibility prop. It would be good to consolidate these together and learn from how web handles these cases

Perhaps something like ARIA hiden would be adequate. Android's importantForAccessibility is a bad model to emulate-- it includes yes, no, and auto as values. Auto is the default I believe, and from the developer's point of view, is hard to use, since the rules for when something is automatically marked as unimportant for accessibility aren't clear. I think a better model is to assume everything is important for accessibility, unless explicitly marked otherwise. So it seems like some notion of hidden is adequate.

Do you think we should make accessibilityElementsHidden cross-platform? Mapping to aria-hidden on web and equivalent on Android?

necolas · 2018-11-16T19:51:19Z

proposals/0000-a11y-cross-platform.md

+
+Properties only available on Android include:
+
+* accessibilityLiveRegion


This is also available on web

We could standardize on ARIA's notion of a live region, and then dumb down the implementation to the various platforms. Android's notion of a live region is pretty basic (polite or assertive). iOS has no notion of live regions as far as I know, so we'd have to use iOS primitives to implement a subset of live region functionality.

accessibilityLiveRegion is essentially already identical to ARIA live region, there's just a different in what the none state is called. So you could extend support for the existing API to iOS and then we'll have the 3 main platforms covered.

+1 on the accessibilityLiveRegion property being more universal. We just implemented this for Windows (see PR here).

+1 for accessibilityLiveRegion on iOS

necolas · 2018-11-16T19:53:14Z

proposals/0000-a11y-cross-platform.md

+Several properties are missing from both platforms:
+
+* accessibilityCompoundComponent: replace accessible-- indicates to assistive technologies that all the components inside this one should be treated as a single component.
+* accessibilityRelationships: describes how this component is related to others


I have a proposal internally that is based on Web's ARIA properties: accessibilityLabelID (equivalent to aria-labelledby), accessibilityDescriptionID (equivalent to aria-describedby), and accessibilityFocusID (equivalent to aria-activedescendent). All these props would take the value of the nativeID of the element they are associated with.

Makes sense. From naming point of view, are you in favor of using the ARIA namespace, or creating our own properties based on ARIA?

What do you mean by "ARIA namespace"? Something like accessibilityLabelledBy vs accessibilityLabelID?

necolas · 2018-11-16T19:54:07Z

proposals/0000-a11y-cross-platform.md

+
+* accessibilityCompoundComponent: replace accessible-- indicates to assistive technologies that all the components inside this one should be treated as a single component.
+* accessibilityRelationships: describes how this component is related to others
+* accessibilityRange: expose information about range-based components such as sliders


I think we can probably learn from web here and expose the range props to the underlying accessibility layer of the platform. Or model this off ARIA props for progressbar etc

We've found that in practice, exposing range information in a consumable way is fairly difficult. Exposing a minimum, current, and maximum value allow you to speak a percentage, which is fine for some types of progress bars. But for others, where the actual value is relevant (say a color contrast setting, stereo balance control, movie timeline slider, etc.) it would be nice to include some information that could cause the screen reader to speak either a string or the current value instead of a percentage. Slider's also imply programatic actions to adjust them.

But for others, where the actual value is relevant (say a color contrast setting, stereo balance control, movie timeline slider, etc.) it would be nice to include some information that could cause the screen reader to speak either a string or the current value instead of a percentage.

ARIA has a property for that aria-valuetext - https://www.w3.org/TR/wai-aria-practices/examples/slider/slider-2.html

I do like how understandable and extensible the accessibilityRelationships and accessibilityRange props names are vs having many more individual props ARIA.

Are you thinking it would look something like this (property names tbh for relationships)?

<View accessibilityRange={{ min, max, current, text }} accessibilityRelationships={{ labelID, descriptionID, focusID }} />

necolas · 2018-11-16T19:55:54Z

proposals/0000-a11y-cross-platform.md

+
+### accessibilityCompoundComponent
+
+We think the current implementation, which is called "accessible", should be renamed to accessibilityCompoundComponent, to more accurately represent what it does. The functionality should remain the same.


The behaviour of accessible has always felt a bit ambiguous to me, as on Android and Web it's equivalent to focusable. I don't think accessibilityCompoundComponent is any clearer a name than accessible

I think the whole notion of compound component handling needs quite a bit more thought. My main opposition to calling this accessible is that it's misleading-- it has little to do with whether the component is accessible, and almost everything to do with how assistive technologies should treat the component.

Maybe I should drop this from this proposal, and make a separate proposal covering compound component handling? I'm thinking as a start about containers with multiple children, which we want to treat as a single item, but depending on the container layout, perhaps only one child is clickable and should be manipulated when the screen reader double taps, etc.

Maybe I should drop this from this proposal, and make a separate proposal covering compound component handling?

I think that sounds good. The idea of an accessibility group is something that's a little complicated on web too, because you have both screen-reader accessibility and keyboard accessibility.

necolas · 2018-11-16T19:56:13Z

proposals/0000-a11y-cross-platform.md

+* labeledBy: this component is labeled by the specified component
+* describedBy: this component is described by the specified components.
+
+When referring to other components, we may need to add an additional property to view-- namely accessibilityId. We need to find the best forward-looking approach for referencing other components.


We already have nativeID that we can use for this

Great, when was this nativeID property introduced? Trying to understand backward compatibility.

Looks like it was introduced for both platforms here in June 2017 facebook/react-native@70e0455

necolas · 2018-11-16T19:57:14Z

proposals/0000-a11y-cross-platform.md

+
+We think the current implementation, which is called "accessible", should be renamed to accessibilityCompoundComponent, to more accurately represent what it does. The functionality should remain the same.
+
+### accessibilityRelationships


What does this API look like in practice? Is the value an object?

If you're referring to compound component handling, I think the answer is yes. perhaps a separate proposal would let us discuss and flesh out exactly how to do this.

Relationships could be an object, or each relationship could be a separate property. We've found it sometimes useful for a relationship to include multiple targets-- for example, cases where multiple components describe a single component.

necolas · 2018-11-16T21:48:57Z

For context, Twitter uses React Native to implement their PWA. The RN abstractions (which have web DNA) are considerably better for building modern web apps that straight DOM abstractions. However, Twitter relies on an undocumented feature of React Native for Web that passes aria-* props to the underlying DOM node to work around the missing accessibility features in React Native. Your proposals cover almost exactly the same problems that Twitter has from a web context and that I started bringing up at Facebook. So I'm really happy to see that Amazon is interested in improving the native accessibility story and would like to help make sure that the API maps cleanly to the web's comprehensive accessibility features (which influenced the introduction of accessibilityRole and accessibilityStates).

necolas · 2018-12-06T22:16:32Z

proposals/0000-a11y-cross-platform.md

+Properties only available on iOS include:
+
+* accessibilityViewIsModal
+* accessibilityElementsHidden


Do you think we should make accessibilityElementsHidden cross-platform? Mapping to aria-hidden on web and equivalent on Android?

necolas · 2018-12-06T22:18:07Z

proposals/0000-a11y-cross-platform.md

+
+Properties only available on Android include:
+
+* accessibilityLiveRegion


accessibilityLiveRegion is essentially already identical to ARIA live region, there's just a different in what the none state is called. So you could extend support for the existing API to iOS and then we'll have the 3 main platforms covered.

necolas · 2018-12-06T22:22:52Z

proposals/0000-a11y-cross-platform.md

+Several properties are missing from both platforms:
+
+* accessibilityCompoundComponent: replace accessible-- indicates to assistive technologies that all the components inside this one should be treated as a single component.
+* accessibilityRelationships: describes how this component is related to others


What do you mean by "ARIA namespace"? Something like accessibilityLabelledBy vs accessibilityLabelID?

necolas · 2018-12-06T22:29:23Z

proposals/0000-a11y-cross-platform.md

+
+* accessibilityCompoundComponent: replace accessible-- indicates to assistive technologies that all the components inside this one should be treated as a single component.
+* accessibilityRelationships: describes how this component is related to others
+* accessibilityRange: expose information about range-based components such as sliders


But for others, where the actual value is relevant (say a color contrast setting, stereo balance control, movie timeline slider, etc.) it would be nice to include some information that could cause the screen reader to speak either a string or the current value instead of a percentage.

ARIA has a property for that aria-valuetext - https://www.w3.org/TR/wai-aria-practices/examples/slider/slider-2.html

I do like how understandable and extensible the accessibilityRelationships and accessibilityRange props names are vs having many more individual props ARIA.

Are you thinking it would look something like this (property names tbh for relationships)?

<View accessibilityRange={{ min, max, current, text }} accessibilityRelationships={{ labelID, descriptionID, focusID }} />

necolas · 2018-12-06T22:30:01Z

proposals/0000-a11y-cross-platform.md

+
+## Motivation
+
+All accessibility properties should be available on all supported platforms. This reduces the burden on developers to understand the nuances of accessibility support on various platforms. It also allows JavaScript components to expose rich accessibility information, rather than relying on the accessibility support in native components.


necolas · 2018-12-06T22:35:24Z

proposals/0000-a11y-cross-platform.md

+
+### accessibilityCompoundComponent
+
+We think the current implementation, which is called "accessible", should be renamed to accessibilityCompoundComponent, to more accurately represent what it does. The functionality should remain the same.


Maybe I should drop this from this proposal, and make a separate proposal covering compound component handling?

I think that sounds good. The idea of an accessibility group is something that's a little complicated on web too, because you have both screen-reader accessibility and keyboard accessibility.

necolas · 2018-12-06T22:38:07Z

proposals/0000-a11y-cross-platform.md

+* labeledBy: this component is labeled by the specified component
+* describedBy: this component is described by the specified components.
+
+When referring to other components, we may need to add an additional property to view-- namely accessibilityId. We need to find the best forward-looking approach for referencing other components.


Looks like it was introduced for both platforms here in June 2017 facebook/react-native@70e0455

necolas · 2018-12-06T22:40:37Z

proposals/0000-a11y-cross-platform.md

+
+This property describes how this component is related to others. Relationship types include:
+
+* labelFor: This component labels the specified component


Is there a use-case you had in mind for having the relationship be defined in either direction like this?

necolas · 2018-12-07T03:45:55Z

proposals/0000-a11y-cross-platform.md

+
+The same documentation that is used to describe the properties on either iOS or Android can be marked as cross-platform for use on either. For the accessibilityRelationships property, labeledBy and labelFor are common paradigms across accessibility support on multiple platforms including web.
+
+## Unresolved questions


I have a related question (and issue) about content that is hidden visually but visible to screen readers. Typically it will be hidden headings so they show up in the screen reader headings list (e.g., mobile.twitter.com does this) and it is visually hidden with a particular CSS incantation. Would you / how would you do something like this in native apps?

Maybe something like this?

import React, { useEffect, useState } from 'react'; import { AccessibilityInfo, Text } from 'react-native'; const useIsScreenReaderEnabled = () => { const [isScreenReaderEnabled, setIsScreenReaderEnabled] = useState(false); useEffect(() => { AccessibilityInfo.addEventListener('screenReaderChanged', setIsScreenReaderEnabled); AccessibilityInfo.isScreenReaderEnabled().then(setIsScreenReaderEnabled); return () => AccessibilityInfo.removeEventListener('screenReaderChanged', setIsScreenReaderEnabled); }, []); return isScreenReaderEnabled; }; const Example = () => { const isScreenReaderEnabled = useIsScreenReaderEnabled(); return <Text>I {isScreenReaderEnabled ? 'love' : '❤️'} React Native for Web</Text>; };

necolas · 2023-06-05T18:22:44Z

I'm going to close this proposal as we've subsequently focused on cross-platform APIs based on the existing ARIA spec as per #496

Proposal for various cross platform a11y improvements.

7f6fe5f

kelset added the 💡 Proposal This label identifies a proposal label Nov 16, 2018

necolas reviewed Nov 16, 2018

View reviewed changes

necolas mentioned this pull request Nov 16, 2018

Accessibility: working with ARIA labelledby and describedby properties necolas/react-native-web#1116

Closed

necolas reviewed Dec 6, 2018

View reviewed changes

necolas reviewed Dec 7, 2018

View reviewed changes

necolas mentioned this pull request Dec 20, 2018

Screenreader-only text necolas/react-native-web#1181

Closed

estevaolucas mentioned this pull request Feb 11, 2019

☂️ Lean Core facebook/react-native#23313

Closed

64 tasks

necolas closed this Jun 5, 2023


		Properties only available on Android include:

		* accessibilityLiveRegion


		### accessibilityCompoundComponent

		We think the current implementation, which is called "accessible", should be renamed to accessibilityCompoundComponent, to more accurately represent what it does. The functionality should remain the same.


		We think the current implementation, which is called "accessible", should be renamed to accessibilityCompoundComponent, to more accurately represent what it does. The functionality should remain the same.

		### accessibilityRelationships


		## Motivation

		All accessibility properties should be available on all supported platforms. This reduces the burden on developers to understand the nuances of accessibility support on various platforms. It also allows JavaScript components to expose rich accessibility information, rather than relying on the accessibility support in native components.


		This property describes how this component is related to others. Relationship types include:

		* labelFor: This component labels the specified component


		The same documentation that is used to describe the properties on either iOS or Android can be marked as cross-platform for use on either. For the accessibilityRelationships property, labeledBy and labelFor are common paradigms across accessibility support on multiple platforms including web.

		## Unresolved questions

Proposal for various cross platform a11y improvements. #56

Proposal for various cross platform a11y improvements. #56

Conversation

marcmulcahy commented Nov 15, 2018

necolas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

necolas commented Nov 16, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

necolas commented Jun 5, 2023