RE: Tab Panel focus movement with Dynamic content.

That was a draft of guidance that did not have working group consensuss.

Please study the editor's draft at:

http://w3c.github.io/aria-practices/

 

From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com] 
Sent: Tuesday, February 28, 2017 1:51 AM
To: Morten Tollefsen <morten@medialt.no>; davebest@cogeco.ca;
w3c-wai-ig@w3.org
Subject: RE: Tab Panel focus movement with Dynamic content.

 

Guys,

 

 

thanks for your information. The methods you have outlined is different then
from what the WAI-ARIA Best Practices
<http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/>  document on the
tab panels section refers too. I have provided the related extract:

 

Tab Panel (widget)


Characteristics: 


Description: 

A tabbed interface component is a container for resources associated with a
tab. It is a set of layered pages where only one page is displayed at a
time. The general look is similar to a file folder with a "tab" that
contains the title of the folder. The tabs are arranged along one of the
edges of the contents but most commonly are found at the top of the page.
The user navigates and makes the contents of each page visible by
interacting with the title "tab" of the page. Sometimes referred to as a tab
container or tab panel. Terms for understanding Tab Panels include:

tabbed interface component

a set of tabs and associated tab panels 

tab panel

contents area that is associated with a tab

tab

the label/title area of the tab panel. This is where you click to activate a
tab panel 

tablist

the set of tabs

When the user activates a tab, the contents of that tab is made visible. The
tab is considered "active". The tab remains active until another tab is
activated. The active tab is placed into the tab order. Only the active tab
should be in the tab order. A default tab is specified that is active when
the tabbed interface component is initialized. A collection of tabs and
their associated tab panels is a complex widget, because it performs
show/hide actions as well as moving the user's point of regard around within
the content. 


Keyboard Interaction: 

*	Tab - only the active tab is in the tab order. The user reaches the
tabbed panel component by pressing the tab key until the active tab title
receives focus. 
*	Left Arrow - with focus on a tab, pressing the left arrow will move
focus to the previous tab in the tab list and activate that tab. Pressing
the left arrow when the focus is on the first tab in the tab list will move
focus and activate the last tab in the list. 
*	Right Arrow - with focus on a tab, pressing the right arrow will
move focus to the next tab in the tab list and activate that tab. Pressing
the right arrow when the focus is on the last tab in the tab list will move
focus to and activate the first tab in the list. 
*	Up arrow - behaves the same as left arrow in order to support
vertical tabs 
*	Down arrow - behaves the same as right arrow in order to support
vertical tabs 
*	Ctrl+Up Arrow - with focus anywhere within the tab panel, pressing
Ctrl+Up Arrow will move focus to the tab for that panel. This is not
standard behavior - is this something we want to implement? Is it necessary
if we provide a mechanism to change the active tab? Similar to
Ctrl+PageUp/Ctrl+PageDown in Firefox to switch tabs? 
*	Alt+Del - When deletion is allowed, with focus anywhere within the
tab panel, pressing alt-del will delete the current tab and tab panel from
the tabbed interface control. If additional tabs remain in the tabbed
interface, focus goes to the next tab in the tab list. An alternative to
providing a keystroke to close a tab is to provide a context menu that is
associated with the tab title. When focus is on the tab, pressing Shift+F10
or pressing the right mouse button will open a context menu with the close
choice 
*	Ctrl+PageUp - When focus is inside of a tab panel, pressing
Ctrl+PageUp moves focus to the tab of the previous tab in the tab list and
activates that tab. When focus is in the first tab panel in the tab list,
pressing Ctrl+PageUp will move focus to the last tab in the tab list and
activate that tab. 
*	Ctrl+PageDown When focus is inside of a tab panel, pressing
Ctrl+PageDown moves focus to the tab of the next tab in the tab list and
activates that tab. When focus is in the last tab panel in the tab list,
pressing Ctrl+PageUpwill move focus to the first tab in the tab list and
activate that tab. 

Regarding Ctrl+PageUp/Ctrl+PageDown. This is currently implemented in
Firefox to move between browser tabs. Firefox also supports Ctrl+Tab and
Ctrl+Shift+Tab to move between tabs. Internet Explorer 7 also uses Ctrl+Tab
and Ctrl+Shift+Tab. There may be advantages to using
Ctrl+PageUp/Ctrl+PageDown as the keys to change tabs since it is a
recognizable keystroke to at least Firefox users and is also supported by
the Windows operating system to move between panels in a tabbed dialog. The
problem is that if the user is within a tabbed interface control on a Web
page, they can not easily switch browser tabs without first moving focus
outside of the tabbed interface control. This may be acceptable. The other
issue is if the entire Web page is a tabbed interface control - in that case
the user could not ever switch browser tabs unless the control on the Web
page ignored the Ctrl+PageUp/Ctrl+PageDown keypress (and thus letting the
browser access it) when the first or last tab was reached. 


ARIA Roles, States, and Properties: 

*	The tabbed interface component uses the role
<http://www.w3.org/WAI/PF/aria/#tabpanel> tabpanel. 
*	The tabbed panel contains tabs and their panels. An element with
role  <http://www.w3.org/WAI/PF/aria/#tab> tab is used as a grouping label,
providing a link for selecting the tabcontent to be rendered to the user. 
*	The currently selected tab has the state selected=true. 
*	A  <http://www.w3.org/WAI/PF/aria/#tablist> tablist is the container
role for a set of elements with the role attribute set to
<http://www.w3.org/WAI/PF/aria/#tab> tab. 

 

 

Based upon the above, spacebar and enter is not a part of the keyboard
navigation. I found it interesting the reference to ctrl page up and ctrl
page down to switch between tabs. I don't think I have ever seen this
implemented with all the above keyboard commands. Based upon the information
above, the  focus does not move to the first focusable element until the
user presses tab. This aligns with how windows navigates dialogs with
multiple tabs.

 

I think this is why users and some developers get confused because there is
no consistent keyboard navigation in controls. I was confused in relation to
the keyboard commands until I read the above and what was posted.

 

 

Sean Murphy

Accessibility Software engineer 

seanmmur@cisco.com <mailto:seanmmur@cisco.com> 

Tel: +61 2 8446 7751       Cisco Systems, Inc.

The Forum 201 Pacific Highway

ST LEONARDS

2065

Australia

cisco.com            

 

 Think before you print.

This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.

 

From: Morten Tollefsen [mailto:morten@medialt.no] 
Sent: Tuesday, 28 February 2017 7:30 PM
To: davebest@cogeco.ca <mailto:davebest@cogeco.ca> ; Sean Murphy (seanmmur)
<seanmmur@cisco.com <mailto:seanmmur@cisco.com> >; w3c-wai-ig@w3.org
<mailto:w3c-wai-ig@w3.org> 
Subject: SV: Tab Panel focus movement with Dynamic content.

 

Hi.

 

Yes, a very good solution for ttabs, David. aria-controls can be used of
course (e. g. Jaws has shortcut keys to move focus). Do you have any
examples of exactly this implementation? 

 

I've not tested tabs very carefully with users, but a small observation:
most users tend to use Enter and Space as similar keys in web interfaces.
This works for buttons, checkboxes etc. Therefore it may be a little bit
confusing that these keys have different behaviour in tablists. But of
course, it is possible to learn this.

 

BR: Morten Tollefsen

90899305,  <http://www.medialt.no> www.medialt.no

 

Fra: David Best [mailto:davebest@cogeco.ca] 
Sendt: tirsdag 28. februar 2017 07.51
Til: 'Sean Murphy (seanmmur)' <seanmmur@cisco.com
<mailto:seanmmur@cisco.com> >; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Emne: RE: Tab Panel focus movement with Dynamic content.

 

Sean, I tend to recommend:

1.	Pressing Left/Right arrow keys in the Tab List moves focus between
the items without selecting.
2.	Pressing Spacebar on a Tab List item, selects the item but does not
move the focus, and an aria-alert reads the Tab Panel heading as it changes.
3.	Pressing Enter key in the Tab List selects the item, moves focus to
the Tab Panel heading and reads it.
4.	Pressing Tab key in the Tab List moves focus to the Tab Panel
heading and reads it.

David

 

From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com] 
Sent: February 28, 2017 12:29 AM
To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Subject: Tab Panel focus movement with Dynamic content.

 

All,

 

What is the best practise if a web page has a tab panel and the content
dynamically updates after the tab is selected? 

 

1.      Should the focus move to the first focusable element?

2.      The focus does not move, leaving it up to the user?

This brings up another question. When should the focus automatically move to
the first focusable element, other than dialogs/pop-ups when dealing with
dynamic content?

 

Sean Murphy

Accessibility Software engineer 

seanmmur@cisco.com <mailto:seanmmur@cisco.com> 

Tel: +61 2 8446 7751       Cisco Systems, Inc.

The Forum 201 Pacific Highway

ST LEONARDS

2065

Australia

cisco.com            

 

 Think before you print.

This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.

 

Received on Tuesday, 28 February 2017 21:44:48 UTC