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?

for

From: Sailesh Panchang
Date: Nov 21, 2015 4:52PM

With reference to:
<input type="checkbox" role="heading" aria-labelledby="foo">
<label id="foo">I'm really a heading, trust me!</label>
Sailesh: Only users relying on AT/UA that are ARIA-aware, the
checkbox above may be expected to be exposed as a heading. Visually,
that element will still appear and behave like a checkbox, right?
Especially if someone chooses to use CSS properties that are not
author-supplied. The ARIA specs suggest that developers need to script
the elements to provide expected functionality, now if that
responsibility is shifted to UA makers, will it create chaos for
various stakeholders including different user groups?
Thanks,
Sailesh


On 11/22/15, Chaals McCathie Nevile < <EMAIL REMOVED> > wrote:
> On Sat, 21 Nov 2015 20:16:05 +0200, Karl Groves < <EMAIL REMOVED> >
> wrote:
>
>> 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
> paths?
>
>>> 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. ;-)
>
> Sure.
>
> 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
> Javascript…
>
> 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)…
>
> cheers
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> <EMAIL REMOVED> - - - Find more at http://yandex.com
> > > > >