Re: Labels

Hi Adam

Thanks for your reply, it hits on exactly the heart of the discussion we are having in person here.

So 'out of context' means when you isolate a label from the surrounding page content - so it's out of the context of the page. A JAWS forms list is an example, or tabbing. A screen reader user having to search the surrounding page content is what we want to ideally avoid. We would like labels to be descriptive both in and out of context.

1.3.1 ensures visible labels (aka the text helping you identify the purpose of the control) is programmatically associated with the component. Here, the buttons have a label 'remove' - but I would argue that alone does not help you identify the purpose of the control, the surrounding text is also required to know what your are removing and is therefor part of the label. Remember 'label' is not the same as the programmatically determined accessible name.

When relationships are not programmatically determinable that is 1.3.1. When the visible label string is not entirely contained within the accessible name, that is label in name, so I'm wondering if they are relevant here.

But my main question is with regards to headings and labels AA. Multiple controls on the page have the same label 'remove' - when encountered in context, that doesn't matter, because the context of the surrounding page helps determine the purpose of the buttons. But out of context for a screen reader user aka in jaws forms dialog, this is not descriptive and users would have to switch navigational methods to identify the purpose of the control. The debate I am trying to resolve is whether this fails 'headings and label'. I would argue it doesn't because if something is non-descriptive out of context only, so descriptive in-context, that suggests some sort of context within the page that should be programmatically associated and therefore is a higher fail 1.3.1

Ultimately, it all comes down to people's opinions on whether the remove buttons fail headings and labels.

Do the remove buttons fail headings and labels?

You can ignore the focus issue as it isn't part of the question at all. I know about managing focus. I also don't need a solution, I know how to create a solution. My question is - do labels which are non-descriptive to screen reader users out of context, but descriptive in context, fail headings and labels. That's really all I want to know.

Thanks

Sarah

Sent from Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Adam Cooper <cooperad@bigpond.com>
Sent: Wednesday, June 18, 2025 1:57 am
To: 'Ms J' <ms.jflz.woop@gmail.com>; 'w3c-wai-ig' <w3c-wai-ig@w3.org>
Subject: RE: Labels

Regardless, it’s a very ugly pattern …

just because there’s a heading immediately above something, doesn’t – in my view at least – satisfy 1.3.1.

From a usability perspective, it means I(20 years plus screen reader user) need to be using a navigational technique at that point in the view which employs headings or start pressing keystrokes that can reveal known programmatic relationships or – worst case – move focus off a control to use cursor keys to explore the immediate context.

Also, what does  “non-descriptive out of context” mean?

In my view, context isn’t a criterion for 2.4.6 - only that a heading or label describes a topic or purpose. And, because success criterion 2.4.6 is normatively ambiguous, ‘remove’ can describe a purpose seemingly perfectly adequately if not accurately.

And label-in-name isn’t relevant because the label is in the name – it’s not about whether the label and/or name is accurate.

I’ll probably receive howls of puritanical protest, but – thanks to another normative ambiguity – it could be argued that the accessible name of these controls does not describe their purpose in a way that is equivalent as per success criterion 1.1.1 ….

In terms of solution, a little bit of JavaScript that climbs the DOM looking for the h2 above each button and then adding its text node to an aria-label on the button (or using aria-labelledby in a  similar fashion) will improve the usability for people using screen readers.

This still leaves the issue of managing focus as per 2.4.3 when the button is activated.





From: Ms J <ms.jflz.woop@gmail.com>
Sent: Tuesday, June 17, 2025 7:12 PM
To: 'w3c-wai-ig' <w3c-wai-ig@w3.org>
Subject: RE: Labels

Hi all

 thank you, so for context, here is a sort of motivating example

<h1>shopping cart</h1>
<h2>Apples</h2>
<button>remove</button>
<span>these apples are delicious </span>
<h2>Bananas</h2>
<button>remove</button>
<span>these bananas are yellow </span>

my 3 questions are would the remove buttons fail

  1.  Headings and labels as for a screen reader user these are non-descriptive out of context?
  2.  1.3.1 - in this case as the sections are marked up with headings, I would say they perhaps don't fail 1.3.1?
  3.  label in name? Because the label which allows you to identify the purpose of the control is not just the text 'remove' but also the heading text allowing me to identify what I will be removing
 thank you

Sarah

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