Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to move TalkBack cursor on Modal component #7471

Open
warsawgentleman opened this issue Dec 4, 2024 · 3 comments · May be fixed by #7478
Open

Unable to move TalkBack cursor on Modal component #7471

warsawgentleman opened this issue Dec 4, 2024 · 3 comments · May be fixed by #7478
Assignees
Labels
accessibility browser bug bug Something isn't working

Comments

@warsawgentleman
Copy link
Contributor

warsawgentleman commented Dec 4, 2024

Provide a general summary of the issue here

When Modal is opened via TalkBack I am unable to change cursor position by swiping left or right. The cursor always comes back to the first focusable element. The flow works perfectly on VoiceOver (macOS).

🤔 Expected Behavior?

I should be able to navigate the elements inside Modal by swiping left or right.

😯 Current Behavior

TalkBack cursor is blocked on the first element.

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

The bug is visible in Modal's documentation - https://react-spectrum.adobe.com/react-aria/Modal.html.

  1. Turn on TalkBack
  2. Go to https://react-spectrum.adobe.com/react-aria/Modal.html
  3. Select "Sign up..." button and double tap to open it
  4. The first input is selected
  5. Swipe right to select the next input
  6. TalkBack cursor isn't changed

Version

1.5.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

Android 14. TalkBack 14.1, Chrome

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

@LFDanLu
Copy link
Member

LFDanLu commented Dec 4, 2024

Thanks for reporting this, verified locally, digging to see when it started happening.

@LFDanLu
Copy link
Member

LFDanLu commented Dec 5, 2024

Looks to be something in our FocusScope:

raf.current = requestAnimationFrame(() => {
// Use document.activeElement instead of e.relatedTarget so we can tell if user clicked into iframe
if (ownerDocument.activeElement && shouldContainFocus(scopeRef) && !isElementInChildScope(ownerDocument.activeElement, scopeRef)) {

where the activeElement is now returning the document body after the RAF instead of the newly focused input element after the swipe operation. Replacing this with e.relatedTarget seems to work just fine, I can't seem to reproduce the original issue in Firefox even with the updated change

@LFDanLu LFDanLu linked a pull request Dec 5, 2024 that will close this issue
5 tasks
@LFDanLu
Copy link
Member

LFDanLu commented Dec 18, 2024

The fix above actually breaks another use case of ours since we still do want to coerce focus back to the Modal if focus is genuinely lost to the body but there isn't a great to differentiate that any longer for Talkback it seems. I've filed a bug against Chrome via https://issuetracker.google.com/issues/384844019 to see if they can shed any light as to what may have changed as of late, currently digging to see if there are any alternative paths here.

@LFDanLu LFDanLu added bug Something isn't working accessibility browser bug labels Dec 18, 2024
@LFDanLu LFDanLu moved this from 🩺 To Triage to 👀 In Review in RSP Component Milestones Dec 19, 2024
@LFDanLu LFDanLu self-assigned this Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility browser bug bug Something isn't working
Projects
Status: 👀 In Review
Development

Successfully merging a pull request may close this issue.

2 participants