Talkback double announcement when using accessibilityRole={'header'}

[JCron245]

Please provide all the information requested. Issues that do not follow this format are likely to stall.

Description

For whatever reason when attaching accessibilityRole={'header'} to an element it is announcing 'heading' twice with TalkBack on. Testing the same component on iOS using VoiceOver achieves the expected result of it only announcing once.

React Native version:

61.4

Steps To Reproduce

Provide a detailed list of steps that reproduce the issue.

1. Create some sort of component with 'accessibilityRole={'header'}`
2. Test on iOS and Android

Expected Results

Talkback should announce 'header' only once when using TalkBack like it does with VoiceOver.

Snack, code example, screenshot, or link to a repository:

https://snack.expo.io/@jcron/accessibility-role-double-announce

[JCron245]

Just as additional info I tested the above snack with the following devices:

iPhone X [iOS v13.4] - Works as expected
iPhone XS [iOS v13.5-b3] - Works as expected
iPad Mini 2 [iOS v12.4.5] - Works as expected
NVIDIA Shield Tablet [Android 7.0] - Announces 'heading' Twice
Galaxy Tab 10 [Android 8.1.0] - Announces 'heading' Twice
Moto E5 [Android 8.1.0] - Announces 'heading' Twice

[AnnieFisher]

*** Note :
When you do NOT apply an accessible label it announces "heading {Text} heading".
Not sure why this is or if it is even useful, just additional information.

[dotjay]

Another test result:
Motorola One Macro XT2016-1 [Android 9.0] - TalkBack announces 'heading' Twice

[heisenbugged]

This has been fixed in v0.63.1:
7428271

[elfstyle]

Just updated from RN 62.2 to 63.4 and accessibilityRole='header' doesn't work anymore. Does anyone experience the same issue?

[nico22utn]

Just updated from RN 62.2 to 63.4 and accessibilityRole='header' doesn't work anymore. Does anyone experience the same issue?

Yes! I have the same issue for Samsung s10e. It works as expected on any IOS device.

[amarlette]

@blavalla has not been able to reproduce this issue on the current RN version. Was this issue resolved by updates since the issue was created?

[arsimr16]

Just updated from RN 62.2 to 63.4 and accessibilityRole='header' doesn't work anymore. Does anyone experience the same issue?

I'm using a fork of react-native based on 61.4. I applied the change which @babylone-star said was added in 63.1.

This bug was reported after my app was tested for accessibility on a Pixel 4XL, but I could not reproduce it on the only testing phone I have, a Samsung Galaxy S8. Someone else tested this for me on a Razor Phone 2 and was able to reproduce the error. So it seems like the header role was announced once on Samsung phones and twice on other phones.

After applying this change, I don't hear the role announced at all on my Samsung device. I suspect the role will now be announced once on the Pixel 4XL and Razor Phone 2.

[blavalla]

@arsimr16, this one may actually be caused by a difference in Talkback or Android versions between devices as well, or could possibly be caused by Samsung's own fork of Talkback that they use.

For what it's worth, I wasn't able to reproduce this on a Samsung Galaxy S20 or a Pixel 5. Both were running Android 11 however, and the latest versions of Talkback (Samsung's is technically a fork, but it's a new fork that should be up to date with Google's implementation).

This was the link used to test: https://snack.expo.io/7tjnjlJbO

On a technical note, the "header" role in RN right now is mapping to the older-style of heading that was only allowed within collection structures in Android (lists, grids, etc.). This works on both older and newer OS and Talkback versions (assuming your element is in a list), but starting in Android 9, Google added a more general-purpose API for headings.

Since you are already working with a fork of RN, one thing to try would be to update this to the newer-style of API to see if it works to resolve the issue. It will limit support down to only API 28 and above (Android 9) or API 19 and above (Android 4.4.) if using the AndroidX compat library.

To do that, you'll want to change these lines:

react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/ReactAccessibilityDelegate.java

Lines 398 to 400 in dfa8eb0

	final AccessibilityNodeInfoCompat.CollectionItemInfoCompat itemInfo =
	AccessibilityNodeInfoCompat.CollectionItemInfoCompat.obtain(0, 1, 0, 1, true);
	nodeInfo.setCollectionItemInfo(itemInfo);

To this:

nodeInfo.setHeading(true)

@kacieb, what is the lowest version of Android that React Native currently supports? If it's above 19, we may want to just switch to use the newer API here.

[arsimr16]

Thanks for the explanation. I switched to the newer API (I'm using AndroidX) and I still don't hear the header role being announced on my Samsung Galaxy S8 running Android 9.

[blavalla]

@arsimr16, just to confirm here. Are you using Google's Talkback (installed from the Play Store), or Samsung's Voice Assistant (comes pre-installed). Voice Assistant was quite an old fork of talkback, and may not have support for the header role.

If you're using Talkback, which version?

[arsimr16]

Thanks, I didn't know that. I was using the Samsung Voice Assistant. Let me try downloading Talkback.

[arsimr16]

Works with Talkback! Thanks so much :)

[kacieb]

@kacieb, what is the lowest version of Android that React Native currently supports? If it's above 19, we may want to just switch to use the newer API here.

That's a good idea. The minimum SDK version supported is 21 so we can switch to the newer API.

[anup690]

I had an issue with accessibilityRole="link", it's also announced twice like: " one link, link"
anyone had this issue and is it solved after the update?

[blavalla]

@anup690 , was this double-link announcement on iOS or Android? If Android, was it using Samsung's "Voice Assistant" or Google's "Talkback"?

If I had to guess, I'd say that this sounds like something that Samsung's Voice Assistant would do. Generally speaking, Voice Assistant tried to be a bit more like Apple's VoiceOver (which automatically announces "link" after links), and RN adding a roleDescription of "Link" may have doubled this up inadvertently. That's a random guess though, and since Samsung has deprecated Voice Assistant in favor of Talkback, I can't really verify it on any of my devices.

If you do have a repro case, see if commenting out this line fixes it:

react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/ReactAccessibilityDelegate.java

Line 375 in da899c0

nodeInfo.setRoleDescription(context.getString(R.string.link_description));

[anup690]

@blavalla you guessed it bang on, it is Samsung's Voice Assistant indeed, got my tester do away with android talkback, yes I recently learned that Voice Assistant is a fork of talkback and outdated,
and the links do read fine on the stock based ROMs (due to Talkback that is)

though with talkback, it reads, "link", "links available, use swipe up and right to view" for each link in the page not the best UX,
i'm checking if there is a way to polish that like "links available, use swipe up and right to view" to utter only once in a page full of links,
thanks for the help

[blavalla]

i'm checking if there is a way to polish that like "links available, use swipe up and right to view" to utter only once in a page full of links,

From an Android perspective, Talkback is doing this for each TextView that contains a ClickableSpan or URLSpan in its text.

From the RN side, whenever you set a link role on a component, we are under the hood creating a URLSpan and setting it as the full length of text on that component:

react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/ReactAccessibilityDelegate.java

Lines 377 to 387 in da899c0

	if (nodeInfo.getContentDescription() != null) {
	SpannableString spannable = new SpannableString(nodeInfo.getContentDescription());
	spannable.setSpan(new URLSpan(""), 0, spannable.length(), 0);
	nodeInfo.setContentDescription(spannable);
	}
	if (nodeInfo.getText() != null) {
	SpannableString spannable = new SpannableString(nodeInfo.getText());
	spannable.setSpan(new URLSpan(""), 0, spannable.length(), 0);
	nodeInfo.setText(spannable);
	}

This is definitely not a great experience currently, and I'm actually working right now to implement a better approach to link handling in general, where the links act more like they do on web surfaces and get focused on their own rather than being accessed via a dedicated menu.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.