Ticket #3079 (closed bug: fixed)
Tabs: keyboard accessibility
| Reported by: | acheetham | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.9.0 |
| Component: | ui.tabs | Version: | 1.6rc6 |
| Keywords: | keyboard a11y | Cc: | davidb |
| Blocking: | Blocked by: |
Description (last modified by scott.gonzalez) (diff)
Currently, tabs are navigated using the Tab key, but the more appropriate method is to use the Tab key to navigate *to* the group of tabs, and then use the Arrow keys to navigate amongst the tabs:
Also, when you do use the keyboard to navigate between tabs (but without pressing Enter to select a tab) there is no change in class, and hence no possibility to apply visual queues.
There's documentation about this on the planning wiki.
Change History
comment:1 Changed 5 years ago by klaus.hartl
- Priority changed from major to minor
- Type changed from bug to feature
comment:3 Changed 4 years ago by scott.gonzalez
- Status changed from new to assigned
- Priority changed from minor to critical
- Version changed from 1.5.1 to 1.6rc6
- Milestone changed from TBD to 1.next
- Owner klaus.hartl deleted
- Type changed from feature to bug
comment:4 Changed 4 years ago by kliehm
According to the WAI-ARIA Best Practices document, tabs in a web page should behave exactly like browser tabs. So you tab on the active tab, and if you continue tabbing you get on items in the active tabpanel. Switching tabs is done by arrow keys (left, right, up, down), CTRL-tab and CTRL-SHIFT-tab, and even page-up and page-down - however, I couldn't prevent event propagation on those keys. I have a rather small script that does that including ARIA goodness, though it's not jQuery UI-fied. If I can help just let me know.
comment:5 Changed 4 years ago by kliehm
I should add that switching through tabs should be in carousel mode, i.e. from the last tab to the first and vice versa.
comment:6 Changed 4 years ago by kliehm
May I bring to your attention that this bug is "assigned", but the owner has been deleted. I suppose if it ever is to be worked on and resolved it needs an owner, doesn't it?
comment:9 Changed 3 years ago by scott.gonzalez
- Milestone changed from 1.8 to 1.next
Bumping to 1.9, which will contain a major push for a11y.
comment:10 Changed 3 years ago by scott.gonzalez
- Priority changed from critical to major
- Milestone changed from 1.next to 1.9
comment:11 Changed 2 years ago by scott.gonzalez
- Priority changed from major to blocker
- Status changed from assigned to open
- Description modified (diff)
- Summary changed from Tabs not properly keyboard accessible to Tabs: keyboard accessibility
comment:12 Changed 2 years ago by eikes
comment:13 Changed 2 years ago by eikes
edit: updated th pull request
comment:14 Changed 2 years ago by petersendidit
comment:15 Changed 19 months ago by scott.gonzalez
From Everett Zufelt (#7846): When using open on mouseover it appears to no longer be possible to open tabs via keyboard.
comment:16 Changed 19 months ago by scott.gonzalez
#7846 is a duplicate of this ticket.
comment:18 Changed 19 months ago by ezufelt
Tabs demo 1.9pre
After using keyboard to add a new tab in the Simple Manipulation demo, or opening a tab in the Collapse demo, focus is set to first element in the DOM.
comment:19 Changed 16 months ago by scott.gonzalez
#3483 is a duplicate of this ticket.
comment:19 Changed 12 months ago by Scott González
- Status changed from open to closed
- Resolution set to fixed
Tabs: Implement ARIA + Key handling. Fixes #3079 - Tabs: keyboard accessibility. Fixes #7845 - Tabs: default accessibility.
Changeset: 48588d3bef746129aa66e5fa915da2962a1a4014