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: Birkir R. Gunnarsson
Date: Nov 21, 2015 5:28PM

Correct Sailesh

This piece of code would be exposed as a heading to A.T. users.
I am not sure what the label tag would do, you can´t associated a
label with a heading, but it can easily be tested.
I still think the way out of this potential mess is a more powerful
and widely supported html5. We need better accessibility support in
browsers for html elements such as dialogs, summary/detail and other
tags meant to replace custom tags.
Also developers need to start using the appropriate html tags.
Why should the browser go through the trouble of implementing all the
native behavior of an anchor mapped as a button using role="button"
when the developer could simply have used the button tag to begin
with.
Developers need to understand that if they wish to develop a custom
component rather than using what's already there, it comes at a cost,
and that cost is making sure it behaves as the native element.

I totally understand the frustrations, both as an accessibility
consultant and an end user.
I have seen whole sections of a page mapped as a tab (instead of
tabpanel), thus preventing me from interacting with any of its
focusable components.
I have seen the aria-labelledby attribute used with a string rather
than an ID reference, thus making the name of a form field impossible
to determine.
Even when implemented correctly there are so many minor variations in
the operation of complex widgets such as date pickers, tabs,
accordions etc. that I never know what I am going to get until I
experiment with it. And let's not get started on dialogs, especially
modal ones.

I am still hoping that a more powerful and better supported future
version of good old html is the answer rather than a more powerful
ARIA, a technology only meant for users with disabilities, as opposed
to technology aimed at all users.







On 11/21/15, Sailesh Panchang < <EMAIL REMOVED> > wrote:
> 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
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.