WebAIM - Web Accessibility In Mind

E-mail List Archives

New resource showing accessibility problems of dynamic web components in many tests with users (video)

for

From: Birkir R. Gunnarsson
Date: Nov 24, 2018 8:31AM

2 quick comments on tabpanel discovery for screen readers.

When a screen reader encounters a tablist element (or rather, the
focus is moved inside a tablist element) it goes into
forms/application mode, a mode in which screen reader navigation (with
arrow keys / short cut keys) is unavailable).
This makes a tabpanel element with no focusable elements more
difficult to discover by a screen reader user because you have to
manually force the screen reader out of forms/application mode once
you have activated a tab.
This is why the idea of putting tabindex="0" on a tabpanel element has
been floated and why it kind of makes sense in this particular context
(it's not ideal, it represents an element which is focusable but has
no interactive properties).

You don't want to use Javascript to send focus to the tabpanel as soon
as the tab is focused. That is like having an onchange event in a
dropdown that automatically sends focus elsewhere.
Imagine that the tab the user wants to activate is the last in a list
of 5 tabs. You don't want the user to have to press the arrow key,
then shift-tab to get back to the tablist and repeat 4 times to
activate the desired tab.
If you implement a set of tabs where the user has to press the enter
key to activate, you could implement it so that focus automatically
goes to the tabpanel but if pressing the arrow key navigates to and
activates the tab you hvae this problem.


On 11/1/18, glen walker < <EMAIL REMOVED> > wrote:
> Ok, I looked at another one but really need to get to bed (4:00am for me
> :-))
>
> Tabbed interfaces, four comments.
>
> 1. In the "Realising that arrow keys should be used for focusing tabs"
> section, you mention that "Web authors sometimes respond to that
> usability
> problem by making the individual tabs also selectable via the tab key."
> This can cause a problem because if the content panel for the currently
> selected tab has focusable elements, then they will not be the next
> focusable thing immediately after the selected tab. You'd have to tab
> through the other tabs in the tablist before getting to the content
> panel.
> Heydon points that out on his page too -
> https://inclusive-components.design/tabbed-interfaces/#keyboardbehavior
>
> 2. In the "Bypassing visible panel content" section, you say "Another
> problem is that screen reader users may bypass the content of the
> visible
> panel, especially if there are no focusable elements in it." In a
> previous
> WebAIM discussion, we talked about not assuming that a screen reader
> user
> will use the tab key to navigate. See
> https://webaim.org/discussion/mail_thread?thread=8966. So you may want
> to caveat your statement about this problem that if a screen reader is
> using the tab key to navigate, then they may miss the content panel if
> there are no focusable elements in it.
>
> Also, you say "This is why some authors recommend making the panel
> itself focusable
> via tabindex". You might have to clarify that. I don't think we want
> the panel itself to have a tabindex="0" because you typically don't want
> a
> non-interactive element to receive keyboard focus via the tab key.
> However, you could use tabindex="-1" on the panel and programmatically
> move
> the focus to it such as when you hit the down arrow key. Heydon
> suggests
> this too. I just wanted to clarify what you meant by using "tabindex".
> That is, tabindex is ok if you're using -1 but probably not ok if using
> 0.
>
> 3. I didn't understand your third bullet point in your tips section.
> You said "Use role="presentation" on list elements (li) to which you
> have
> assigned a new role (like role="tab")."
>
> If you used role="tab" then why would you want to override that and then
> set role="presentation"? I don't think you're really recommending that
> but
> that's what it sounds like.
>
> I *think* what you're trying to say (and please correct me if I'm
> misinterpreting) is that if you are using a <ul role="tablist"> and the
> subsequent <li> elements do *not* have a role specified, then you must
> set
> role="presentation" on the list items. However, if the list items have
> role="tab", then you're ok.
>
> 4. Your first tab example video shows an example from sas.com. I
> provided that example way back in May (see
> https://webaim.org/discussion/mail_thread?thread=8742#post1) when you
> asked for real world tab examples. Yay :-) (I worked for SAS for 30
> years.)
>
>
> Glen
> > > > >


--
Work hard. Have fun. Make history.