E-mail List Archives

Search E-mail List Archives for

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

From: Mark Magennis
Date: Wed, Sep 27 2017 4:16AM
Subject: Navigating from tab to tab panel
No previous message | Next message →

Hi everyone.

I've a question about how tabbed interfaces work with a screen reader. Usually, it seems, the tabs are in a list which is followed by a bunch of divs, each containing a tab panel. If so, when the user activates a tab and its panel opens, in order to get to the content (leaving aside the JAWS Ins+Alt+M shortcut as it's only JAWS), they have to arrow down through the remaining tabs first.

This seems unintuitive. It would seem more natural that when you open a tab, it's contents appear immediately after it, not with all the other tabs in between. So instead of this ordering:

Tab 1
Tab 2
Tab 3
Tab 1 panel
Tab 2 panel
Tab 3 panel

you would have this:

Tab 1
Tab 1 panel
Tab 2
Tab 2 panel
Tab 3
Tab 2 panel

In both cases, of course, only the open panel would be exposed.

I'm wondering has anyone tried to do it this way? Does anything think it's worth doing it this way, or is it likely to cause other usability problems? Should it just be accepted that the panels normally come after the whole tab list?

If anyone has done it this other way, then I'd be interested in seeing how. It seems it would involve placing the panel directly after the tab in the DOM, but because the tab is a list item, this would make the panel its child would it? Which sounds strange.

Thanks,
Mark

Mark Magennis | Accessibility Support Manager
InterAccess.ie <http://interaccess.ie/>; - Accessible UX

From: Mohith BP
Date: Wed, Sep 27 2017 5:26AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

Hi Mark,

I agree with you regarding the unnecessary navigation.
The suggestion you proposed works good provided:
1. Initially none of the tabs are expanded so that the user can
navigate between the list of tabs in both brows and focus modes.
2. Once one of the tab is activated, the user should be able to
navigate between the list of tabs without encountering the expanded
tab panel. I think at least in focus mode this can be achieved.

We have implemented the following:
1. Tabs and tabpanel are arranged in the treditional order (as you
explained in first scenario).
2. In the list of tabs when enter is pressed to activate the tab the
focus is automatically moved to the beginning of the tab panel with
JAVA script.
3. Pressing shift + tab from the tab panel brings back the focus to
the active tab in the tablist.

Note: This still has other issues such as if tab panel has any
actionable elements, focus cannot be brought back to the active tab as
logical tab focus need to be maintained.

Proposal of providing a skip link at the end of the tabpanel back to
the tablist was mostly rejected by designers.


Thanks & Regards,
Mohith B. P.

On 9/27/17, Mark Magennis < = EMAIL ADDRESS REMOVED = > wrote:
> Hi everyone.
>
> I've a question about how tabbed interfaces work with a screen reader.
> Usually, it seems, the tabs are in a list which is followed by a bunch of
> divs, each containing a tab panel. If so, when the user activates a tab and
> its panel opens, in order to get to the content (leaving aside the JAWS
> Ins+Alt+M shortcut as it's only JAWS), they have to arrow down through the
> remaining tabs first.
>
> This seems unintuitive. It would seem more natural that when you open a tab,
> it's contents appear immediately after it, not with all the other tabs in
> between. So instead of this ordering:
>
> Tab 1
> Tab 2
> Tab 3
> Tab 1 panel
> Tab 2 panel
> Tab 3 panel
>
> you would have this:
>
> Tab 1
> Tab 1 panel
> Tab 2
> Tab 2 panel
> Tab 3
> Tab 2 panel
>
> In both cases, of course, only the open panel would be exposed.
>
> I'm wondering has anyone tried to do it this way? Does anything think it's
> worth doing it this way, or is it likely to cause other usability problems?
> Should it just be accepted that the panels normally come after the whole tab
> list?
>
> If anyone has done it this other way, then I'd be interested in seeing how.
> It seems it would involve placing the panel directly after the tab in the
> DOM, but because the tab is a list item, this would make the panel its child
> would it? Which sounds strange.
>
> Thanks,
> Mark
>
> Mark Magennis | Accessibility Support Manager
> InterAccess.ie <http://interaccess.ie/>; - Accessible UX
> > > > >

From: mhysnm1964
Date: Wed, Sep 27 2017 5:56AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

Extracted this from the ARIA best practise 1.1 guide which is what you are saying:

Permalink for 2.23 Tabs

Tabs are a set of layered sections of content, known as tab panels, that display one panel of content at a time. Each tab panel has an associated tab element,
that when activated, displays the panel. The list of tab elements is arranged along one edge of the currently displayed panel, most commonly the top edge.


Terms used to describe this design pattern include:

definition list of 4 items
Tabs or Tabbed Interface

A set of tab elements and their associated tab panels.

Tab List

A set of tab elements contained in a
tablist
element.

tab

An element in the tab list that serves as a label for one of the tab panels and can be activated to display that panel.

tabpanel

The element that contains the content associated with a tab.
list end

When a tabbed interface is initialized, one tab panel is displayed and its associated tab is styled to indicate that it is active. When the user activates
one of the other tab elements, the previously displayed tab panel is hidden, the tab panel associated with the activated tab becomes visible, and the tab
is considered "active".

Examples
list of 2 items
- Tabs With Automatic Activation:
A tabs widget where tabs are automatically activated and their panel is displayed when they receive focus.
- Tabs With Manual Activation:
A tabs widget where users activate a tab and display its panel by pressing Space or Enter.
list end

Keyboard Interaction

For the tab list:

list of 3 items
- Tab: When focus moves into the tab list, places focus on the active tab element . When the tab list contains the focus, moves focus to the next element
in the page tab sequence outside the tablist, which is typically either the first focusable element inside the tab panel or the tab panel itself.
- When focus is on a tab element in a horizontal tab list:
list of 2 items nesting level 1
◦ Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See
note below).
◦ Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused
tab (See note below).
list end nesting level 1
- When focus is on a tab in a tablist with either horizontal or vertical orientation:
list of 5 items nesting level 1
◦ Space or Enter: Activates the tab if it was not activated automatically on focus.
◦ Home (Optional): Moves focus to the first tab
◦ End (Optional): Moves focus to the last tab.
◦ Shift + F10: If the tab has an associated pop-up menu, opens the menu.
◦ Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel. If any tabs remain, sets focus to the
tab following the tab that was closed and activates the newly focused tab. Alternatively, or in addition, the delete function is available in a context
menu.
list end nesting level 1
list end

NOTE
list of 3 items
1. It is recommended that tabs activate automatically when they receive focus as long as their associated tab panels are displayed without noticeable latency.
This typically requires tab panel content to be preloaded. Otherwise, automatic activation slows focus movement, which significantly hampers users' ability
to navigate efficiently across the tab list. For additional guidance, see
4.4 Deciding When to Make Selection Automatically Follow Focus.
2. If the tabs in a tab list are arranged vertically:
list of 2 items nesting level 1
A. Down Arrow performs as Right Arrow is described above.
B. Up Arrow performs as Left Arrow is described above.
list end nesting level 1
3. If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even
when focus is inside the tab list.
list end

WAI-ARIA Roles, States, and Properties
list of 8 items
- The element that serves as the container for the set of tabs has role
tablist.
- Each element that serves as a tab has role
tab
and is contained within the element with role tablist.
- Each element that contains the content panel for a tab has role
tabpanel.
- Each element with role tab has the property
aria-controls
referring to its associated tabpanel element.
- The active tab element has the state
aria-selected
set to true and all other tab elements have it set to false.
- Each element with role tabpanel has the property
aria-labelledby
referring to its associated tab element.
- If a tab element has a pop-up menu, it has the property
aria-haspopup
set to true.
- If the tablist element is vertically oriented, it has the property
aria-orientation
set to vertical. The default value of aria-orientation for a tablist element is horizontal.
list end

Sorry if the links did not come through correctly for the examples.

Sean

From: Birkir R. Gunnarsson
Date: Wed, Sep 27 2017 5:58AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

There are two problems with nesting tabs and tabpanels in a tablist:

1. The screen reader announcement of the number of tabs in the tablist
is inaccurate (because both the tabs and the tabpanels are in the
tablist).
2. If the active tabpanel is displayed before tabs ths uer may find it
difficult to locate/discover the other tabs (think of a situation
where tabpenel 1 is displayed after tab 1 but before tabs 2 and 3).
ON desktop this is ok, provided that the arrow key navigation was
implemented, but on responsive devices without a keyboard, the user
may have a very hard time finding the tabs after that tabpanel.
3. The ARIA spec is too vague, I am not sure if an element with
role="tablist' is allowed to have children whose role is not tab. The
spec says the tablist role must have at least one child with
role="tab" but the required wned elements section does not say whether
it is allowed to have descendant elements with other roles.
The spec should make this clear.



On 9/27/17, Mohith BP < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Mark,
>
> I agree with you regarding the unnecessary navigation.
> The suggestion you proposed works good provided:
> 1. Initially none of the tabs are expanded so that the user can
> navigate between the list of tabs in both brows and focus modes.
> 2. Once one of the tab is activated, the user should be able to
> navigate between the list of tabs without encountering the expanded
> tab panel. I think at least in focus mode this can be achieved.
>
> We have implemented the following:
> 1. Tabs and tabpanel are arranged in the treditional order (as you
> explained in first scenario).
> 2. In the list of tabs when enter is pressed to activate the tab the
> focus is automatically moved to the beginning of the tab panel with
> JAVA script.
> 3. Pressing shift + tab from the tab panel brings back the focus to
> the active tab in the tablist.
>
> Note: This still has other issues such as if tab panel has any
> actionable elements, focus cannot be brought back to the active tab as
> logical tab focus need to be maintained.
>
> Proposal of providing a skip link at the end of the tabpanel back to
> the tablist was mostly rejected by designers.
>
>
> Thanks & Regards,
> Mohith B. P.
>
> On 9/27/17, Mark Magennis < = EMAIL ADDRESS REMOVED = > wrote:
>> Hi everyone.
>>
>> I've a question about how tabbed interfaces work with a screen reader.
>> Usually, it seems, the tabs are in a list which is followed by a bunch of
>> divs, each containing a tab panel. If so, when the user activates a tab
>> and
>> its panel opens, in order to get to the content (leaving aside the JAWS
>> Ins+Alt+M shortcut as it's only JAWS), they have to arrow down through the
>> remaining tabs first.
>>
>> This seems unintuitive. It would seem more natural that when you open a
>> tab,
>> it's contents appear immediately after it, not with all the other tabs in
>> between. So instead of this ordering:
>>
>> Tab 1
>> Tab 2
>> Tab 3
>> Tab 1 panel
>> Tab 2 panel
>> Tab 3 panel
>>
>> you would have this:
>>
>> Tab 1
>> Tab 1 panel
>> Tab 2
>> Tab 2 panel
>> Tab 3
>> Tab 2 panel
>>
>> In both cases, of course, only the open panel would be exposed.
>>
>> I'm wondering has anyone tried to do it this way? Does anything think it's
>> worth doing it this way, or is it likely to cause other usability
>> problems?
>> Should it just be accepted that the panels normally come after the whole
>> tab
>> list?
>>
>> If anyone has done it this other way, then I'd be interested in seeing
>> how.
>> It seems it would involve placing the panel directly after the tab in the
>> DOM, but because the tab is a list item, this would make the panel its
>> child
>> would it? Which sounds strange.
>>
>> Thanks,
>> Mark
>>
>> Mark Magennis | Accessibility Support Manager
>> InterAccess.ie <http://interaccess.ie/>; - Accessible UX
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Sailesh Panchang
Date: Wed, Sep 27 2017 8:41AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

Birkir,
I think the definitions are quite clear:
Tablist: A list of tab elements, which are references to tabpanel elements.

Tabpanel: A container for the resources associated with a tab, where
each tab is contained in a tablist.

tablist elements are typically placed near, usually preceding, a
series of tabpanel elements.
(From the ARIA 1.1 Oct 2016 candidate rec.)
Sorry I do not see the vagueness you attributed to the descriptions
of the roles. Please can you point me to that content?
Thanks and Best regards,


On 9/27/17, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> There are two problems with nesting tabs and tabpanels in a tablist:
>
> 1. The screen reader announcement of the number of tabs in the tablist
> is inaccurate (because both the tabs and the tabpanels are in the
> tablist).
> 2. If the active tabpanel is displayed before tabs ths uer may find it
> difficult to locate/discover the other tabs (think of a situation
> where tabpenel 1 is displayed after tab 1 but before tabs 2 and 3).
> ON desktop this is ok, provided that the arrow key navigation was
> implemented, but on responsive devices without a keyboard, the user
> may have a very hard time finding the tabs after that tabpanel.
> 3. The ARIA spec is too vague, I am not sure if an element with
> role="tablist' is allowed to have children whose role is not tab. The
> spec says the tablist role must have at least one child with
> role="tab" but the required wned elements section does not say whether
> it is allowed to have descendant elements with other roles.
> The spec should make this clear.
>
>
>
> On 9/27/17, Mohith BP < = EMAIL ADDRESS REMOVED = > wrote:
>> Hi Mark,
>>
>> I agree with you regarding the unnecessary navigation.
>> The suggestion you proposed works good provided:
>> 1. Initially none of the tabs are expanded so that the user can
>> navigate between the list of tabs in both brows and focus modes.
>> 2. Once one of the tab is activated, the user should be able to
>> navigate between the list of tabs without encountering the expanded
>> tab panel. I think at least in focus mode this can be achieved.
>>
>> We have implemented the following:
>> 1. Tabs and tabpanel are arranged in the treditional order (as you
>> explained in first scenario).
>> 2. In the list of tabs when enter is pressed to activate the tab the
>> focus is automatically moved to the beginning of the tab panel with
>> JAVA script.
>> 3. Pressing shift + tab from the tab panel brings back the focus to
>> the active tab in the tablist.
>>
>> Note: This still has other issues such as if tab panel has any
>> actionable elements, focus cannot be brought back to the active tab as
>> logical tab focus need to be maintained.
>>
>> Proposal of providing a skip link at the end of the tabpanel back to
>> the tablist was mostly rejected by designers.
>>
>>
>> Thanks & Regards,
>> Mohith B. P.
>>
>> On 9/27/17, Mark Magennis < = EMAIL ADDRESS REMOVED = > wrote:
>>> Hi everyone.
>>>
>>> I've a question about how tabbed interfaces work with a screen reader.
>>> Usually, it seems, the tabs are in a list which is followed by a bunch of
>>> divs, each containing a tab panel. If so, when the user activates a tab
>>> and
>>> its panel opens, in order to get to the content (leaving aside the JAWS
>>> Ins+Alt+M shortcut as it's only JAWS), they have to arrow down through
>>> the
>>> remaining tabs first.
>>>
>>> This seems unintuitive. It would seem more natural that when you open a
>>> tab,
>>> it's contents appear immediately after it, not with all the other tabs in
>>> between. So instead of this ordering:
>>>
>>> Tab 1
>>> Tab 2
>>> Tab 3
>>> Tab 1 panel
>>> Tab 2 panel
>>> Tab 3 panel
>>>
>>> you would have this:
>>>
>>> Tab 1
>>> Tab 1 panel
>>> Tab 2
>>> Tab 2 panel
>>> Tab 3
>>> Tab 2 panel
>>>
>>> In both cases, of course, only the open panel would be exposed.
>>>
>>> I'm wondering has anyone tried to do it this way? Does anything think
>>> it's
>>> worth doing it this way, or is it likely to cause other usability
>>> problems?
>>> Should it just be accepted that the panels normally come after the whole
>>> tab
>>> list?
>>>
>>> If anyone has done it this other way, then I'd be interested in seeing
>>> how.
>>> It seems it would involve placing the panel directly after the tab in the
>>> DOM, but because the tab is a list item, this would make the panel its
>>> child
>>> would it? Which sounds strange.
>>>
>>> Thanks,
>>> Mark
>>>
>>> Mark Magennis | Accessibility Support Manager
>>> InterAccess.ie <http://interaccess.ie/>; - Accessible UX
>>> >>> >>> >>> >>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >


--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765

From: Mark Magennis
Date: Wed, Sep 27 2017 8:49AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

Thanks for the reply Mohith.

> The suggestion you proposed works good provided:
> 1. Initially none of the tabs are expanded

I see your point, and it arises whenever a panel (except the last) is open. But it only means that the tab group works as a single element in focus mode only but not in browse mode.

> 2. In the list of tabs when enter is pressed to activate the tab the
> focus is automatically moved to the beginning of the tab panel with
> JAVA script.

Okay, although this method only works if the Enter key press is required to open a tab panel, not if it opens when the tab receives focus.

> Proposal of providing a skip link at the end of the tabpanel back to
> the tablist was mostly rejected by designers.

On what grounds did they reject it? Wouldn't any arguments for and against it be the same as those for a skip link at the top of the page?

Mark

Mark Magennis | Accessibility Support Manager
InterAccess.ie <http://interaccess.ie/>; - Accessible UX

From: Mark Magennis
Date: Wed, Sep 27 2017 8:50AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

Thanks Birkir. Announcing the incorrect number of tabs would indeed be a problem.

A question about your other point:

> ON desktop this is ok, provided that the arrow key navigation was
> implemented, but on responsive devices without a keyboard, the user
> may have a very hard time finding the tabs after that tabpanel.

So what you're saying is that on touchscreens you don't have the opportunity of implementing a 'focus mode' tab list navigation because there is no 'focus mode'. Have I got that right?

Mark

Mark Magennis | Accessibility Support Manager
InterAccess.ie <http://interaccess.ie/>; - Accessible UX

From: Mark Magennis
Date: Wed, Sep 27 2017 8:50AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

I'm assessing an implementation here where, when a tab is selected using Enter, all tabs are given aria-hidden="true". This means that arrowing down skips past them to the open panel. The problem is, the tabs are never unhidden, so they are subsequently completely inaccessible.

I wonder is there a good way of clearing aria-hidden when the user has skipped past the hidden tabs? I guess this would involve clearing it when user enters the tab panel and when the user TABs or SHIFT+TABs out of the tab list.

Is it feasible to do this using JS in a reliable way that doesn't have unwanted side effects?

Mark

Mark Magennis | Accessibility Support Manager
InterAccess.ie <http://interaccess.ie/>; - Accessible UX

From: Birkir R. Gunnarsson
Date: Wed, Sep 27 2017 8:59AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

Mark
What I would do to rsolve his is to give all tabpanels a tabindex of
0. That way the user can reliably navigate from the tab to the
tabpanel by pressing the tab key (only the active tab is in the focus
order) (see why the label "tab" is so confusing, it applies to the tab
panel, the tab control and the tab key).
Yes, on touch-screen devices you don't have the benefit of using arrow
keys to jump between tabs (at least not on iOS), you cannot alter the
swipe order on those devices (except possibly though some serious
manipulation of the aria-owns attribute which I suspect would not
work).

Sailesh, good points. I was looking primarily at the "required owned
elements" section of the spec (I can dig up the exact link later).
I just wish the spec would use a clearer language, so that, e.g. aXe
(or any accessibility checker) would fail an element with
role="tablist" that contains an element with role="tabpanel" (or any
element that does not have either role="presentation" or role="tab").
When I was providing aXe feedback I brought up this idea but, based on
my memory, the team did not feel the spec was explicit enough to add
this check.
This would also address the question of tabs and tabpanels. If a
tablist cannot contain an element with role tabpanel, you can't
implement tabs accordion style.



On 9/27/17, Mark Magennis < = EMAIL ADDRESS REMOVED = > wrote:
> I'm assessing an implementation here where, when a tab is selected using
> Enter, all tabs are given aria-hidden="true". This means that arrowing down
> skips past them to the open panel. The problem is, the tabs are never
> unhidden, so they are subsequently completely inaccessible.
>
> I wonder is there a good way of clearing aria-hidden when the user has
> skipped past the hidden tabs? I guess this would involve clearing it when
> user enters the tab panel and when the user TABs or SHIFT+TABs out of the
> tab list.
>
> Is it feasible to do this using JS in a reliable way that doesn't have
> unwanted side effects?
>
> Mark
>
> Mark Magennis | Accessibility Support Manager
> InterAccess.ie <http://interaccess.ie/>; - Accessible UX
> > > > >


--
Work hard. Have fun. Make history.

From: Sailesh Panchang
Date: Wed, Sep 27 2017 10:42AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

Mark,
The tab panels all (except the active tab) have to be hidden ie. not
rendered for all users so display: none should be toggled. No use for
aria-hidden IMO.

Birkir-
For tablist the 'required owned' is only tab ... so that's quite clear.
Accordion is a different UI. It is pretty much a list of links
stacked vertically with expand/collapse functionality. The authoring
guide too describes it in this manner.
Yes there are similarities but if the intent is an accordion, then one
should not use tablist, tabpanel ... that will confuse users because
tabs are generally horizontal. One does not have multi select on tabs
generally but it is more common in accordions.
Best wishes,

On 9/27/17, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> Mark
> What I would do to rsolve his is to give all tabpanels a tabindex of
> 0. That way the user can reliably navigate from the tab to the
> tabpanel by pressing the tab key (only the active tab is in the focus
> order) (see why the label "tab" is so confusing, it applies to the tab
> panel, the tab control and the tab key).
> Yes, on touch-screen devices you don't have the benefit of using arrow
> keys to jump between tabs (at least not on iOS), you cannot alter the
> swipe order on those devices (except possibly though some serious
> manipulation of the aria-owns attribute which I suspect would not
> work).
>
> Sailesh, good points. I was looking primarily at the "required owned
> elements" section of the spec (I can dig up the exact link later).
> I just wish the spec would use a clearer language, so that, e.g. aXe
> (or any accessibility checker) would fail an element with
> role="tablist" that contains an element with role="tabpanel" (or any
> element that does not have either role="presentation" or role="tab").
> When I was providing aXe feedback I brought up this idea but, based on
> my memory, the team did not feel the spec was explicit enough to add
> this check.
> This would also address the question of tabs and tabpanels. If a
> tablist cannot contain an element with role tabpanel, you can't
> implement tabs accordion style.
>
>
>
> On 9/27/17, Mark Magennis < = EMAIL ADDRESS REMOVED = > wrote:
>> I'm assessing an implementation here where, when a tab is selected using
>> Enter, all tabs are given aria-hidden="true". This means that arrowing
>> down
>> skips past them to the open panel. The problem is, the tabs are never
>> unhidden, so they are subsequently completely inaccessible.
>>
>> I wonder is there a good way of clearing aria-hidden when the user has
>> skipped past the hidden tabs? I guess this would involve clearing it when
>> user enters the tab panel and when the user TABs or SHIFT+TABs out of the
>> tab list.
>>
>> Is it feasible to do this using JS in a reliable way that doesn't have
>> unwanted side effects?
>>
>> Mark
>>
>> Mark Magennis | Accessibility Support Manager
>> InterAccess.ie <http://interaccess.ie/>; - Accessible UX
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >


--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765

From: Mark Magennis
Date: Thu, Sep 28 2017 1:52AM
Subject: Re: Navigating from tab to tab panel
← Previous message | Next message →

The language does make this confusing and I think you misunderstood me Sailesh. In the non-working solution I mentioned, it is the tab buttons that are temporarily hidden, not the tab panels. As you say, the closed tab panels are always hidden. I say "temporarily" because that seems to be the intent, except the developers seem to have forgotten to unhide them. The idea behind this approach is that when the screen reader user opens a tab panel by activating its tab button, it appears as if the tab panel comes immediately after its tab button. No need to go through the other buttons to get there. I think this is a good idea, but it involves unhiding the hidden tab buttons after the user has moved. Now that I think about this even more though, I guess its possible that a user may decide to open a different panel before moving (say they realise they accidentally clicked the wrong tab button, or they just change their mind). Having to move away and back again in order to make the other tab buttons spring back into life would be strange to say the least and it would be obvious that there is some kind of voodoo going on, which is always a bit disconcerting I think.

Anyways, thanks guys for the suggestions.

Mark

Mark Magennis | Accessibility Support Manager
InterAccess.ie <http://interaccess.ie/>; - Accessible UX

> On 27 Sep 2017, at 17:42, Sailesh Panchang < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >> wrote:
>
> Mark,
> The tab panels all (except the active tab) have to be hidden ie. not
> rendered for all users so display: none should be toggled. No use for
> aria-hidden IMO.

From: Birkir R. Gunnarsson
Date: Thu, Sep 28 2017 9:47AM
Subject: Re: Navigating from tab to tab panel
← Previous message | No next message

Mark

The screen reader user would only have to move past a couple of tab
controls to get to the tabpanel (anywhere from 0 to maybe 5 or 6, at
least I have not seen more tabs in a tabbed interface). By correctly
using aria-controls you are also offering screen readers the ability
to take users straight to the tabpanel (sadly only Jaws implements
functionality for this attribute, but we can file issues to get more
vendors to take advantage). If you make the tabpanel focusable the
user can also get directly to it fro mthe tab by pressing the tab key
(assuming the tabpanel is located next to the tabs in the page csource
code order).

Contrast this with putting the the user having to navigate through all
the contents of a tabpanel to get to the remaining tabs (e.g. if tab 1
is activated, the order is tab1, tabpanel1, tab 2, tab 3). A tabpanel
can contain a lot of data with headings and links and stuff, and there
is no easy way for the user to jump directly past it to tabs 2 and 3.

It is certainly hard to implement the perfect interface for all users,
but I think between these two approaches keeping the tabs together is
the better approach (plus it is semantically correct while the other
is not per the ARIA standard).



On 9/28/17, Mark Magennis < = EMAIL ADDRESS REMOVED = > wrote:
> The language does make this confusing and I think you misunderstood me
> Sailesh. In the non-working solution I mentioned, it is the tab buttons that
> are temporarily hidden, not the tab panels. As you say, the closed tab
> panels are always hidden. I say "temporarily" because that seems to be the
> intent, except the developers seem to have forgotten to unhide them. The
> idea behind this approach is that when the screen reader user opens a tab
> panel by activating its tab button, it appears as if the tab panel comes
> immediately after its tab button. No need to go through the other buttons to
> get there. I think this is a good idea, but it involves unhiding the hidden
> tab buttons after the user has moved. Now that I think about this even more
> though, I guess its possible that a user may decide to open a different
> panel before moving (say they realise they accidentally clicked the wrong
> tab button, or they just change their mind). Having to move away and back
> again in order to make the other tab buttons spring back into life would be
> strange to say the least and it would be obvious that there is some kind of
> voodoo going on, which is always a bit disconcerting I think.
>
> Anyways, thanks guys for the suggestions.
>
> Mark
>
> Mark Magennis | Accessibility Support Manager
> InterAccess.ie <http://interaccess.ie/>; - Accessible UX
>
>> On 27 Sep 2017, at 17:42, Sailesh Panchang < = EMAIL ADDRESS REMOVED =
>> <mailto: = EMAIL ADDRESS REMOVED = >> wrote:
>>
>> Mark,
>> The tab panels all (except the active tab) have to be hidden ie. not
>> rendered for all users so display: none should be toggled. No use for
>> aria-hidden IMO.
> > > > >


--
Work hard. Have fun. Make history.