E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Birkir R. Gunnarsson
Date: Sat, Nov 24 2018 8:31AM
Subject: New resource showing accessibility problems of dynamic web components in many tests with users (video)
No previous message | Next message →

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 ADDRESS 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.

From: Detlev Fischer
Date: Mon, Nov 26 2018 3:18AM
Subject: Re: New resource showing accessibility problems of dynamic web components in many tests with users (video)
← Previous message | No next message

Hi Birkir,

thanks for your helpful feedback about screen reader issues with tab panels.

I have revised the text in the problems section on the tabbed interfaces
page https://accessuse.eu/en/tabbed-interfaces.html#problems

I have now included a general section "Screen reader users and tab
panels" which is more or less based on your feedback.

I have also tweaked the advice in the accessibility tips section
https://accessuse.eu/en/tabbed-interfaces.html#tips in bullet point
"Make the panel content focusable". I hope is hasn't got too wordy now,
and captures what you wanted to add.

Best,

Detlev


Am 24.11.2018 um 16:31 schrieb Birkir R. Gunnarsson:
> 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.

--
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg

Mobil +49 (0)157 57 57 57 45

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus