- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 18 Jul 2016 12:59:37 -0500
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, ARIA Working Group <public-aria@w3.org>
- Message-ID: <CAKdCpxy=ESs0x3Us_kfYTDMHaK4t+PpiUk6xqbP5j+Ozpdt5aw@mail.gmail.com>
Steve wrote: > > Also buttons should be actionable using both the enter and spacebar keys right? 'Should" as a Best practice, yes. RFC 2119 SHOULD , as in mandated by WCAG 2.0? No, there is nothing in WCAG 2.0 that mandates this functionality. We might consider a new SC in WCAG 2.1 that would get us to something like that, although I'd probably suggest we look to have it be a 4.x.x SC, as "robustness" is more of the issue I believe: when you author something and call it a button, there is an implied expectation that the button will act like a native button, but we never explicitly call that out in WCAG 2.0. AFAIK JF On Mon, Jul 18, 2016 at 2:09 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote: > a potential issue (i think) is that keyboard users have to tab through > every focusable element in an open panel to expand the next panel. Why not > allow enter to both expand and collapse the currently focused button? Also > buttons should be actionable using both the enter and spacebar keys right? > > -- > > Regards > > SteveF > Current Standards Work @W3C > <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/> > > On 18 July 2016 at 07:56, Bryan Garaventa < > bryan.garaventa@ssbbartgroup.com> wrote: > >> Okay, files moved, please try this again... >> >> Live page: >> http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm >> >> Download: >> http://whatsock.com/test/w3c/ARIA%20Accordions.zip >> >> Bryan Garaventa >> Accessibility Fellow >> SSB BART Group, Inc. >> bryan.garaventa@ssbbartgroup.com >> 415.624.2709 (o) >> www.SSBBartGroup.com >> >> -----Original Message----- >> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] >> Sent: Sunday, July 17, 2016 6:28 PM >> To: ARIA Working Group <public-aria@w3.org> >> Subject: Live Code for APG: ARIA Accordion design pattern ready for review >> >> Hi, >> The code for the accordion wireframe is ready, which can be tested at >> http://snoringfoot.dyndns.org/Webserver/ARIA%20Accordions/demo.htm >> >> At present this is just the coded implementation since my primary >> objective was to simply build out what works first, then document it after >> we finish any tweaks. For this reason, I'm hosting this temporarily on a >> test server. >> >> Also, you can download this zip file at >> http://snoringfoot.dyndns.org/ >> >> Included within this is a vanilla JavaScript helpers lib I've cobbled >> together over some years now, which should aid in the process for building >> out these widgets in the future. This is included within the file >> "helpers.js'. >> >> The design pattern uses the new model for Accordions, which is the use of >> individually focusable toggles in combination with aria-expanded to convey >> the active state of each toggle. >> >> The setup for this type of implementation is automatically scalable, >> meaning that it can include any type of embedded control type within the >> dynamically expandable sections, including other complex ARIA widget >> controls, or even embedded accordion controls to nest functionality. This >> is why the named regions are important for intuitive grouping. >> >> This too works on mobile touch screen devices, and within setup.js, >> redundant event handling shows how the same script can be applied to >> non-native triggering elements such as Div or Span elements in place of >> native links or buttons for use as accordion toggles. >> >> Within this demo, the styling and content are just what I've thrown >> together, but all can be changed however you like. It probably needs some >> positioning work for the accordion section content for instance. The >> triggering elements are presently A tags, but these can be changed to >> native buttons, or even simulated elements like Div or Span with >> tabindex='0' and role='button', and the scripting will still work >> accessibly. >> >> Also, please feel free to use the helpers.js file for whatever you wish >> as well, it may make this process go faster. >> >> All the best, >> Bryan >> >> >> >> >> Bryan Garaventa >> Accessibility Fellow >> SSB BART Group, Inc. >> bryan.garaventa@ssbbartgroup.com >> 415.624.2709 (o) >> www.SSBBartGroup.com >> >> >> >> > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Monday, 18 July 2016 18:00:09 UTC