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

fix(tabs): allow bi-directional arrow key navigation in both orientations #3410

Merged
merged 3 commits into from
Jul 26, 2023

Conversation

TarunAdobe
Copy link
Contributor

@TarunAdobe TarunAdobe commented Jul 4, 2023

Description

Updated the logic to accept event code on arrow key press in TabGroup.ts allowing users to use both ArrowLeft and ArrowUp keys interchangeably (same for ArrowDown and ArrowRight)

Related issue(s)

fixes #3263

Motivation and context

Currently a screen reader user would have to guess the orientation to figure out which arrow keys will work to navigate to the next or previous Tab since we can't rely on screen readers announcing the tablist orientation.

How has this been tested?

  • Test case 1
    1. Go here
    2. Do this
  • Test case 2
    1. Go here
    2. Do this

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • If my change required a change to the documentation, I have updated the documentation in this pull request.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.

@TarunAdobe TarunAdobe added bug Something isn't working a11y Issues related to accessibility labels Jul 4, 2023
@TarunAdobe TarunAdobe self-assigned this Jul 4, 2023
@github-actions
Copy link

github-actions bot commented Jul 4, 2023

Tachometer results

Chrome

tabs permalink

Version Bytes Avg Time vs remote vs branch
npm latest 406 kB 274.05ms - 278.93ms - unsure 🔍
-1% - +1%
-3.68ms - +3.92ms
branch 407 kB 273.46ms - 279.29ms unsure 🔍
-1% - +1%
-3.92ms - +3.68ms
-

top-nav permalink

Version Bytes Avg Time vs remote vs branch
npm latest 410 kB 208.10ms - 213.14ms - unsure 🔍
-0% - +2%
-0.65ms - +5.10ms
branch 411 kB 207.01ms - 209.78ms unsure 🔍
-2% - +0%
-5.10ms - +0.65ms
-
Firefox

tabs permalink

Version Bytes Avg Time vs remote vs branch
npm latest 406 kB 391.50ms - 424.82ms - unsure 🔍
-4% - +6%
-16.36ms - +22.84ms
branch 407 kB 394.61ms - 415.23ms unsure 🔍
-6% - +4%
-22.84ms - +16.36ms
-

top-nav permalink

Version Bytes Avg Time vs remote vs branch
npm latest 410 kB 289.17ms - 318.59ms - unsure 🔍
-6% - +6%
-17.28ms - +19.60ms
branch 411 kB 291.59ms - 313.85ms unsure 🔍
-6% - +6%
-19.60ms - +17.28ms
-

@Rajdeepc
Copy link
Contributor

Rajdeepc commented Jul 4, 2023

@TarunAdobe Please check the tests on Tabs. I think these are failing because of your changes.

Copy link
Contributor

@Westbrook Westbrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which ever path we take, you additional tests should help support that decision, so nice addition there!

Comment on lines 233 to 235
return code.startsWith('Arrow');
case 'vertical':
return code === 'ArrowUp' || code === 'ArrowDown';
return code.startsWith('Arrow');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the conversation in the issue this stems from, I'm still not sure we want to flatten ALL usage of this controller or if we want to just leverage both in Tabs, so that it can be accurately supported. Can you take a look at leveraging that instead?

If really nothing should be horizontal or vertical, then that's another question. Do we auto fallback to both like this? And then use Dev Mode warnings to clarify why the functionality isn't what might be expected by the input, or do we leave horizontal and vertical as is, change all of our consumption to both, and then Dev Mode warn that horizontal and vertical may not deliver the expected screen reader/keyboard experience.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is actually a good point to consider here... I feel though that this should apply to pretty much all the components leveraging the controller right (not just Tabs) as the functionality we are expecting should be consistent? But sure I can try to leverage the both functionality in just the tabs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Westbrook Based on the conversation in issue should I make the changes such that this functionality of using both Down/RightArrow and Up/LeftArrow works specifically with tablist only... I'd start by removing the changes from FocusGroup.ts. Let me know if that makes sense?

@TarunAdobe TarunAdobe requested a review from Westbrook July 25, 2023 05:38
@Westbrook Westbrook force-pushed the bug/screen-readers-orientation branch from f09c016 to 7c7c595 Compare July 26, 2023 01:16
Copy link
Contributor

@Westbrook Westbrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for simplifying this! We'll get down to the real guts of this change with the a11y team later.

@Westbrook Westbrook changed the title fix: refactored FocusGroup to improved tab navigation accessibility for screen readers fix(tabs): allow bi-directional arrow key navigation in both orientations Jul 26, 2023
@Westbrook Westbrook merged commit ea10049 into main Jul 26, 2023
@Westbrook Westbrook deleted the bug/screen-readers-orientation branch July 26, 2023 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y Issues related to accessibility bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug][a11y]: Screen reader users perceive no distinction between horizontal and vertical orientation
3 participants