Fixes #700 - Fix keyboard interaction for tabs as per W3 accessibility pattern #1112
Conversation
…nt to adhere to ARIA Authoring Practices Guide
…port for keyboard navigation
…unnecessary calls
|
Hi there @jonnymuir, thank you for this contribution! 👍 While we wait for the team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:
Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution. If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request. Thanks, from your friendly Umbraco GitHub bot 🤖 🙂 |
jonnymuir
changed the title
|
Note - although this works well in storybook, there are other things going on in the back office which means that the tabbed interfaces are not interacting well. For instance the umb-app component is somehow trapping / claiming the focus, meaning that when we query for the document.activeElement, we are not getting the right thing back. |
…listeners to avoid problems with shadow dom and detecting the active focus
|
Last change has fixed the focusing problem. It was to do with how the document.activeelement and the shadow dom play together. Instead changed it to listen to focus and blur events. Interestingly enough, couldn’t get it to fail in a test, just when in situ in the full back office. |
jonnymuir
changed the title
|
Fixes #700 |
…shadow DOM is not always present.
|
Last commit was because after doing a bit more testing in the back office, I found that the slot changed event wasn't always being fired after the shadow DOM had been populated. This meant that the setfocusable on the tabs sometimes worked, and sometimes didn't. Making the slot changed event async and waiting for the tab's updateComplete promise to complete made sure that setfocusable happens in the correct sequence every time. The "section" tab group appeared to consistently fall foul of this timing issue. You can see from the this screenshot this is now fixed (here with the setting tab having focus): 
|
…ke it focusable, don't automatically focus
|
Description
This pull request implements the keyboard interaction part of the W3 Accessibility pattern as per https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
Implement the keyboard and activation
Left and right arrow move the focus left and right (and loop round).
Home and end go to first and last.
Space and enter make the tab active.
It was decided to go with manual activation of the tab according the w3 pattern because automatic activation, although usually more desirable, doesn't work so well with delay content which is what the Umbraco back office uses in most of its tabbed containers.
Handling of overflow tabs
If the screen size is made smaller, tabs are removed from view and moved to the more button, drop down menu (existing functionality). This has been changed so the tabs are now removed from view using translateX rather than display: none and if brought into focus by the keyboard, this is removed and logic to make sure they are in view has been added. This is so that screen readers read out the correct number of tabs
Types of changes
Motivation and context
Accessibility fix
How to test?
Tab (as in use the tab key) to select the tabbed interface. Either the first or the currently active tab will become in focus. You can use the left, right, home, and end keys to navigate between the tabs. Enter or space will select the tab.
Make you window smaller so that the the more button appears. Test that the interaction still works and you can cycle through all the tabs.
Use a screen reader (voice over / NVDA / JAWS) to test that each tab makes sense and you can orientate yourself in with the correct number of tabs in the tab group.
Screenshots (if appropriate)
Example screen shot showing voice over caption (media tab, 3 of 6) and focus on the "media" tab.
Same example on restricted view port
Checklist