[$250] State check/uncheck announced incorrectly with screen reader on checkbox and radio

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.15-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #81054
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: macOS Sonoma 14.5 / Chrome, Android 13 / Xiaomi Poco F5
App Component: Other

Action Performed:

Precondition:

• Screen reader VoiceOver/TalkBack is enabled.

1. Open https://staging.new.expensify.com/ and login
2. Navigate to Reports > Filters > Date dropdown
3. Try to check/uncheck the radio button
4. Navigate to Filters > Status dropdown
5. Try to check/uncheck the checkbox

Expected Result:

The state check/uncheck announced correctly with screen reader on Checkbox and Radio button

Actual Result:

The state check/uncheck announced incorrectly with screen reader on Checkbox and Radio button
Note:

• For the checkbox, the state is always announced as unchecked even though the checkbox is already checked.
• For the radio button, the state is not announced at all

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022021040076572289696
• Upwork Job ID: 2021040076572289696
• Last Price Increase: 2026-02-10

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #81054

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #81054 - "[Accessibility] Fix accessibility roles and states for radio buttons, checkboxes, and tabs" by @ashu75575 (High confidence)
Related Issues: #79240 (original accessibility tracking issue that PR #81054 attempted to fix)

Recommendation: ROLL FORWARD

The issue is caused by conflicting accessibility attributes creating nested roles. PR #81054 added accessibilityRole="checkbox" and accessibilityState={{checked: ...}} to the BaseListItem wrapper (PressableWithFeedback), but the actual Checkbox component inside already has its own role="checkbox" and aria-checked attributes. This causes screen readers to announce the outer wrapper's state instead of the inner Checkbox component's state.

A quick fix is simpler than reverting: We should NOT apply the checkbox/radio role to the BaseListItem wrapper when a rightHandSideComponent is provided (since that component handles its own accessibility). The fix would be a small conditional check in BaseListItem.

Labels: Keeping DeployBlockerCash as this is a Frontend bug that blocks the App deploy.

📋 Detailed Analysis

Evidence

PR #81054 was merged on 2026-02-04 and modified the accessibility implementation for selection lists. The issue was reported during QA testing of this same PR, confirming it as the causing change.

Root Cause

The problem is nested accessibility roles creating conflicts:

1. MultiSelectListItem creates a standalone Checkbox component:

   <Checkbox
       isChecked={item.isSelected}
       accessibilityLabel={item.text ?? ''} 
       onPress={() => onSelectRow(item)}
   />

   This Checkbox has role="checkbox" and aria-checked={isChecked} (see /home/runner/work/App/App/src/components/Checkbox.tsx line 133-137)

2. This Checkbox is passed as rightHandSideComponent to BaseListItem

3. BaseListItem wraps everything in PressableWithFeedback with:

   accessibilityRole={CONST.ROLE.CHECKBOX}  // ← Outer checkbox role
   accessibilityState={{checked: !!item.isSelected}}  // ← Outer checked state

4. Screen readers encounter TWO checkbox roles (outer wrapper + inner component) and read the outer wrapper's accessibilityState which may not sync properly with the inner Checkbox's aria-checked.

Why This Happened

The PR correctly identified that selection list items needed proper accessibility roles. However, it didn't account for cases where the rightHandSideComponent is already a semantic component (like Checkbox) with its own accessibility attributes.

Proposed Fix

In BaseListItem, only apply the checkbox/radio role when there's NO rightHandSideComponent, or when we're certain the right-hand component is not a semantic form control:

// Don't override role to checkbox/radio if rightHandSideComponent exists
// (it likely has its own accessibility already)
const shouldUseSemanticRole = !rightHandSideComponent && (canSelectMultiple || /* radio condition */);
const accessibilityRole = shouldUseSemanticRole ? determinedRole : getButtonRole(true);

This is a smaller, safer change than reverting the entire PR, which made other valid improvements to tab accessibility.