Accessibility Behavior

Methods of testing:

• iOS: using Accessibility Inspector (in iOS mode!) on iOS simulator
• Android: using TalkBack on Android emulator

<Text> component

<Text> behavior in iOS

Component	Screen reader	Label	Value	Traits	Identifier	Hint	User Input Label
<Text>Hello!</Text>	Hello!	Hello !	(none)	Static Text	(none)	(none)	Hello !
accessible={true} accessibilityRole="text"	Hello!	Hello !	(none)	Static Text	(none)	(none)	Hello !
accessible={true}	Hello!	Hello !	(none)	Static Text	(none)	(none)	Hello !
accessible={false}	(ignored)	(ignored)	(ignored)	(ignored)	(ignored)	(ignored)	(ignored)
accessibilityRole="text"	Hello!	Hello !	(none)	Static Text	(none)	(none)	Hello !
accessibilityRole="none"	Hello!	Hello !	(none)	(none)	(none)	(none)	Hello !

Findings:

• iOS behaves the same for when accessible={true} or when prop is not specified
• iOS behaves the same for when accessibilityRole="text" or when prop is not specified
• iOS ignores element when accessible={false}
• changing accessibilityRole to "none" removes Static Text trait, but view is still readable by screen reader

<Text> behavior in Android

Component	Screen reader
<Text >Hello!</Text>	Hello!
accessible={true} accessibilityRole="text"	Hello!
accessible={true}	Hello!
accessible={false}	Hello!
accessibilityRole="text"	Hello!
accessibilityRole="none"	Hello!
importantForAccessibility="no"	(ignored)
importantForAccessibility="no-hide-descendants"	(ignored)

Findings:

• Android accessible props does not affect TalkBack screen reader behaviour
• Android accessibilityRole props does not affect TalkBack screen reader behaviour
• Android ignores element if importantForAccessibility value "no" or "no-hide-descendants"

<Text> handling recommendations

• assume default accessible value of true
• assume default accessibilityRole of text
• assume no role when accessible={false} or accessibilityRole="none" (based on iOS semantics)
• assume no role when importantForAccessibility="no" or importantForAccessibility="no-hide-descendants" (based on Android semantics)

<TextInput> component

<TextInput> behavior in iOS

Component	Screen reader	Label	Value	Traits	Identifier	Hint	User Input Label
<TextInput defaultValue="Hello" />	Hello	(none)	Hello	(empty)	(none)	(none)	Hello
accessible={true}	Hello	(none)	Hello	(empty)	(none)	(none)	Hello
accessible={false}	Hello	(none)	Hello	(empty)	(none)	(none)	Hello
accessibilityRole="search	Hello - search field	(none)	Hello	Search Field	(none)	(none)	Search Field
accessibilityRole="none"	Hello	(none)	Hello	(empty)	(none)	(none)	Hello
`editable={false}	Hello - not enabled	(none)	Hello	Not enabled	(none)	(none)	Hello

Findings:

• iOS ignores accessible={false} attribute, it behaves the same as default and true value
• iOS ignores accessibilityRole="none" the elements behaves the same as without role attribute
• iOS reacts to accessibilityRole="search" by reading the "serach field" trait name
• iOS reacts to editable={false} by reading the "not enabled" trait name