Re: Labels

Additional context: some of the most common feedback I see with regards to screen reader users is 'this button was not descriptive to me out of context - I had to switch navigational methods to search the surrounding content which is time consuming' - this is very common, close buttons, remove buttons, delete buttons, but also more bespoke ones...  many pages have duplicated cards or panels with similar controls for different things... 'like', 'comment' etc

So my question is, are these considered 'non-descriptive' as per headings and labels? I would have thought no on the basis that if they are only non-descriptive out of context, then there must be some relevant context that is not programmatically associated with the control? But that's what I'm trying to clarify/understand. It seems like a very specific question, but it's actually a very common issue that comes up.

Thanks

Sarah

Sent from Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Adam Cooper <cooperad@bigpond.com>
Sent: Wednesday, June 18, 2025 1:57:27 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?

  1.  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?

  1.  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>