Regression: vertical tabs are not keyboard accessible.
Problem/Motivation
The vertical tabs javascript has been refactored and improved in D8, however an accessibility problem has been introduced.
In D7, a sighted keyboard user can use the keyboard to tab through the vertical tabs, and access any tab they want by pressing enter when the when the desired tab is focussed.
In D8, when a keyboard user arrives at a vertical tabset using the tab key, they become stuck at the first tab. Pressing tab again should allow the user to cycle through all tabs to select the one they want. The upshot is that some configuration options will NOT be available at all to keyboard users. For example, a keyboard user will be prevented from turning off the "Display author and date information" option for node types.
This is somewhat mitigated for screenreader users, as the vertical tab links are inside list-items. Many screenreaders provide controls to cycle through list-items, so there is a workaround route to select the desired tab.
Proposed resolution
Fix it. D8 behaviour should stay the same as D7.
Remaining tasks
User interface changes
bug fix - make it work as intended. Restore the D7 behaviour for keyboard navigation.
API changes
None proposed.
Data model changes
None proposed.
Beta phase evaluation
| Issue category | Bug because it's a regression from Drupal 7 |
|---|---|
| Issue priority | Major because it's a regression and made UX issue |
| Prioritized changes | The main goal of this issue is usability and accessibility |
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | regression_vertical-2574917-4.patch | 603 bytes | andrewmacpherson |
Comments
Comment #2
andrewmacpherson commentedBumping to major. This is a failure at WCAG level A, and a regression which WILL break Drupal for a clear group of users:
Comment #3
andrewmacpherson commentedI've been looking at the D7 and D8 versions of vertical-tabs.js, and I have a fix. Expect a patch soon.
Comment #4
andrewmacpherson commentedThis might turn out to be an easy fix.
Comment #5
andrewmacpherson commentedExplanation: the patch in #4 nests event.preventDefault() correctly, so we only prevent default link behaviour when the enter key is pressed. Pressing tab, page up, space, etc. should continue to have the default behaviour.
Here is what D7 does. We only prevent default behaviour when the enter key is detected:
Compare this with D8. Default behaviour is prevented regardless of which key was pressed. Now, the enter key is the only key which does anything:
Consequently, the user cannot press the tab key to move focus to the next vertical tab link.
The patch in #4 corrects this by nesting event.preventDefault() correctly.
Comment #6
andrewmacpherson commentedComment #7
andrewmacpherson commentedComment #8
googletorp commentedReviewed and tested the code, all looks good.
Comment #9
andrewmacpherson commentedThanks googletorp, but we're still waiting for the test bots to smile ;-)
Comment #10
andrewmacpherson commentedComment #11
googletorp commentedAdd beta evaluation, so all it good to go. (Assuming test bot doesn't fail, but since test bot doesn't test JS I can't see this possibly failing)
Comment #12
andrewmacpherson commentedAwesome, thanks googletorp.
Comment #13
mgiffordThis could be a record between posted & getting into Core... Great job guys!
Comment #15
nod_That's what the code was supposed to be. Introduced in #1749782: Use event.preventDefault(); and event.stopPropagation(); instead of return false;.
Comment #17
googletorp commentedRetesting issue, as the fails shouldn't be related to this issue - RTBC when patch turn green again.
Comment #18
catchComment #21
quietone commented