WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Is a button that does not support space bar activation a violation of WCAG?

for

From: Sean Curtis
Date: May 6, 2015 8:02PM

http://jsbin.com/nofila/2/

Spacebar works on all of them (in Chrome/Safari/Firefox on OSX at least).
Spacebar also then causes a click event to bubble up.

If you're replicating native elements by using roles on something else, you
are responsible for ensuring those custom components behave the same way.

Cheers,

Sean

On Thu, May 7, 2015 at 11:52 AM, Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> All good points.
> The remaining experiment is to see if all html elements that map to
> the button role
> (button tag, input with type submit, reset, image, button ..
> optionally the summary attribute though it is not well supported) can
> be activated using the spacebar as well as the enter key.
> If so,then we can definitely say that space bar activation of the
> button role is firmly established, and an expected part of that role's
> operation.
> If anyone is wondering. I am preparing for my keyboard accessibility
> testing class at Access U. Of course I encourage anyone going to
> Access U to attend. ;)
> Cheers
> -B
>
>
> On 5/6/15, Paul J. Adam < <EMAIL REMOVED> > wrote:
> > According to PCAG, Paul's Content Accessibility Guidelines, :) yes of
> course
> > you must match the keyboard behavior to the role used on that element.
> >
> > If you say role=button then you are saying "I work with the spacebar!" if
> > you don't work with the space bar then you're just lying to the user and
> the
> > Accessibility API ;)
> >
> > I'm calling them WCAG failures if the keyboard interaction does not match
> > the role. You can be flexible with complex ARIA menubar mega menu type
> > widgets and allow both arrow navigation and tab key navigation through
> all
> > elements so all users know how to work the control and power users can
> skip
> > through it faster if desired.
> >
> > Things I'd consider a fail would be using an ARIA role that implies
> > spacebar, arrow key, or escape key behavior without actually implementing
> > that behavior. Seems like a 4.1.2 failure, i.e. you are using the
> incorrect
> > role for this element since the behavior does not match the standard
> native
> > element.
> >
> > Paul J. Adam
> > Accessibility Evangelist
> > www.deque.com <http://www.deque.com/>;
> >> On May 6, 2015, at 8:37 PM, Birkir R. Gunnarsson
> >> < <EMAIL REMOVED> > wrote:
> >>
> >> Yeah, that is the core of my question basically.
> >> WCAG says that all page elements have to be keyboard operable, but the
> >> standard does not specify a manner in which they have to be keyboard
> >> operable.
> >> I have always recommended space bar activation for buttons (because
> >> that is a function supported by native html button elements).
> >> It has never really come to a head for me, but I would have stopped
> >> short of demanding it if buttons are made keyboard accessible in a
> >> predictable or documented manner.
> >> Cheers
> >>
> >>
> >>
> >>
> >>
> >> On 5/6/15, Jonathan Avila < <EMAIL REMOVED> > wrote:
> >>>> I was asking if it was an absolute requirement of WCAG that all
> buttons
> >>>> be
> >>>> coded so that either enter or spacebar activates them. My guess from
> >>>> where this discussion has gone is no.
> >>>
> >>> It depends who you talk too -- so -- at this point there is no
> consensus
> >>> that I am aware of on this being a requirement. I'd assume we all
> agree
> >>> it's at least advisory though. There are many other techniques that
> fall
> >>> into this category and over time techniques may move from not having
> >>> consensus into having consensus. For example, do banner and footer
> >>> content
> >>> have to be marked as such as with HTML5 or ARIA -- do groups of links
> >>> have
> >>> to be within a nav or use navigation role, etc. My thoughts are my own
> >>> and
> >>> I'm not speaking for any working groups.
> >>>
> >>> Jonathan
> >>>
> >>> --
> >>> Jonathan Avila
> >>> Chief Accessibility Officer
> >>> SSB BART Group
> >>> <EMAIL REMOVED>
> >>>
> >>> 703-637-8957 (o)
> >>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> >>>
> >>>
> >>>