RE: Labels

In answer to your primary question and strictly speaking, the answer is no -
it fails neither 1.3.1 nor 2.4.6. 

 

Let's be clear, however, WCAG 2.x is fundamentally deficient in its
requirements for this and many other similar cases. 

 

WCAG is not interested in navigational nor operational efficiency more is
the pity - only whether an action can be completed effectively (and
sometimes within a specified timeframe).

 

The 'out of context' you describe is problematic, though.  

 

First, because what is presented in a forms dialog, for example, is actually
the accessible name as per the normative definition of name and not a label,
and , second, because context in a broader sense can often be added by user
agents rather than authors.

 

The 'context' of this button is 'programmatically determinable' as per 1.3.1
and its label describes its purpose as per 2.4.6 otherwise pressing JAWS + T
wouldn't announce either the button label or its 'context' (other screen
reading applications have similar functions, but different keystrokes . NVDA
+ T only announces the window title, for example, but pressing NVDA NumPad 5
or NumPad 7 progressively announces previous and next items  thereby
providing a context).

 

By my way of thinking, the NVDA way is preferrable because it uses a
'native' structure rather than relying on developers to code in particular
ways to establish relationships of 'programmatic determinability'.

 

But the notion of 'programmatically determinable' is  broken here too
because these established relationships of elements in the DOM are of
technologies from yesteryear that have been baked into various
specifications and can be broken by user agent and code implementations.

 

(wrap the headings in a <section> and the button in a <nav> and JAWS won't
read the h2 In Chrome for example).

 

And the normative definitions of 'label' and 'name' require only that they
identify a component not describe it . nor require any reference to context
whatsoever.

 

With regards to 2.5.3, 'remove' is contained in both the label and the
accessible name, so, unless the accessible name is overridden by aria-label
or aria-labelledby and doesn't contain the word 'remove', then it similarly
satisfies this success criterion. That someone cannot target each individual
button directly or immediately with a single voice command is not relevant
to this success criterion (Dragon can present a dialog with each button in a
way similar to JAWS forms list dialog from which someone can select one). 

 

Also, people using speech to text software (usually) have functional vision
such that they can perceive the context of each button (i.e., the heading)
and interact with it accordingly so don't necessarily need to target a
single component in the same way a screen reader user might . 

 

 

In any case, one of the reasons why this issue is so hard to resolve is
because of the equivocality and ambiguity inherent in WCAG 2.x which recent
amendments to the informative documentation don't do anything to clarify in
my view . the W3 won't be changing 2.x normatively any time soon so we can
only hope that WCAG 3.0 doesn't have as many gaps.

 

 

 

From: Ms J <ms.jflz.woop@gmail.com> 
Sent: Thursday, June 19, 2025 12:02 AM
To: Adam Cooper <cooperad@bigpond.com>; 'w3c-wai-ig' <w3c-wai-ig@w3.org>
Subject: 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>