WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Paul J. Adam
Date: May 6, 2015 8:32PM

I used to think and say that if it looked like a button visually then it should have role=button since most people would refer to it as a button in a conversation.

However, humans and designers all have very different opinions on what button or a link really looks like. On iOS now buttons look like blue links without an underline. Thanks to the flat design trends buttons don't really look like buttons any longer.

I'm also thinking that a screen reader user does not care what the UI element they're focused on looks like so it's best to set the role based on the functionality of the element rather than the look. Native mobile makes this more apparent. So elements that open external URLs should likely be a link role even if they look like a button and elements that function like expanding/collapsing widgets should likely be a button role rather than a link role even if they look like a typical link.

So eliminating the "if it looks like a" from the discussion makes determining the proper role much easier.

Paul J. Adam
Accessibility Evangelist
www.deque.com <http://www.deque.com/>;
> On May 6, 2015, at 9:12 PM, Jonathan Avila < <EMAIL REMOVED> > wrote:
>
>> 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.
>
> Then you might also say if something looks like a button but is implemented with a link then it's also a failure. These are all good discussions -- but we would really need consensus and then corresponding WCAG failure techniques to assist the wider community in determining conformance.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> <EMAIL REMOVED>
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Paul J. Adam
> Sent: Wednesday, May 06, 2015 9:46 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Is a button that does not support space bar activation a violation of WCAG?
>
> 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
>>>
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>>> Behalf Of Birkir R. Gunnarsson
>>> Sent: Wednesday, May 06, 2015 9:14 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Is a button that does not support space bar
>>> activation a violation of WCAG?
>>>
>>> Guys.
>>> I was not asking whether it was hard or easy (I have a single
>>> JavaScript function of 5 lines that adds the appropriate keyboard
>>> interaction to all links turned buttons).
>>> 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.
>>> Thanks
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >
> > > > > > >