RE: Labels

Some of the problem lies in the definitions of identify, describe, and
descriptive in English . as I have asked this list before to no avail, it
would be interesting to know whether the ambiguity that is often encountered
in WCAG .x with these terms is also present in languages other than English.

 

You may be interested in the following GIT issue
:https://github.com/w3c/wcag/issues/3984

 

I'd be interested to know what your thinking is after reading this and the
other GIT issues cross referenced therein especially with the overlap with
1.1.1 which you touch on below.

 

As I said earlier in this thread, there is a sound argument for SC1.1.1
requiring that controls have a name that describes their purpose. 

 

 

 

 

From: Ms J <ms.jflz.woop@gmail.com> 
Sent: Thursday, June 19, 2025 6:11 PM


To: Adam Cooper <cooperad@bigpond.com>; 'w3c-wai-ig' <w3c-wai-ig@w3.org>
Subject: Re: Labels

 

Hi Adam,

 

Thank you, this is really helpful!

 

Yes, I think I was interpreting 'identifying a control' to mean identifying
their purpose, but you're right, it must just mean indicating their presence
and then the SC build specific requirements at different severity levels.
Although, it does make 3.3.2 somewhat confusing, as this SC says the purpose
is to 'present instructions or labels that identify the controls in a form
so that users know what input data is expected' - but if we take
'identifying a control' to not require the label be descriptive of the
purpose and leave that to 2.4.6, then there's actually no reason that
providing a label would help users 'know what input data is expected'. It
almost negates the need for 3.3.2, because an arbitrary label like 'bob' is
arguably no better than no label at all, you could just have 2.4.6 include
the requirement for a label to be present. once again, trying to pin down
the SC ends up raising more questions! But you have already answered my
question very helpfully in that tighter definition of a label means that the
additional context is not required to be formally taken as part of the label
and therefore not required to be programmatically associated as the
accessible name.

 

Yes, you are right, and made me think of a new way of phrasing my question -
which is, does 2.4.6 also require the accessible name be descriptive (where
it is specified). Because, for a screen reader user, the 'label' as they
will encounter it, is really the accessible name, and it may be different
from the visible label - for example, if an aria-label is used as an
alternative to an icon label. Although, I recognise this is more covered
under 1.1.1 if the aria-label is not sufficiently equivalent to the icon.
And arguably, when viewed in isolation, the label 'remove' isn't descriptive
for anyone, because it doesn't state what it is that will be removed -
further information is required.  

 

I think my confusion here primarily rests in that my interpretation of
whether a label is descriptive may differ depending on whether I look at it
as a part of the page, or whether I look at it from, for example, a JAWS
forms list. But if we did agree that 'remove' was not descriptive on its
own, then the solution would be to add more context into the visible label
for all users, as the SC focuses on all users not just screen reader users.
However, in the case where a sufficient solution would be to include some
hidden context into the label for a screen reader user only, then this
doesn't really come under 2.4.6 as the descriptiveness of a label should
apply to everyone. 

 

So, it seems to me that headings and labels 2.4.6 actually requires that the
label be descriptive enough to identify the purpose of the control in
context, and does not require that the accessible name be descriptive enough
when considered in isolation (obviously there are other SC to cover cases
where label and accessible name do not match)?

 

Thanks again, 

 

Sarah

 

 

 

From: Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> >
Date: Thursday, 19 June 2025 at 05:27
To: 'Ms J' <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> >
Cc: 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
Subject: 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 <mailto:ms.jflz.woop@gmail.com> >
Sent: Thursday, June 19, 2025 12:02 AM
To: Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> >;
'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto: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 <mailto:cooperad@bigpond.com> >
Sent: Wednesday, June 18, 2025 1:57 am
To: 'Ms J' <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> >;
'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto: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 <mailto:ms.jflz.woop@gmail.com> >
Sent: Tuesday, June 17, 2025 7:12 PM
To: 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto: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>