RE: Tab Panel focus movement with Dynamic content.

Matt, thanks for sharing the editor's draft. I have a couple of questions for
clarification, that appear not to be addressed in the draft.

 

What Tab Widget guidance is offered to maintain a consistent navigation and page
structure?

 

First, should the Tab widget use an open or Dialog wrap around model:

- With focus on any Tab element in the TabList, pressing Shift+Tab moves focus
to the previous page element.

- With the focus on a Tab in the TabList, pressing Tab key move focus to the
first focusable element in the TabPanel, and then Shift+Tab moves focus back to
the TabList.

- With focus in the TabPanel, pressing Tab or Shift+Tab moves focus through
TabPanel elements.

- With the focus on the last TabPanel element, pressing Tab key moves focus to
the next page element or back to the first TabPanel element or back to the
TabList? If to the next page element, will the user know that they are leaving
the TabPanel (which is the expected behaviour for other page elements)? If wrap
around, then how do you get to the next page element (Escape key could close the
TabPanel, but this may conflict with elements like Combo boxes within the
TabPanel) or a Close Button could be used.

 

Second, the Heading hierarchy within the TabPanel may break the underlying page
heading structure, but if a Dialog model is used this is not a problem. Also, a
TabPanel may contain a lot of content, even child TabList/TabPanels, and a
region Landmark structure could be used to organize content relationships. Does
the draft offer any recommendations for Tab widget content structure?

 

Thanks!

David

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: February 28, 2017 12:12 PM
To: davebest@cogeco.ca; 'Morten Tollefsen'; 'Sean Murphy (seanmmur)';
w3c-wai-ig@w3.org
Subject: RE: Tab Panel focus movement with Dynamic content.

 

Please, please pay attention to the versions of documents you are reading. This
thread references a practices guide from 2009. That document was never
completed. It was not fully reviewed and thus its content is not backed by ARIA
working group consensus.

 

While we do not not yet have a completed practices guide for ARIA, we do have
very active work in that direction. Most of the current editors draft has
completed its review processes. The parts that have not are flagged by links to
github issues. So, unntil we have a complete version of authoring practices, I
recommend studying the editor's draft at:

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

 

@David, please be cautious when making recommendations based on the behaviors of
a specific screen reader. Once we have consensus regarding best practice for a
pattern and its reference implentations in the ARIA Authoring Practices, you
will be able to assess the quality of the screen reader by the quality of
experience it provides when using the reference implementation of a pattern
(assuming no browser bugs).

 

Matt King

 

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

 

I have read the WAI-ARIA Best Practices document tab panels section and, not
only very confusing, I have yet to find a web page that follows this model. I
support the WAI model, but for simplistity and ease of use, I suggest a slight
variation. If WAI has a keyboard plugin component event handler for TabPanels,
then we could reasonably expect a more consistent behaviour by recommending that
technique model. My reasoning:

 

1. Spacebar is typically used to change state (Button on/off, Checkbox
checked/unchecked, ...), and Enter key is used to activate page content updates
(Links, Modals, ...). Spacebar and Enter key can be used for some elemetns, like
Buttons, but I feel this is teaching users bad habits.

 

2. The TabList keyboard instructions say that pressing Left/Right Arrow keys
will move the focus between Tab items and activate the TabPanel. However, this
depends upon the type of TabPanel content. The Left/Right Arrow key should be
used to reveal (Show/Hide) TabPanel state, and not load new TabPanel container
content. In this case, the Left/Right Arrow keys should activate an TabPanel
aria-alert. Alternatively, if it is a large page with many Tab items, Spacebar
could be used to activate the TabPanel aria-alert and Show/Hide state. Enter key
typically loads new page content, so the expected behaviour would be to press
Enter key on a TabList Tab item to load the new TabPanel container content and
move focus to the TabPanel. In some cases, like with JAWS, the Enter key pops
the user out of Forms Mode and does not change the focus position, which then
changes the Left/Right Arrow key responses and confuses the user.

 

I believe we need a basic keyboard behaviour, with the option of other key
commands for advanced users. In my experience, it is a challenge to get most
developers to just understand the basic keyboard command requirements, but I
agree a consistent WAI widget keyboard model should be prefered.

David

 

 

From: Morten Tollefsen [mailto:morten@medialt.no] 
Sent: February 28, 2017 05:09 AM
To: Sean Murphy (seanmmur); davebest@cogeco.ca; w3c-wai-ig@w3.org
Subject: 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,  <http://www.medialt.no> 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
<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

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,  <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>; 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

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.