WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: using "label for=" on things other than inputs

for

From: Jonathan Avila
Date: Feb 22, 2016 11:22AM

Steve, the API document also doesn't seem to indicate label can be used for input type button, reset, submit, and image. This is the traditionally understood approach. However you mention the HTML5 spec allows all input to be labelled yet the spec only appears to call out type hidden. Is this also a bug from the Accessibility API spec or did I miss something? Just wanted to confirm.

Best Regards,

Jonathan



-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Steve Faulkner
Sent: Sunday, February 21, 2016 2:00 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] using "label for=" on things other than inputs

further to this, I added some tests to
http://thepaciellogroup.github.io/AT-browser-tests/test-files/label.html

for button, meter, progress and output

quick testing of button found that in Firefox, Edge, IE on windows exposed the label as the accessible name for the button element, the button text was discarded. Chrome was the outlier

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 20 February 2016 at 00:12, Steve Faulkner < <EMAIL REMOVED> >
wrote:

> FYI the list of labelable elements in HTML5 includes
> - button <http://www.w3.org/TR/html5/forms.html#the-button-element>;
> - input <http://www.w3.org/TR/html5/forms.html#the-input-element>; (if
> the type <http://www.w3.org/TR/html5/forms.html#attr-input-type>;
> attribute is
> *not* in the hidden
> <http://www.w3.org/TR/html5/forms.html#hidden-state-(type=hidden)>
> state)
> - keygen <http://www.w3.org/TR/html5/forms.html#the-keygen-element>;
> - meter <http://www.w3.org/TR/html5/forms.html#the-meter-element>;
> - output <http://www.w3.org/TR/html5/forms.html#the-output-element>;
> - progress
> <http://www.w3.org/TR/html5/forms.html#the-progress-element>;
> - select <http://www.w3.org/TR/html5/forms.html#the-select-element>;
> - textarea
> <http://www.w3.org/TR/html5/forms.html#the-textarea-element>;
>
> http://www.w3.org/TR/html5/forms.html#category-label
>
>
> On Friday, 19 February 2016, Detlev Fischer
> < <EMAIL REMOVED> >
> wrote:
>
>> Short question: When checking forms for a11y, I often see that 'label'
>> with an explicit association via the 'for' attribute is used on
>> things other than input elements. For example, on a button that will
>> add a user via a pseudo popup dialog, or on text that is read-only
>> because a user may not have permission to input data at this point.
>> The label does not activate the button so using it does not extend
>> the click area for mouse users as is the case with checkboxes or radio buttons.
>> The proper label of the button is of course given via the value of
>> the button (or link text of links made to look like buttons).
>>
>> So the question I have come up with is whether
>> (A) I should dissuade developers from using label on content that
>> is not suitable
>> as a labeled control even though the use may be harmless
>> (B) Whether this unintended use of label for="" would violate
>> 4.1.2 or is actually harmless
>>
>> One reason for using label for developers is of course that they can
>> apply the same styling to label elements regardless of whether they
>> are labels of inputs or labels of other stuff that is not an input
>> (read-only content, buttons etc.). There can also be different
>> variants of a form where depending on the rights of the user an
>> element may be a proper input or read-only content, so it is probably
>> unreasonable to expect developers to create different variants of the
>> same form mark-up depending on permission rights.
>>
>>
>> --
>> Detlev Fischer
>> testkreis - das Accessibility-Team von feld.wald.wiese c/o
>> feld.wald.wiese Thedestraße 2
>> 22767 Hamburg
>>
>> Mobil +49 (0)157 57 57 57 45
>> Fax +49 (0)40 439 10 68-5
>>
>> http://www.testkreis.de
>> Beratung, Tests und Schulungen für barrierefreie Websites
>>
>>
>>
>>
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w
> 3c/>
>
>