So, I verified that the class is being removed but correct me if I wrong, the updated labels should come at the highlighted place right? If so, they aren't being shown here.

Edit:
The problem seems to be in layouts/joomla/searchtools/default/bar.php at line 42.

This condition seems to cause the issue.

The labels are deliberately not visible. Just because you dont display a label on the screen doesn't mean that you don't need to have a label on every input. This is very important for accessibility

I'm not asking why the labels are hidden, I understand that.

Take a look at the text of label, the correct text isn't being displayed and I think it's caused due to this particular code.

Edit:
The problem seems to be in layouts/joomla/searchtools/default/bar.php at line 42.

joomla-cms/layouts/joomla/searchtools/default/bar.php

Lines 42 to 48 in e317fe2

	<label for="filter_search" class="visually-hidden">
	<?php if (isset($filters['filter_search']->label)) : ?>
	<?php echo Text::_($filters['filter_search']->label); ?>
	<?php else : ?>
	<?php echo Text::_('JSEARCH_FILTER'); ?>
	<?php endif; ?>
	</label>

This condition seems to cause the issue.

Sorry - I understand you know. I will submit a patch shortly

That's alright, my intention was just to help. Could have added a clearer screenshot though, will keep that in mind. ?

So this PR is correct. What you have identified is a bigger possible issue effecting many components which I need to look at the reason for that code before proposing a solution in a separate PR

Yes, @brianteeman would you mind if I create an issue for this?

No need to create the issue - I will do a full PR when I get to the reasoning

I have looked back into the history and I cant see why the conditional statement was introduced back in #10090

I think it's there in case there isn't any label provided. The thinking may have been to check if any label was provided, in case there wasn't any, then to fallback to a standard "Search" label. But since this condition isn't proper, it keeps on falling back to the default. So, We would have to change that particular condition.

I suspect that at the time the code was introduced there were search fields that didnt have a label so this was a quick and dirty attempt to make sure they all got a label. In which case we can probably just kill the if statement as they all have a valid search label now.

Or just fix the condition so that it actually does what it was intended to do. Display the search label for the field and if there isnt one to fallback to the global string.

If you want to have a try at creating a PR for that then go for it

Or just fix the condition so that it actually does what it was intended to do. Display the search label for the field and if there isnt one to fallback to the global string.

If you want to have a try at creating a PR for that then go for it

Yes, I would love to!
I think it's best if we have a fallback just in case a label isn't present.

Just noting that the label does not appear in the source and waiting for a bigger fix before testing.

@ceford #32660 and #32670 must be tested together.

@chmst I think this one would be ready to commit as soon as #32670 is merged which is RTC but haven't been merged yet.

I have tested this item ✅ successfully on 6e3a2c2

I have tested this item ✅ successfully on 6e3a2c2

RTC

Thanks!

thanks