WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?


From: Chaals McCathie Nevile
Date: Nov 21, 2015 11:49PM

On Sat, 21 Nov 2015 20:16:05 +0200, Karl Groves < <EMAIL REMOVED> >

> On Sat, Nov 21, 2015 at 2:02 AM, Chaals McCathie Nevile
> < <EMAIL REMOVED> > wrote:
>> In any event, given that browsers have fast, efficient, well-tested
>> native code for making buttons work, why should we tell millions of
>> authors to replicate that code in javascript? That is an inefficient,
>> error-prone way to work. If browsers recognised controls from their
>> role, why can't they just apply the same code they use when they
>> recognise them from the element name? In the button case, I can't
>> think of a reason. Nor in the case of a range control, or a
>> date-picker.
> If I understand what you're implying, I think you're proposing
> something quite compelling, but likely difficult to make happen.

I suspect you do understand, and yes, I suspect that browser makers will
say it is impossible, very difficult, and possibly a very bad idea -
although more likely I expect "not clear what the benefit is".

> Right now, browser vendors have a well-defined DOM specification to work
> from and gobs of legacy code implementing that. Keeping in mind that
> a large portion of native form controls had their DOM interfaces
> defined back in DOM Level 2.

Yeah, but what's the hard bit in connecting to that code?

> Browsers already do some of this type of trickery using the Shadown
> DOM for new HTML5 input types, so it isn't impossible. It just
> seems... hairy. It seems difficult to now say "ok all objects with a
> specified 'role' property should now apply the same DOM methods and
> properties as those items they're pretending to be".
> Imagine:
> <input type="checkbox" role="heading" aria-labelledby="foo">
> <label id="foo">I'm really a heading, trust me!</label>
> Absurd? Yes. But there's no limit to developer silliness!

Well, yeah, but what is the expected outcome of this? And if browsers are
implementing that instead of just having something in the accessibility
API, doesn't that seriously help us reduce confusion and likely separate

>> The only issue will arise if the button is
>> coded to do something the user *doesn't* expect, like operate on
>> pressing q
>> or f.
> Well that, like anything, comes down to the designers & developers
> disavowing themselves of any misguided belief that doing so would be a
> good idea. ;-)


On the other hand, of course, if someone makes a quirky browser that
really meets its users' needs, and for some reason the *expected*
behaviour of that browser is that the q key presses buttons, it would be
nice if that happened without developers somehow having to implement it in

Think of TV browsers (they aren't massively used for various reasons, but
there are a *lot* of them out there), or controlling with a gamepad, or
talking to your stereo (how else are they going to keep selling those
things?) about the news, weather, and how to book tickets to the latest
toddler-band concert and find some schoolkid to carry you there on his
bicycle-rickshaw (as part of the work experience he is paying some Silicon
Valley tax wheeze to be allowed to slave for)…


Charles McCathie Nevile - web standards - CTO Office, Yandex
<EMAIL REMOVED> - - - Find more at http://yandex.com