RE: Tab Panel focus movement with Dynamic content.

David,

 

The ARIA Authoring Practices design patterns do not address integration of
the pattern into the larger page structure. Most integration issues are
common across patterns. While the practices do not yet holistically address
integration, some aspects of integration are addressed in the landmark and
keyboard sections. More sections that cover integration will eventually be
included.

 

The integration patterns you mentioned are valid. You can put a tabbed
interface inside of a dialog, inside of a section of a page (which may or
may not be a landmark region), or tabs can be used as the primary navigation
for a site. And, of course, you can nest a tabbed interface inside the
tabpanel of another tabbed interface.

 

If your interaction design calls for a contained tab ring such that tabbing
out of the tabpanel returns focus to the tablist, then you would need to put
the tabs inside of a window (dialog in ARIA parlance). That dialog could be
modal or non-modal, as needed.

 

If tabs are part of the site navigation, then efficient means for moving
focus to the tablist would be part of your site wide keyboard navigation
scheme.

 

I don't know that it is always necessary for screen reader users to be aware
of when focus has moved outside a tabpanel, especially when moving focus
with the tab key. In my experience, such announcements appear to distract
people more than they help them. But, that is not a statement based on
formal research. And,  I would venture to guess  that the importance of such
transitions would likely vary meaningfully across implementations.

 

On the other hand, I assume most screen readers will eventually enable their
users to be aware of tabpanel boundaries when navigating with a reading
cursor. Currently, JAWS is the only screen reader that renders the panel
boundaries when reading. JAWS 17 and several earlier did this. It seems that
has regressed in JAWS 18. 

 

Matt

 

From: David Best [mailto:davebest@cogeco.ca] 
Sent: Wednesday, March 8, 2017 11:33 AM
To: davebest@cogeco.ca; 'Matt King' <a11ythinker@gmail.com>; 'Morten
Tollefsen' <morten@medialt.no>; 'Sean Murphy (seanmmur)'
<seanmmur@cisco.com>; w3c-wai-ig@w3.org
Cc: naomib@google.com; karakara@google.com; jelbourn@google.com
Subject: 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 <mailto:davebest@cogeco.ca> ; 'Morten Tollefsen';
'Sean Murphy (seanmmur)'; w3c-wai-ig@w3.org <mailto: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 <mailto:morten@medialt.no> >;
'Sean Murphy (seanmmur)' <seanmmur@cisco.com <mailto:seanmmur@cisco.com> >;
w3c-wai-ig@w3.org <mailto: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 <mailto:davebest@cogeco.ca> ;
w3c-wai-ig@w3.org <mailto: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 <mailto:morten@medialt.no> >;
davebest@cogeco.ca <mailto:davebest@cogeco.ca> ; w3c-wai-ig@w3.org
<mailto: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 <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.