mattinger
10/15/2026, 6:22 PMtestTagsAsResourceId doesn't actually expose the accessibility property for the viewIdResourceName. The only aternative i've seen suggested is selecting by text or content description, which isn't ideal as that changes from language to language.Preetam
10/15/2026, 7:38 PMNavigationBarItem (and several other M3 components) merges and clears semantics internally, which causes Compose's platform accessibility bridge to drop testTagsAsResourceId from the OS-level AccessibilityNodeInfo. Since Appium only sees the external OS accessibility tree, it forces you into matching localized text or content descriptions.
I built Parikshan (github.com/aryapreetam/parikshan) to solve this exact issue.
Instead of relying on OS accessibility exports and testTagsAsResourceId, Parikshan interacts directly with Compose's internal unmerged semantics tree (useUnmergedTree = true). Any Modifier.testTag(...) you set on NavigationBarItem works natively without depending on locale-specific text:
e2eTest {
click(tag("nav_profile"))
assertVisible(tag("profile_screen"))
}
It also runs the exact same test suite across Android, iOS, Desktop, and Web. Happy to help if you'd like to try it out or need a quick setup sample for your navigation bar.mattinger
10/16/2026, 1:09 PMmattinger
10/16/2026, 1:11 PMPreetam
10/16/2026, 8:32 PMBox(Modifier.semantics { testTagsAsResourceId = true }.testTag("nav_item_home")) {
NavigationBarItem(...)
}
It's a bit of a layout smell, but because the Box sits above NavigationBarItem in the tree, Compose exposes the viewIdResourceName on its accessibility node before M3's internal semantics clearing takes over.
And yeah, completely agreed on M3—Google has had an open ticket on this exact clearAndSetSemantics behavior breaking accessibility tools for a while: issuetracker.google.com/issues/304199047