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

Issues with arrows and selecting with VoiceOver (Sequoia and Sonoma MacOS) #2589

Closed
iseatz-zgoodwin opened this issue Nov 15, 2024 · 5 comments · Fixed by #2609
Closed

Issues with arrows and selecting with VoiceOver (Sequoia and Sonoma MacOS) #2589

iseatz-zgoodwin opened this issue Nov 15, 2024 · 5 comments · Fixed by #2609
Assignees

Comments

@iseatz-zgoodwin
Copy link

Steps to reproduce

Steps:

  1. Test on this page (version 9.3.0): https://daypicker.dev/guides/accessibility
  2. Use Mac with Sonoma/Sequoia OS
  3. Use Safari/Chrome/Edge/Firefox browsers
  4. Turn VoiceOver
  5. TAB into calendar box (observe that first date is on focus)
  6. Then use either arrow down/up/left/right or Ctrl + Option + Arrow down/up/left/right
  7. Observe how arrows work (pay attention where they land and how focus works)
  8. Press ENTER
  9. Observe how selection doesn't work

Current behavior

We noticed that on our proprietary apps date pickers no longer properly work with VoiceOver but only on Sonoma and Seqouia MacOS (works fine on Ventura OS). On all browsers ENTER/SPACE doesn't select the correct date - selection is always on what TAB landed on. However, now only Control + Option + SPACE/ENTER selects, while in the past only ENTER/SPACE was enough. And also issues with regular arrow buttons.

With VoiceOver if using regular arrows, only arrow left/right works, but not arrow up/down, however, Ctrl + Option + Arrow up/down/left/right works fine for moving the cells. Technically, both options should work.

Similarly, on iPhone + VoiceOver, only swiping right/left makes cells move left right, but swiping up/down doesn't make cells move up/down. The good news tapping twice to select - works, so no major concerns with VoiceOver on phones.

I additionally tested this date picker with NVDA/JAWS 2024/JAWS 2025 on Windows 10 on Edge/Chrome/Firefox and there were no issues with those combinations. JAWS performed the best: no issues using arrows or ENTER. On NVDA odd discrepancy that arrow up/down moves left/right and arrow left/right reads letters one by one (but doesn't move the cells), however, since it's a table, using Ctrl + Alt + arrow up/down/left/right was no issue.

Video:
https://drive.google.com/file/d/10dS8cwHG_U0gmXer4JGXyy4dzkjZAUBs/view?usp=sharing

Expected behavior

VoiceOver users are used to use regular arrows and ENTER/SPACE without Control + Option as it works in earlier versions (for example, Ventura OS) so usability should not change.

Context

It is hard to say if it's Apple issue or library issue, but it's a 50/50 possibility. However, this could raise issues with violating WCAG 2.0/2.1/2.2 Level A SC 4.1.2 (Compatibility) due to usability inconsistency.

Your environment

Computer:
MacBook Pro, Apple M1 Max, 15.1 (24B83)

Phone:
iPhone 14 Pro, iOS 18.1

Browsers:
Safari Version 18.1 (20619.2.8.11.10)
Chrome Version 130.0.6723.117 (Official Build) (arm64)
Edge Version 130.0.2849.80 (Official build) (arm64)
Firefox Version 132.0.2 (aarch64)

@gpbl gpbl changed the title [accessibility] [VoiceOver] Issues with arrows and selecting with VoiceOver (Sequoia and Sonoma MacOS) Issues with arrows and selecting with VoiceOver (Sequoia and Sonoma MacOS) Nov 15, 2024
@gpbl
Copy link
Owner

gpbl commented Nov 15, 2024

Interesting, thanks for the detailed report. This issue may be introduced by #2475 in v9.1.2, where we removed unnecessarily role attributes.

@gpbl gpbl self-assigned this Nov 16, 2024
@gpbl
Copy link
Owner

gpbl commented Nov 16, 2024

I understand that there might be some issues with VoiceOver and keyboard navigation. This is likely because VoiceOver gets confused by the cell attributes (aria-selected, etc.) and the button it contains.

In your video, it appears that when navigating with the VoiceOver Rotor, the cells and the grid are navigable using the keyboard, but for some reason, the button inside the cell is ignored, so no selection can be made.

One possible solution to fix this issue could be to remove the button from the grid cells. This means using <div role="gridcell"> as the “button".

However, there are a couple of potential issues with this approach:

  • It may be challenging to ensure that both VoiceOver and the HTML validator are happy with the changes. The HTML validator seems to have strict rules regarding the role property, so it’s important to verify that the changes comply with these rules.
  • Any changes to the HTML tree could potentially break existing implementations, which could result in a major version release.

The goal is to get VoiceOver to work with the current HTML layout. I’ve tried playing with the onFocus event over the cell, but I haven’t been able to make significant progress. I also noticed that laying out the grid using role="gridcell" directly on the button makes the VoiceOver navigation work smoother.

Additionally, it seems that the ArrowUp and ArrowDown keys are not working as expected. They navigate to the previous and next days instead of the week.

@iseatz-zgoodwin, are you available to help me test the possible fixes here?

@iseatz-zgoodwin
Copy link
Author

@gpbl Thank you for reporting back, I will gladly help out to test (with Sequoia OS + VO specifically and other screen readers if needed).

@gpbl gpbl linked a pull request Nov 30, 2024 that will close this issue
@gpbl
Copy link
Owner

gpbl commented Nov 30, 2024

@iseatz-zgoodwin v9.4.1 includes some fixes that address the VoiceOver navigation issue Thank you very much for your report.

Please let me know if you encounter any other issues.

@gpbl gpbl closed this as completed Nov 30, 2024
@iseatz-zgoodwin
Copy link
Author

@gpbl Thank you for fixing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants