WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Anchor inside label?

for

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

From: Isabel Holdsworth
Date: Thu, Apr 12 2018 7:33AM
Subject: Anchor inside label?
No previous message | Next message →

Hi all,

We're putting together a prototype that has a checkbox whose label
contains an anchor (<a>) to a footnote further down in the page.

This doesn't cause any validation errors, but I'm wondering if it's
likely to throw up any accessibility issues?

I'd appreciate your thoughts.

From: Steve Faulkner
Date: Thu, Apr 12 2018 7:49AM
Subject: Re: Anchor inside label?
← Previous message | Next message →

Hi Lynne, I added some advice and code examples
<https://www.w3.org/TR/html/sec-forms.html#example-42c5e0c5> around this to
the HTML spec a while back which may be helpful

The ability to click or press a label to trigger an event on a control
> provides usability and accessibility benefits by increasing the *hit area*
> of a control, making it easier for a user to operate. These benefits may be
> lost or reduced, if the label element contains an element with its own
> activation behavior, such as a link:
>
>
--

Regards

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

On 12 April 2018 at 14:33, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = >
wrote:

> Hi all,
>
> We're putting together a prototype that has a checkbox whose label
> contains an anchor (<a>) to a footnote further down in the page.
>
> This doesn't cause any validation errors, but I'm wondering if it's
> likely to throw up any accessibility issues?
>
> I'd appreciate your thoughts.
> > > > >

From: Birkir R. Gunnarsson
Date: Thu, Apr 12 2018 8:14AM
Subject: Re: Anchor inside label?
← Previous message | Next message →

This one is tricky.
By including the link in the label you are making it easier for users
to navigate to and review the terms and conditions.
Screen readers handle this situation pretty well.

But you are also reducing the clickable target size of the label for
people who need to interact with the checkbox.

If the aria-flowto attribute was supported anywhere outside of Jaws
with Firefox (if that combo still supports it) this would be an ideal
case for use of that attribute.
<input type="checkbox" id="ch1">
<label for="ch1">I gree to the
<span aria-flowto="tac">terms and conditions</span>
</label>

....
<div id="tac">
<h4>terms and conditions</h4>
...
</div>

If you navigate to the phrase "terms and conditions" with Jaws (and
Firefox, at lesat older versions) it should tell you an alternative
flow is available and that you can navigate to it by pressing "=", you
can get back from there to the label by pressing shift-But sadly, as great as the idea behind this attribute was, lack of
support has basically forcedme to take it off my recommendations list,
though I wonder whether we should either try to push for better
support or remove it from the ARIA spec.



On 4/12/18, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Lynne, I added some advice and code examples
> <https://www.w3.org/TR/html/sec-forms.html#example-42c5e0c5> around this to
> the HTML spec a while back which may be helpful
>
> The ability to click or press a label to trigger an event on a control
>> provides usability and accessibility benefits by increasing the *hit area*
>> of a control, making it easier for a user to operate. These benefits may
>> be
>> lost or reduced, if the label element contains an element with its own
>> activation behavior, such as a link:
>>
>>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 12 April 2018 at 14:33, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Hi all,
>>
>> We're putting together a prototype that has a checkbox whose label
>> contains an anchor (<a>) to a footnote further down in the page.
>>
>> This doesn't cause any validation errors, but I'm wondering if it's
>> likely to throw up any accessibility issues?
>>
>> I'd appreciate your thoughts.
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Graham Armfield
Date: Thu, Apr 12 2018 9:34AM
Subject: Re: Anchor inside label?
← Previous message | Next message →

Dear All,

I don't have the ability to test this anymore, but when using Voiceover on
some earlier versions of iOS (I'm thinking iOS 9 on iPhone or iPad), I
noticed that Voiceover seemed to ignore any links in explicitly marked up
labels. Double tapping on it transferred focus to the input field - ie
following the native browser behaviour for labels.

So if anyone is still on older versions, and the link to Terms and
Conditions is the only way to read the Ts and Cs, then those people
wouldn't easily be able to get to the Ts and Cs to read them.

As far as I can tell, this issue is no longer true in newer versions of iOS.

Regards
Graham Armfield
Coolfields Consulting
​

From: Jonathan Avila
Date: Thu, Apr 12 2018 1:04PM
Subject: Re: Anchor inside label?
← Previous message | Next message →

In addition, in the past TalkBack had issues with implicit labels that contain input fields and links.

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office

Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog

Looking to boost your accessibility knowledge? Check out our free webinars!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Graham Armfield
Sent: Thursday, April 12, 2018 11:35 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Anchor inside label?

Dear All,

I don't have the ability to test this anymore, but when using Voiceover on
some earlier versions of iOS (I'm thinking iOS 9 on iPhone or iPad), I
noticed that Voiceover seemed to ignore any links in explicitly marked up
labels. Double tapping on it transferred focus to the input field - ie
following the native browser behaviour for labels.

So if anyone is still on older versions, and the link to Terms and
Conditions is the only way to read the Ts and Cs, then those people
wouldn't easily be able to get to the Ts and Cs to read them.

As far as I can tell, this issue is no longer true in newer versions of iOS.

Regards
Graham Armfield
Coolfields Consulting
​

From: Isabel Holdsworth
Date: Fri, Apr 13 2018 2:40AM
Subject: Re: Anchor inside label?
← Previous message | Next message →

Thanks for your thoughts guys. I'm not sure why wrapping other tags in
labels makes me uncomfortable, but it does. Perhaps it's just the
(perceived?) unpredictability of how it might render in different
browser/AT combinations, and how easy it could be for devs to get it
wrong, like wrapping a group of radiobuttons in a descriptive
super-label.

On 12/04/2018, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> In addition, in the past TalkBack had issues with implicit labels that
> contain input fields and links.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Graham Armfield
> Sent: Thursday, April 12, 2018 11:35 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Anchor inside label?
>
> Dear All,
>
> I don't have the ability to test this anymore, but when using Voiceover on
> some earlier versions of iOS (I'm thinking iOS 9 on iPhone or iPad), I
> noticed that Voiceover seemed to ignore any links in explicitly marked up
> labels. Double tapping on it transferred focus to the input field - ie
> following the native browser behaviour for labels.
>
> So if anyone is still on older versions, and the link to Terms and
> Conditions is the only way to read the Ts and Cs, then those people
> wouldn't easily be able to get to the Ts and Cs to read them.
>
> As far as I can tell, this issue is no longer true in newer versions of
> iOS.
>
> Regards
> Graham Armfield
> Coolfields Consulting
> ​
> > > > > > > > >

From: glen walker
Date: Fri, Apr 13 2018 9:54AM
Subject: Re: Anchor inside label?
← Previous message | No next message

When I put my developer hat on, I can understand your uncomfortableness.
From an object oriented programming perspective, a link in a label is
essentially multiple inheritance. While it's natural for people to inherit
from two parents, in object oriented programming, you typically only
inherit from one parent. If you inherit from two, and both parents have
the same named method, which superclass method gets called when the method
goes up the chain? With a link in a label, the link essentially has two
parents - the <a> and the <label>. Both the <a> and the <label>
essentially have the same named method to handle a selection. So when you
select the link, which parent should be called? Is it a link or is it a
label (and subsequently checks the checkbox)?

So you're not alone with this uncomfortable construct.


On Fri, Apr 13, 2018 at 2:40 AM, Isabel Holdsworth <
= EMAIL ADDRESS REMOVED = > wrote:

> Thanks for your thoughts guys. I'm not sure why wrapping other tags in
> labels makes me uncomfortable, but it does. Perhaps it's just the
> (perceived?) unpredictability of how it might render in different
> browser/AT combinations, and how easy it could be for devs to get it
> wrong, like wrapping a group of radiobuttons in a descriptive
> super-label.
>
> On 12/04/2018, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> > In addition, in the past TalkBack had issues with implicit labels that
> > contain input fields and links.
> >
> > Jonathan
> >
> > Jonathan Avila
> > Chief Accessibility Officer
> > Level Access
> > = EMAIL ADDRESS REMOVED =
> > 703.637.8957 office
> >
> > Visit us online:
> > Website | Twitter | Facebook | LinkedIn | Blog
> >
> > Looking to boost your accessibility knowledge? Check out our free
> webinars!
> >
> > The information contained in this transmission may be attorney privileged
> > and/or confidential information intended for the use of the individual or
> > entity named above. If the reader of this message is not the intended
> > recipient, you are hereby notified that any use, dissemination,
> distribution
> > or copying of this communication is strictly prohibited.
> >
> > -----Original Message-----
> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf
> > Of Graham Armfield
> > Sent: Thursday, April 12, 2018 11:35 AM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Anchor inside label?
> >
> > Dear All,
> >
> > I don't have the ability to test this anymore, but when using Voiceover
> on
> > some earlier versions of iOS (I'm thinking iOS 9 on iPhone or iPad), I
> > noticed that Voiceover seemed to ignore any links in explicitly marked up
> > labels. Double tapping on it transferred focus to the input field - ie
> > following the native browser behaviour for labels.
> >
> > So if anyone is still on older versions, and the link to Terms and
> > Conditions is the only way to read the Ts and Cs, then those people
> > wouldn't easily be able to get to the Ts and Cs to read them.
> >
> > As far as I can tell, this issue is no longer true in newer versions of
> > iOS.
> >
> > Regards
> > Graham Armfield
> > Coolfields Consulting
> > ​
> > > > > > > > > > > > > > > > > >
> > > > >