Links inside help tabs (help-tab-content) are not keyboard accessible

[rianrietveld]

When accessing the help tabs some divs with the help text contain links.
These links can't be accessed by keyboard tabbing only.

For example the link "learn more about embeds" in the Insert Media tab.

This ticket is submitted at the WordCamp Netherlands contributors day.

[neil_pie]

This is because an active state is being applied to each tab on keyboard focus as well as click, rather than just click. This displays the contents of each tab-panel as the links themselves gain keyboard focus.

The problem is caused because keyboard focus only enters the tab-panel once it has finished cycling through the tab-links themselves ( and in this case the "more information" links to the right ). Because the active state is applied to each tab-panel as it gains focus, the final tab is always being displayed by the time keyboard focus reaches the tab-panel contents and only these links will be keyboard accessible. You can see an example of this in the Help tabs of edit.php

I don't believe that this is correct behaviour, as nowhere else would you expect to activate a link or button simply by applying keyboard focus. The submitted patch fixes this. Tabs no longer become active on keyboard focus, but instead when 'Enter' is pressed. This means that links in all of the tab-panels are now keyboard accessible

[joedolson]

Works, looks good to me.

The tab order is a little bit non-intuitive in this area of the admin, so we should look at a stronger visual focus and possibly changing the HTML order, but that's another issue, and I'll raise a ticket for that.

[rianrietveld]

Yes, it works, but the tab order is indeed a bit weird and like Joe writes, not non-intuitive.
And now keyboard readers have to Enter-Tab to read the info, instead of just tab.
Maybe putting the extra info inside the <li> of contextual-help-tabs would better for a natural tab order.

[neil_pie]

I absolutely agree that the tab order is jarring. One would expect to tab from left to right through the tab-list, then the tab-panel, then the sidebar. As Joe states, this is a separate issue.

I personally disagree that activating tab-panels on keyboard focus is correct/desired behaviour. I'm basing this on the WAI-ARIA best practices at ​http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#tabpanel

tab: the label/title area of the tab panel. This is where you click to activate a tab panel
When the user activates a tab, the contents of that tab is made visible ... The active tab is placed into the tab order.

The key word to me there is 'click'. In other contexts this would indicate a press of the spacebar or enter key. Am I misinterpreting this or should it not be applied in this case?

Also, isn't the alternative to force the user to tab through all the links in a tab-panel before keyboard focus is moved to the next tab in a tab-list? This feels like a worse User Experience to me, or is there another solution that I'm missing?

[GrahamArmfield]

Replying to neil_pie:

I absolutely agree that the tab order is jarring. One would expect to tab from left to right through the tab-list, then the tab-panel, then the sidebar. As Joe states, this is a separate issue.

I personally disagree that activating tab-panels on keyboard focus is correct/desired behaviour. I'm basing this on the WAI-ARIA best practices at ​http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#tabpanel

tab: the label/title area of the tab panel. This is where you click to activate a tab panel
When the user activates a tab, the contents of that tab is made visible ... The active tab is placed into the tab order.

The key word to me there is 'click'. In other contexts this would indicate a press of the spacebar or enter key. Am I misinterpreting this or should it not be applied in this case?

Also, isn't the alternative to force the user to tab through all the links in a tab-panel before keyboard focus is moved to the next tab in a tab-list? This feels like a worse User Experience to me, or is there another solution that I'm missing?

Coincidentally I've been researching this for a client site I've just started working on. I'm basing my tabs on the ideas set out in these two resources: ​http://www.marcozehe.de/2013/02/02/advanced-aria-tip-1-tabs-in-web-apps/ and ​http://www.deque.com/blog/building-accessible-tab-panel-aria/

The thrust of the articles is that tabbing around a page will eventually bring you to a tab panel grouping. Focus should go to whichever tab is currently active. As long as all the ARIA is in place screen readers will be notified they are in a tab list.

The convention is to use the left/right arrow keys to move amongst the tabs. But actioning the tabs is carried out using the space bar (or Enter key) when the person has found a tab they are interested in. When they action a tab then focus is to be transferred into the first item within the corresponding tab panel (or the panel itself), and the corresponding tab panel will become visible. Further tabbing will visit any links within the tab and then move off the tab panel onto the rest of the page.

Note that not all of the actual tabs are part of the tab order of the page - only the currently selected one.

I think all this agrees with the page you have referenced Neil.

[helen]

In 28869:

Don't switch contextual help tabs when tabbing around. props neil_pie. see #28209.

[helen]

I committed the patch, as it fixes the immediate issue at hand. It sounds like there are concerns over the actual order of elements/tabbing?

[neil_pie]

Replying to joedolson:

Works, looks good to me.

The tab order is a little bit non-intuitive in this area of the admin, so we should look at a stronger visual focus and possibly changing the HTML order, but that's another issue, and I'll raise a ticket for that.

Did another ticket get raised joe? I can't see on trac. If not I can bounce one in today as I have a little spare time this week to work in this.

[helen]

Let's open new tickets for more fixes here - probably not a lot more we'll have bandwidth for in 4.0.