WebAIM - Web Accessibility In Mind

E-mail List Archives

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


From: Julie Romanowski
Date: Nov 19, 2015 3:43PM

Thank you, Birkir. :)

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, November 19, 2015 4: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?

I believe the closest W3C specs come to dictating functionality of simulated controls is via the ARIA authoring Best Practices.
It is important to understand that these are not normative, but they do suggest the expected keyboard operation pattern of custom interface components, including buttons, radiobuttons and checkboxes.
I can suggest to the taskforce, which meets next Monday, whether content can be added to simulated form controls explaining the importance of enabling the click-the-label-to-focus functionality, and we could implement this in our best practice widget examples (which a lot of smart people are working hard on on Github).
It doesn't change WCAG or the different viewpoints expressed here, but it could provide encouragement and demonstration on how things should be done right, and that can at least help point people's brains in the right direction.

On 11/19/15, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> On 19/11/2015 21:14, Julie Romanowski wrote:
>> We need to remember that assistive technologies include hardware as
>> well as software. We're not just talking about screen readers.
>> There are employees with mobility challenges at our company who use
>> special types of ergonomic mice to access their computers. For
>> example, one person uses a foot mouse (also called a slipper mouse)
>> and another person uses a head mouse. Both of them have poor fine
>> motor control and it's very difficult to impossible for them to click
>> on small items such as radio buttons or check boxes. Coding the
>> controls and their respective labels correctly using the id and for
>> attributes provides a much larger area for these two people to click
>> on, making selecting the controls much easier.
> That is only one possible technique. Another would be to make the
> actual radio button or checkbox very big. So it's not a cut-and-dry
> "if the label isn't a proper <label>, and not assigned explicitly
> using for="..." attribute, it's a fail.
> But in both cases, I don't believe any WCAG 2.0 SC specifically deals
> with target/touch sizes (something that has since been brought up in
> the specific context of touchscreens in the mobile a11y TF, but I
> would have liked to see tackled more generally even on "desktop" for
> mouse users - see
> https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jul/003
> 7.html)
>> In the "Understanding Techniques for WCAG Success Criteria"
>> documentation under "Sufficient Techniques"
>> (http://www.w3.org/TR/2015/NOTE-UNDERSTANDING-WCAG20-20150226/underst
>> anding-techniques.html#ut-understanding-techniques-sufficient-head)
>> it states that "If web content implements the sufficient techniques
>> for a given criterion correctly and it is accessibility-supported for
>> the content's users, it conforms to that success criterion". Maybe
>> I'm misunderstanding the WCAG 2.0 definition of accessibility support
>> (http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-access
>> ibility-supported-definition-head),
>> but I take this to mean that using aria-labelledby to label radio
>> buttons will fail SC 4.1.2 Name, Role, Value, as it isn't "
>> accessibility-supported for the content's users" (the people using
>> ergonomic mice as AT).
> Why 4.1.2? "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)" ... nowhere here
> is there talk of "users must be able to operate controls with their
> specific input technology" or similar. This is about exposing name,
> role, state, value programmatically. Unless you're thinking of "allow
> themselves to be controlled by assistive technologies" in the intent
> for the SC http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html ...
> which, I'd say, is a bit of a stretch, IMO.
> 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
> >

Work hard. Have fun. Make history.