De-ARIA-fy tabs

[patrickhlauke]

Current tabs implementation http://v4-alpha.getbootstrap.com/components/navs/#javascript-behavior uses ARIA pattern, which may not be ideal for actual users - see http://simplyaccessible.com/article/danger-aria-tabs/

This is a meta-issue to explore the current implementation of tabs, how the proposed de-ARIA-fied version works, and potentially to adopt the latter in v4

[thbt]

Any update on this issue ?

[LaurenceRLewis]

@patrickhlauke
Please read this article which rebuffs danger aria-tabs.
https://medium.theuxblog.com/danger-testing-accessibility-with-real-people-4515f72db648

[mdo]

Status on this?

[LaurenceRLewis]

Hopefully a decision is made to drop the idea of e-Aria-fied as it is a bad one, :-)

[patrickhlauke]

The aspect that Leonie's article still doesn't fully address is that of sighted non-AT keyboard users who may simply not be expecting desktop/native application navigation paradigms to apply to web content, and who may therefore be confused about pure ARIA-fied tabs. BS doesn't use those currently (indeed it's a mixed bag, since tab triggers are currently implemented as separately focusable, rather than just a single focus stop). I'd keep this open as a longer-running exploration is needed (once I get time to mock up some alternatives)

[LaurenceRLewis]

I need to think on this one again before I post a reason for or against. It is indeed interesting when considering accessibility for all users.

[LaurenceRLewis]

Sighted keyboard only users have to be aware of various navigation methods in the same way that non-sighted screen reader users do. Getting stuck in situations where everything is a tab stop can be equally disorienting and aggravating.

There is a simple technique for providing sighted keyboard only users with the ability to see what keystrokes are available when setting focus to a tab when the arrow keys are then enabled for switching between tabs, which is to use a CSS focus pseudo element to show double arrow graphic when a tab receives focus:

a.tab:focus:after {
/* Styling for element, such as absolute positioning to enable float etc. */
Content: ‘<i class="fa fa-angle-double-right" aria-hidden="true"></i>’;
}

Excessive tab stops don’t equal better accessibility in such cases as this.

[patrickhlauke]

throwing thierry's article http://cssmojo.com/tab-panel-the-right-way/ into the mix (regardless of the slightly grating tone, makes good additional points to consider)

[LaurenceRLewis]

Probably one if those questions that has no definitive solution. Interesting article which again leaves food for thought. Thanks for posting the link. By the way, as an aside, in regards to the point in the article about SR announcing the number x of x tabs. This is announced. However, I tend to include aria-posinset="" and aria-setsize="" because in iOS the correct number of tabs is not announced correctly by VoiceOver, this will force the screen reader to announce the correct numbering. The more I learn the less I seem to know 😁