WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Does WCAG require that when you click a label itchecks the checkbox or radio button?

for

From: Jonathan Avila
Date: Nov 19, 2015 1:39PM

> If it does not operate with the keyboard like a real <button> then how is it keyboard operable?

Technically the button wouldn't even need to be in the focus order and could be operable through a documented keystroke such as control+shift+f1. Obviously this would strongly be discouraged in most situations but it's still operable with a keyboard. I think what you are asking is what is the definition of operable -- simply put "it can be used" and it can with a keyboard. Now there could certainly be other accessibility support concerns raised and functional accessibility issues that pose a risk to organizations here and any good accessibility consultant should strongly steer folks toward to right way of doing things for the sake of users and the organization.

Best Regards,

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 Adam
Sent: Thursday, November 19, 2015 12:08 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Does WCAG require that when you click a label it checks the checkbox or radio button?

It says All functionality is operable through keyboard interface. It does not say "and the Enter key alone is sufficient" or this or that key must work.

If it does not operate with the keyboard like a real <button> then how is it keyboard operable?

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 11:04 AM, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
>
> On 19/11/2015 16:57, Paul Adam wrote:
>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard
>> -operable.html
>>
>> 2.1.1 Keyboard: All functionality of the content is operable through
>> a keyboard interface without requiring specific timings for
>> individual keystrokes, except where the underlying function requires
>> input that depends on the path of the user's movement and not just
>> the endpoints. (Level A)
>>
>> I'm choosing NOT to water down WCAG and say that a button element only has to work with enter key when in reality all native <button>s work with enter and spacebar.
>
> You talk of "watering down", but: unless there is normative text that specifically says so, all we're "watering down" here is *your* interpretation.
>
>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
>> 4.1.2 Name, Role, Value: For all user interface components (including
>> but not limited to: form elements, links and components generated by
>> scripts), the name and role can be programmatically determined;
>> states, properties, and values that can be set by the user can be
>> programmatically set; and notification of changes to these items is
>> available to user agents, including assistive technologies. (Level A)
>>
>> I'm saying that if you use the role of button but you don't implement that role like a native button then you're not meeting Name, Role, Value.
>
> Again, that seems to be more *your* interpretation, rather than what WCAG actually normatively says.
>
> To be clear: I understand that in practice these things should be done (and indeed, in many reports for clients, I've been known to write lengthy stretches starting with "Although X meets the letter of WCAG, we however strongly advise that..."). But, if you are tasked with auditing against WCAG, it's best IMHO not to fail a particular SC based on your expanded interpretation that is nowhere in the actual normative text.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > archives at http://webaim.org/discussion/archives
>