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

Calendar keyboard navigation accessibility #6275

Closed
damyanpetev opened this issue Dec 3, 2019 · 6 comments · Fixed by #8314
Closed

Calendar keyboard navigation accessibility #6275

damyanpetev opened this issue Dec 3, 2019 · 6 comments · Fixed by #8314
Assignees
Labels
📆 calendar 📈 enhancement keyboard-navigation ♿ a11y When the issue or PR is related to accessibility ✅ status: resolved Applies to issues that have pending PRs resolving them, or PRs that have already merged.

Comments

@damyanpetev
Copy link
Member

Is your feature request related to a problem? Please describe.

Related to #6272, after looking at the descriptions for calendar in the datepicker example:
"calendar that uses the grid pattern"
"as specified in the grid design pattern, only one button in the calendar grid is in the Tab sequence."

In other words, tab navigation through the calendar is supposed to allow you to jump through the prev/next buttons, the year/month pickers and the calendar grid itself. Right now the calendar handles the tab as it would cursor keys, which is super tedious.

Describe the solution you'd like

The tab navigation of the calendar should allow you to jump through the separate groups and have a single tab stop for the actual calendar grid.

Additional context

I realize this is a behavior change from the current implementation, but the way the spec describes the behavior seems very reasonable, so I'm logging this as an enhancement.

@damyanpetev damyanpetev added 📈 enhancement 📆 calendar ♿ a11y When the issue or PR is related to accessibility labels Dec 3, 2019
@damyanpetev
Copy link
Member Author

Actually, I don't see that in the spec.. Is this Tab behavior simply a side-effect of the date elements being focusable?

@hanastasov
Copy link
Contributor

hanastasov commented Dec 3, 2019

Actually, I don't see that in the spec.. Is this Tab behavior simply a side-effect of the date elements being focusable?

Currently, we just let the browser handle the tabs as it would. I don'` know if this was intentional, I guess yes. There are some tweaks though that skip a disabled/non-visible date when tabbing.

@github-actions
Copy link

There has been no recent activity and this issue has been marked inactive.

@github-actions github-actions bot added the status: inactive Used to stale issues and pull requests label May 11, 2020
@zdrawku
Copy link
Contributor

zdrawku commented May 11, 2020

@radomirchev does "Next Milestone Draft" means that this issue is planned for the next milestone?

@zdrawku zdrawku removed the status: inactive Used to stale issues and pull requests label May 11, 2020
@radomirchev
Copy link
Contributor

@zdrawku it is a draft, not a final version. It is under consideration to be included in the next milestone.

@github-actions
Copy link

There has been no recent activity and this issue has been marked inactive.

@github-actions github-actions bot added the status: inactive Used to stale issues and pull requests label Jul 15, 2020
@zdrawku zdrawku removed the status: inactive Used to stale issues and pull requests label Jul 20, 2020
@zdrawku zdrawku assigned ddincheva and unassigned hanastasov Sep 24, 2020
@zdrawku zdrawku added the 🛠️ status: in-development Issues and PRs with active development on them label Sep 25, 2020
@zdrawku zdrawku added ✅ status: resolved Applies to issues that have pending PRs resolving them, or PRs that have already merged. and removed 🛠️ status: in-development Issues and PRs with active development on them labels Oct 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📆 calendar 📈 enhancement keyboard-navigation ♿ a11y When the issue or PR is related to accessibility ✅ status: resolved Applies to issues that have pending PRs resolving them, or PRs that have already merged.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants