-
Notifications
You must be signed in to change notification settings - Fork 206
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
Conversation
Tachometer resultsChrometabs permalink
top-nav permalink
Firefoxtabs permalink
top-nav permalink
|
@TarunAdobe Please check the tests on Tabs. I think these are failing because of your changes. |
There was a problem hiding this 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!
return code.startsWith('Arrow'); | ||
case 'vertical': | ||
return code === 'ArrowUp' || code === 'ArrowDown'; | ||
return code.startsWith('Arrow'); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
f09c016
to
7c7c595
Compare
There was a problem hiding this 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.
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?
Screenshots (if appropriate)
Types of changes
Checklist
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
.