Govuk-frontend: Tabs interface needs better way to get to panel content

[kr8n3r]

Moving over from Frontend Toolkit
issue raised by @detlevhfischer

When used with NVDA it is difficult to get from the tabs on https://design-system.service.gov.uk/components/tabs/ to the corresponding panel. Both left / right as well as up / down arrows traverse the tabs in the tablist. I suggest to consider implementing arrow down as a shortcut to move focus to the right panel content. See https://inclusive-components.design/tabbed-interfaces/ , section "A problem reading panels".

@alex-ju commented
@detlevhfischer: hi, thanks for adding your suggestions, we took that article into consideration while building the component. have you done any user research around this?

@detlevhfischer commented
I just tried it using NVDA and Firefox and noticed that left/right arrow did the same as top/down arrow, so that latter is not used (as I believe recommended by Heydon) to move the focus to the panel. Leaving forms mode and trying reading mode to progress to the panel often lands in the wrong one because tab and its panel are not adjacent in the source code, I guess.
I intend o include the gov.uk example in the user tests I am currently conducting and will report back on issues, if there are any.

@alex-ju commented
Feedback from research would be extremely valuable for us and would help us shape the component, thank you!

[hannalaakso]

Hi @detlevhfischer,

Thanks for raising this issue related to the tabs component.

We'd be keen to know if any related findings came out of the user tests you conducted?

Thanks,
Hanna

[detlevhfischer]

It's holiday time - there will be more tests after the summer break. I'll be in touch!
I have just tried again with different settings - I turned off caret brosing (Fn + F7 in Firefox ), and turned off HID-conformant touch screen in hardware settings (I had to do this anyway for another test). While I am not sure whether that has changed anything significantly, the problem with using the NVDA sreen reader remains that in order to get, say, to the first tab's panel content, I need to tab which bypasses the panel content since that has no focusable items. If I use the arrow keys, that will focus tabs 2-4 (and show the corresponding panel content) so by the time I get to arrowing into the panel, it will show the panel content for tab 4, not the first one. It is possible that this is not a problem for JAWS users where there is a special key to jump to the corresponding panel content, but with NVDA, I don't see a way to do it except tabbing past the whole panel construct and then arrowing backwards into the panel, which is an awkward hack. More competent screen reader users may have ways for solving this that I am not aware of (I am not using NVDA on a daily basis, just as a testing / evaluation tool).
If anything interesting comes up in user testing with screen reader users, I'll be in touch!

[nickcolley]

"In the operation of screen readers like NVDA and JAWS, the down arrow moves the user to the next element (focusable or otherwise) and reads it out. Without intervention, this would be the next tab in the tablist. Instead, we can intercept the down arrow key press and move focus programmatically to the open panel itself, making sure it isn't missed. See panels[i].focus() in the following snippet:"

@heydon this seems well reasoned but do you have any research that shows that the current behaviour is a barrier for NVDA users?

[Heydon]

Hi @nickcolley. Only my own testing. I basically experienced what @detlevhfischer did. I think many rely on the idea that aria-controls will save them, but it is only supported by JAWS.

Related: Note that, in the book version of inclusive-components.design, I have made some updates. These include 'cycling' through tabs, rather than the left and right arrow keys just doing nothing when you reach the end or the start. I can give you the updated code should you want it.

[nickcolley]

Some interesting guidance in the WAI-ARIA authoring guides: https://www.w3.org/TR/wai-aria-practices/#kbd_selection_follows_focus

https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

In this implementation of tabs they have made the tabpanel itself a focusable element, which recieves focus when you press tab.

So the interaction looks like this:

1. Tab to tabs component
2. Pick a tab
3. Tab into tabs panel

Something worth thinking about here is that clicking the panel will focus it, we have had issues with this relating to the skip-link before https://github.com/alphagov/govuk-design-system-backlog/issues/66#issuecomment-411673528

[Heydon]

Yeah, you can do that too. But, where there are focusable elements in the
panel, it becomes redundant and a bit obstructive. I added the down arrow
because that's what I think folks would reach for if tabbing became
confusing. I think either solution is OK though.

On Mon, 17 Sep 2018, 15:18 Nick Colley, [e-mail] wrote:

Some interesting guidance in the WAI-ARIA authoring guides:
https://www.w3.org/TR/wai-aria-practices/#kbd_selection_follows_focus

https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

In this implementation of tabs they have made the tabpanel itself a
focusable element, which recieves focus when you press tab.

So the interaction looks like this:

1. Tab to tabs component
2. Pick a tab
3. Tab into tabs panel

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/alphagov/govuk-frontend/issues/860#issuecomment-422034959,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AApuJkGUQA_gEDZml4kxp7AZ69vwz4G0ks5ub68sgaJpZM4U_lA5
.

[nickcolley]

We have had some internal conversations that I forgot to update here:

I think there is a need to do more, we do not have evidence of how it impacts real users but from trying to use NVDA it seems overly complicated.

I spoke with the GOV.UK Design System team (Tim, Jani and Hanna) and we agreed to try making the panel focusable, with the con that you have to tab twice to get to tabbable content within the panel.

We think this will better stand the test of time as we're worried about custom keyboard behaviour colliding with newly introduced mechanics.

We want to make sure our implementation is well tested across assistive technologies and if possible consult the accessibility team in one of their clinics.

We then will ask the community to help test this, and if this does not happen organise a component round up ourselves.

I've created a card in our internal team board to track this: https://trello.com/c/YXM4dkVc/384-make-tab-panel-focusable-in-the-tabs-component (only visible for team members sorry 😢 )