SV: Tab Panel focus movement with Dynamic content.

Hi.

I know: the suggestion is not the same as WAI-ARIA Best Practices<http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/>.

What I like with Davids solution is:
- Simpler to learn, use and implement.
- Doesn't use the same keys as typically used in browsers and screen readers. E. g. Jaws use Ctrl+PgUp/Dn.
- Arrow keys do not select the pane: a good solution for screen readers because you're able to check panes without selecting (even if forms mode). This is not important if the content is loaded very fast, however if content is not loaded fast it is time consuming to check available panes. The same is true for keyboard users: they do not have to wait until content is loaded for each tab when using arrow keys.



Br: Morten Tollefsen
90899305, www.medialt.no<http://www.medialt.no>

Fra: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com]
Sendt: tirsdag 28. februar 2017 10.51
Til: Morten Tollefsen <morten@medialt.no>; davebest@cogeco.ca; w3c-wai-ig@w3.org
Emne: 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 tabpanel<http://www.w3.org/WAI/PF/aria/#tabpanel>.
  *   The tabbed panel contains tabs and their panels. An element with role tab<http://www.w3.org/WAI/PF/aria/#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 tablist<http://www.w3.org/WAI/PF/aria/#tablist> is the container role for a set of elements with the role attribute set to tab<http://www.w3.org/WAI/PF/aria/#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
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; Sean Murphy (seanmmur) <seanmmur@cisco.com>; 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, www.medialt.no<http://www.medialt.no>

Fra: David Best [mailto:davebest@cogeco.ca]
Sendt: tirsdag 28. februar 2017 07.51
Til: 'Sean Murphy (seanmmur)' <seanmmur@cisco.com>; 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
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.