RE: Link labels

  *   Chaals wrote - In my opinion: a form label not programatically associated to an input does not fail 1.3.1 if the text is adjacent in a way that is not ambiguous. However, it would fail 2.5.3 [1]. Because in the text of that requirement:

Not failing SC 1.3.1 for input fields and labels not being associated is in my opinion a departure from the guidance previously provided by the Accessiblity Guidelines Working Group and other WAI materials.  While text can be used to meet SC 1.3.1 – the association is necessary to be accessibility supported in a consistent way.

Jonathan

From: Chaals Nevile <chaals@fastmail.fm>
Sent: Monday, December 12, 2022 7:28 AM
To: Ms J <ms.jflz.woop@gmail.com>; Mark Magennis <Mark.Magennis@skillsoft.com>; w3c-wai-ig@w3.org
Subject: Re: Link labels

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

In my opinion: a form label not programatically associated to an input does not fail 1.3.1 if the text is adjacent in a way that is not ambiguous. However, it would fail 2.5.3 [1]. Because in the text of that requirement:

  For user interface components<https://www.w3.org/TR/WCAG21/#dfn-user-interface-components> with labels<https://www.w3.org/TR/WCAG21/#dfn-labels> that include text<https://www.w3.org/TR/WCAG21/#dfn-text> or images of text<https://www.w3.org/TR/WCAG21/#dfn-images-of-text>, the name<https://www.w3.org/TR/WCAG21/#dfn-name> contains the text that is presented visually.

a label is defined in a way that covers the text available in context, and a name is defined as a programmatic association to the control. This might also apply to your situation, implying that the headings have to be programmatically associated, which could lead to the painful repetition Mark mentioned.

[1] https://www.w3.org/TR/WCAG21/#label-in-name


cheers

On Monday, 12 December 2022 13:00:04 (+01:00), Ms J wrote:
Thank you Mark, so does that mean that if form labels are not programmatically associated with an input, they don't fail 1.3.1 if the text is the adjacent to the fields?

Thanks

Sarah

Sent from Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Mark Magennis <Mark.Magennis@skillsoft.com<mailto:Mark.Magennis@skillsoft.com>>
Sent: Monday, December 12, 2022 11:57 am
To: Ms J <ms.jflz.woop@gmail.com<mailto:ms.jflz.woop@gmail.com>>
Subject: RE: [EXTERNAL] Link labels

I’m not sure this fails 1.3.1 because that is about information conveyed through presentation. The fact that this control is within the section under that heading is conveyed by the heading structure, not just presentation.

If it was a link, it would probably fail 2.4.4: Link Purpose (In Context) and the fact that this SC only relates to links is, I think, a deficiency in WCAG. Realistically, it should relate to buttons too. It allows for the context not to be made part of the control’s name or description if it is “in the same sentence, paragraph, list item, or table cell as the link, or in the table header cell for a link in a data table, because these are directly associated with the link itself”. None of these are true in your case.

However, leaving aside whether this is a WCAG failure, you might consider what is best for accessibility. I’ll give you an example from a similar use of cards containing headings and controls. My company makes an eLearning product offering courses, books, videos, audiobooks, live events, etc. and each  of these ‘assets’ is presented as a card which has the asset title as the heading (and a link to the asset), then some text content – type, duration, description, etc. - and some controls – “add to playlist”, “like”, “share”, etc. The question is, do we include the asset title in the names of all the controls? Asset tiles can be quite long, so we might have something like this:

Great Answers to Tough Interview Questions: Your Comprehensive Job Search Guide with over 200 Practice Interview Questions, 11th Edition [Heading]
Book
By Martin John Yate
Dec 2020
Share [button]
Like [button]
More Actions [button]

So do we name the buttons like so?:

Share Great Answers to Tough Interview Questions: Your Comprehensive Job Search Guide with over 200 Practice Interview Questions, 11th Edition
Like Great Answers to Tough Interview Questions: Your Comprehensive Job Search Guide with over 200 Practice Interview Questions, 11th Edition
More Actions Great Answers to Tough Interview Questions: Your Comprehensive Job Search Guide with over 200 Practice Interview Questions, 11th Edition

In user testing some learners complained about the constant repetition. So we thought about it again and changed it to:

Share this book
Like this book
More Actions for this book

This seems to work well because users never read these buttons without having just read the heading. They either jump through headings looking for the asset they want, arrow through the page encountering the heading before the buttons or Tab through the page, again encountering the heading before the buttons. So they always know what “this book” or “this video” refers to.

Mark


From: Ms J <ms.jflz.woop@gmail.com<mailto:ms.jflz.woop@gmail.com>>
Sent: Monday 12 December 2022 11:01
To: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: [EXTERNAL] Link labels

You don't often get email from ms.jflz.woop@gmail.com<mailto:ms.jflz.woop@gmail.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hello all

Can someone please clarify a point for me.

If I have a series of 'cards' all introduced by headings and under each card there is a control and they are all called 'find out more'

You click the control and more information expands

To me, the 'label' (i.e., the text which helps me identify the purpose of the control) includes the heading information. On its own 'find out more' is meaningless. I would say the heading needs to be programmatically associated as part of the button label to pass 1.3.1. Is this correct? Or is it ok because the heading is marked up as a heading?

This leads to my main question which is about links. If there is text adding context to a link, but is not programmatically associated with the link, should this fail 1.3.1? Just like it would for form labels that are not programmatically associated?

I am confused about how link labels are treated in comparison to other control labels. Does 'headings and labels' apply to link labels?

Thanks

Sarah

Sent from Outlook for iOS<https://aka.ms/o0ukef>

--
Chaals Nevile
Using Fastmail - it's worth it