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 alphagov/govuk-design-system-backlog#66 (comment)

[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, ***@***.***> 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 <#860 (comment)>, 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 😢 )

[CharlotteDowns]

Possibly something to look at when we look at improving the tabs pattern or start working on the tabbed navigation proposal

[selfthinker]

This was reported again recently.

I looked into it and found that it's likely a bug in NVDA.
It happens with NVDA in both Firefox and Chrome. It doesn't happen in any other major screen reader.

The problem seems to be that the screen reader focus disappears. The same happens with the tabs pattern in WAI's Authoring Practice Guide.

There seems to be confusion about what the exact issue is, so I'll describe it in detail...

Steps to reproduce the issue

1. Use NVDA with Chrome (Firefox works as well but there is another bug which interferes here so might be confusing, see below)
2. Open https://design-system.service.gov.uk/components/tabs/default/
3. Use the down arrow keys to navigate to all of the tabs and further down to the first heading (all of which work fine using the screen reader focus)
4. Use shift + tab to get the keyboard focus to the tabs
5. Use the down arrow key again to try to get back to the heading

Actual vs expected behaviour

Although step 4 above already behaves unexpectedly, it is step 5 which is the main issue.
You would expect to be able to get back to the content of the tab container again except that you are now stuck among the tabs. Only the keyboard focus seems to be working as soon as it has the focus and the screen reader focus seems to have disappeared and cannot be used again unless the keyboard focus moves to a different element.

You can get out of it via tabbing (not in the example above as there is nowhere to tab to, try https://www.gov.uk/bank-holidays for that). But if there is nothing interactive in the tab container you'd have to go back up to the start of the container (as is the case with the Bank Holiday example). And that is only if you understood what was happening and have the patience to try and find where the tab container starts.
You can also get out of it via other shortcuts, but that is highly reliant on what is in the tab container (like headings).

Additional problems for Firefox users

The problem gets worse for Firefox users due to another bug that means they cannot use the arrow keys at all to get to the other tabs, so have to use the tab key to get to them.

[selfthinker]

I looked into it and found that it's likely a bug in NVDA. It happens with NVDA in both Firefox and Chrome. It doesn't happen in any other major screen reader.

I had initially only tested in JAWS 2023. As the user who reported the issue again has mentioned it also happens in JAWS for them and has now come back with their JAWS version (which was 2022), I retested in JAWS 2022 and lots of earlier versions as well. And I can confirm it is also an issue in JAWS up to and including 2022 but was fixed in JAWS 2023.