Re: APG 1.0 entry for accordion is unclear on focus order

True. I just wanted to implement the 1.0 widget to get  feel for it.
I can take on the task or help you do it Bryan, if you need
assistance, just holler.

On 6/30/16, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> Hi,
> All of the ARIA Tab markup is being removed from the APG 1.1 design pattern
> for Accordion, so too is the keyboard functionality per our meeting
> agreement prior to CSUN.
>
> I was asked by Matt this last Monday in the APG call to build out an
> Accordion demo for the new section, am I still on the hook for this?
>
> Thanks,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> bryan.garaventa@ssbbartgroup.com
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
> Sent: Thursday, June 30, 2016 4:38 AM
> To: 'ARIA Working Group' <public-aria@w3.org>
> Subject: APG 1.0 entry for accordion is unclear on focus order
>
> Happy Thursday.
>
> I am coding an accordion using the multi-selectable tab implementation
> recommendation from ARIA APG 1.0 (in preparation for coding an updated
> version for 1.1).
> http://www.w3.org/TR/wai-aria-practices/#accordion
>
> Looking at the documentation, it is unclear to me how to ensure that at
> least one of the tabs in the accordion is in focus order.
> For a single-select tab the APG recommendation says the active tab should be
> in the focus order, simple.
> There is no such recommendation for multi-select tabs in this spec.
> The closest the spec comes to making a recommendation is describing the tab
> key behavior, but it assumes the focus is already on one of the tabs in the
> accordion.
> It says that if focus is on a focusable element in a tabpanel, pressing tab
> will move the focus to the first interactive element in the next open
> tabpanel, or to the first focusable element outside of the accordion if no
> subsequent tabpanel is open.
> This does not allow the focus to land on a tab.
>
> The entry for shift-tab says "Generally the reverse of Tab."
> >From that I conclude that:
> With focus on a focusable element inside an expanded a tabpanel, pressing
> shift-tab will:
> 1. If a previous tab is expanded, focus is moved to the last interactive
> element in that tabpanel.
> 2. If not, focus will move to the previous focusable component outside of
> the accordion.
>
> Neither of these recommendations results in the focus actually landing on a
> tab, which is essential for keyboard navigation to, and operating the
> accordion.
> Am I missing something, or is this one of the things we are fixing in 1.1
> (yes, our 1.1 recommendation for accordions will be both simpler and
> better).
> Thanks
> -B
>
>
>


-- 
Birkir Gunnarsson, CPACC
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Thursday, 30 June 2016 18:24:17 UTC