W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2017

RE: Tab Panel focus movement with Dynamic content.

From: Karen Lewellen <klewellen@shellworld.net>
Date: Tue, 28 Feb 2017 12:05:57 -0500 (EST)
To: David Best <davebest@cogeco.ca>
cc: 'Morten Tollefsen' <morten@medialt.no>, "'Sean Murphy (seanmmur)'" <seanmmur@cisco.com>, w3c-wai-ig@w3.org
Message-ID: <Pine.LNX.4.64.1702281201440.10794@server2.shellworld.net>
Just a single comment.  I am always concerned about a generalization 
regarding 
what is typically done, certainly the suggestion of teaching a user, who 
you do not know, a habit bad or otherwise.
Speaking only for myself, I use the enter key for checking items, and have 
personally never used a site that would do the same with the space 
bar..but that is me.
Opting for a flexible response makes sense to me.  claiming to teach to 
those whose  technology experiences you know nothing of seems 
disrespectful.
Back to the corner smiles,
Kare


On Tue, 28 Feb 2017, David Best wrote:

> 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.
>
>
>
>
Received on Tuesday, 28 February 2017 17:06:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 February 2017 17:06:29 UTC