E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 18 (In chronological order)

From: Detlev Fischer
Date: Thu, Feb 18 2016 11:55PM
Subject: using "label for=" on things other than inputs
No previous message | Next message →

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

From: Jonathan Avila
Date: Fri, Feb 19 2016 12:15PM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

> (B) Whether this unintended use of label for="" would violate 4.1.2 or is actually harmless

In my opinion it depends on whether the information and relationship is communicated another way or whether it is necessary information or relationship. If a label is used incorrectly to associate text with a button but the text is not necessary to understand the purpose of the button then it does not seem to be a failure. However, if the information is necessary to understand the purpose of the control then it must be associated somehow with the control and thus if it were not it could be a failure of SC 1.3.1. Use of a label on a button doesn't seem to be a failure under SC 4.1.1.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Steve Faulkner
Date: Fri, Feb 19 2016 5:12PM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

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 ADDRESS 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
>
>
>
>
>
> > > > >


--
--

Regards

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

From: Jonathan Avila
Date: Fri, Feb 19 2016 6:42PM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

Ø FYI the list of labelable elements in HTML5 includes - button <http://www.w3.org/TR/html5/forms.html#the-button-element>;



WCAG Technique H44<https://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H44> states:



Note 2: The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button).



'Submit and Reset buttons ( input type="submit" or input type="reset")

'Image buttons ( input type="image")

'Hidden input fields ( input type="hidden")

'Script buttons (button elements or <input type="button">)



HTML Accessibility API Mappings 1.0<https://www.w3.org/TR/html-aam-1.0/#button-element> also indicates the following which does not seem to include the label element:

5.4 button Element
5.4.1 button Element Accessible Name Calculation

1. If the button element has an aria-label<http://www.w3.org/TR/wai-aria-1.1/#aria-label>; or an aria-labelledby<http://www.w3.org/TR/wai-aria-1.1/#aria-labelledby>; attribute the accessible name<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name> is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1<http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html>;.
2. Otherwise use the button element subtree
3. Otherwise use title attribute
4. If none of the above yield a usable text string there is no accessible name<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>



Jonathan

From: Steve Faulkner
Date: Sat, Feb 20 2016 1:37AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

On 20 February 2016 at 01:42, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> HTML Accessibility API Mappings 1.0<
> https://www.w3.org/TR/html-aam-1.0/#button-element> also indicates the
> following which does not seem to include the label element:
>

Yes you are correct that this is was the API spec currently says, that is
my fault.

I have filed an issue https://github.com/w3c/aria/issues/259

--

Regards

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

From: Detlev Fischer
Date: Sat, Feb 20 2016 5:42AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

All this doesn't quite answer my original question whether the use of label on elements other than those Steve listed could be confusing and should be discouraged. I take it nobody would see a failure of 1.3.1 for using 'label for=' on read-only text, disabled input, or a button that already has an accessible name via value - correct?

Sent from phone

> On 20 Feb 2016, at 09:37, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 20 February 2016 at 01:42, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> HTML Accessibility API Mappings 1.0<
>> https://www.w3.org/TR/html-aam-1.0/#button-element> also indicates the
>> following which does not seem to include the label element:
>
> Yes you are correct that this is was the API spec currently says, that is
> my fault.
>
> I have filed an issue https://github.com/w3c/aria/issues/259
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > >

From: Patrick H. Lauke
Date: Sat, Feb 20 2016 5:47AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

On 20/02/2016 12:42, Detlev Fischer wrote:
> All this doesn't quite answer my original question whether the use of
> label on elements other than those Steve listed could be confusing
> and should be discouraged. I take it nobody would see a failure of
> 1.3.1 for using 'label for=' on read-only text,

If it's a scenario like something in a form that the user is not
currently allowed to actually edit, I'd actually suggest turning that
text into a readonly input (and then yes, having the label associated
with that input. Otherwise, I'd say it's a mild failure as there's no
relationship defined between the label and what is static text (as that
relationship is not exposed in the accessibility tree, even if there
for="..." points to an id for the container of the text.

> disabled input,

It may be disabled, but the relationship to its label is still needed
(if the user navigated to this input with the reading keys, even though
they can't actively TAB/SHIFT+TAB into it)

> or a
> button that already has an accessible name via value - correct?

If <label for="..."> on a button is legit per spec (which seems to be
what Steve is saying), then that should be legitimate. Whether it's
appropriate and/or supported by actual browser/AT combinations is
another matter...

P

> Sent from phone
>
>> On 20 Feb 2016, at 09:37, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> On 20 February 2016 at 01:42, Jonathan Avila
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> HTML Accessibility API Mappings 1.0<
>>> https://www.w3.org/TR/html-aam-1.0/#button-element> also
>>> indicates the following which does not seem to include the label
>>> element:
>>
>> Yes you are correct that this is was the API spec currently says,
>> that is my fault.
>>
>> I have filed an issue https://github.com/w3c/aria/issues/259
>>
>> --
>>
>> Regards
>>
>> SteveF Current Standards Work @W3C
>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>>
>>
>> >> archives at http://webaim.org/discussion/archives >> messages to = EMAIL ADDRESS REMOVED =
> > subscription, visit http://list.webaim.org/ List archives at
> http://webaim.org/discussion/archives > = EMAIL ADDRESS REMOVED =
>


--
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

From: Steve Faulkner
Date: Sun, Feb 21 2016 11:59AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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
>>
>>
>>
>>
>>
>> >> >> >> >>
>
>
> --
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
>

From: Sailesh Panchang
Date: Mon, Feb 22 2016 10:15AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

The HTML5 specs say, "button element represents a button labeled by
its contents". So a button element or an input element of pushbutton
type do not need or use for-id method for label association.
Also see https://www.w3.org/TR/WCAG20-TECHS/H91.html

With regard to Detlev ' s question:
The for-id method is only meant for form controls other than buttons really.
It can be used for controls with readonly attribute too. Sure it will
not move focus because the control is readonly but the label
association is available to screen readers.
I have seen label for-id incorrectly being used in non-editable mode
when the content is displayed for, say confirmation of data already
entered.
So the data is displayed in a 2-col format with label on the left and
the data to its right. This is plain static text and the label text is
marked up as a label and the plain text to its right has an id that
points to the label! This does not expose any info relationship as
intended by the author. The content needs to be marked up as a 2-col
data table with row headers or as a dl-dt-dd to expose data
relationships and pass SC 1.3.1.
Thanks and regards,
Sailesh Panchang

From: Jonathan Avila
Date: Mon, Feb 22 2016 11:22AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

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

From: Jonathan Avila
Date: Mon, Feb 22 2016 11:27AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

> I take it nobody would see a failure of 1.3.1 for using 'label for=' on read-only text, disabled input, or a button that already has an accessible name via value - correct?

In the case that the label would override the button text and provide a different accessible name a violation could occur if that new accessible name did not sufficiently label the button. For example, a button with text color had a label of "foreground". Foreground would be the accessible name unless the button was wrapped within the label such as in <label for="a1"> Foreground <button id="a1">Color</button></label>.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Steve Faulkner
Date: Tue, Feb 23 2016 7:09AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

On 22 February 2016 at 18:22, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> 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.


hi Jon, the HTML5 spec defines that any input, apart from type=hidden, can
be labelled using the label element.

--

Regards

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

From: Sailesh Panchang
Date: Tue, Feb 23 2016 7:43AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

>>the HTML5 spec defines that any input, apart from type=hidden, can be labelled using >>the label element.
The HTML5 specs also say, "button element represents a button labeled
by its contents".
So is there a need for one to use a label element to label a button
really given other AT-supported methods to label a button / push
button type input element are available?
Jon, In your example:
<label for="a1"> Foreground <button id="a1">Color</button></label>
With implicit labelling, there is no need for for-id, right?
Also if "Foreground" is meant to function as a visible label like the
button content, "Color", why not have the word "Foreground within
button content? Visually too one may only identify "color" to be the
button's name really.
If "color" is really non text (img of some color), then it can be
assigned alt or an accessible name within the button content.
So I am trying to understand the use-case for using a label with a
button or push putton type input element.
Is there any need really to change H44 or H91?
Thanks,
Sailesh


On 2/23/16, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> On 22 February 2016 at 18:22, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> 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.
>
>
> hi Jon, the HTML5 spec defines that any input, apart from type=hidden, can
> be labelled using the label element.
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > > >

From: Steve Faulkner
Date: Tue, Feb 23 2016 7:51AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

On 23 February 2016 at 14:43, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
wrote:

> The HTML5 specs also say, "button element represents a button labeled
> by its contents".
> So is there a need for one to use a label element to label a button
> really given other AT-supported methods to label a button / push
> button type input element are available?
>

Hi Sailesh, I am not and have not argued that using a label is either
necessary or recommended.

my interest is in whether what is defined in the spec for UA
implementations is actually implemented and what effect it has on the
accessible name calculation.

As stated previously, what i found in some quick testing is that use of
label on a button indeed results in the label text being used for the
button accessible name.

--

Regards

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

From: Jonathan Avila
Date: Tue, Feb 23 2016 7:56AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

> my interest is in whether what is defined in the spec for UA implementations is actually implemented and what effect it has on the accessible name calculation.

So should this then logically flow to allow labeling for ARIA equivalents to buttons and input elements such as role button, role radio, and role checkbox.
<span id="r1" role="radio" ...> ...</span><label for="r1">Milk</label>

In the past this was not considered allowable -- but perhaps this is changing.

Jonathan Avila

From: Jonathan Avila
Date: Tue, Feb 23 2016 7:56AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

> Jon, In your example:
<label for="a1"> Foreground <button id="a1">Color</button></label> With implicit labelling, there is no need for for-id, right?

Correct, although implicit labels without matching for/id are not supported by some technologies such as Dragon and perhaps Talkback on Android. So this wraps both and contains the explicit association those AT need.

> Also if "Foreground" is meant to function as a visible label like the button content, "Color", why not have the word "Foreground within button content? Visually too one may only identify "color" to be the button's name really.

This would likely be done to make sure the button widths are equal or space reasons. In some cases repeating text on each button actually makes it more difficult for people looking at the buttons. For example, say you had an add button and it corresponded with some other text in a row and you didn't want to duplicate the text.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Steve Faulkner
Date: Tue, Feb 23 2016 8:09AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | Next message →

On 23 February 2016 at 14:56, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> So should this then logically flow to allow labeling for ARIA equivalents
> to buttons and input elements such as role button, role radio, and role
> checkbox.
> <span id="r1" role="radio" ...> ...</span><label for="r1">Milk</label>
>
> In the past this was not considered allowable -- but perhaps this is
> changing.
>

The idea has been raised, but there nothing has arisen.

See this thread - Making ARIA and native HTML play better together
https://lists.w3.org/Archives/Public/public-html/2015May/0038.html
--

Regards

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

From: Patrick H. Lauke
Date: Tue, Feb 23 2016 8:24AM
Subject: Re: using "label for=" on things other than inputs
← Previous message | No next message

On 23/02/2016 14:56, Jonathan Avila wrote:
>> my interest is in whether what is defined in the spec for UA implementations is actually implemented and what effect it has on the accessible name calculation.
>
> So should this then logically flow to allow labeling for ARIA equivalents to buttons and input elements such as role button, role radio, and role checkbox.
> <span id="r1" role="radio" ...> ...</span><label for="r1">Milk</label>
>
> In the past this was not considered allowable -- but perhaps this is changing.

I believe the current reasoning is that if you're "faking" a control
using role, then you also need to fake the normal label/for relationship
using aria-label or similar. i.e. the native structural relationship is
only provided/mapped correctly by the browser/AT if you're using the
correct HTML elements (rather than forcing the roles).

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