Elements on grouped exposed filters configuration form are missing accessible names

This is still an issue. Tried playing around with this but just adding a title to the 'group default' for example leads to this gem:

So unfortunately the build up of the HTML of that form makes this more difficult than one might expect.

In case somebody wants to take a stab at this, the form can be found in \Drupal\views\Plugin\views\filter\FilterPluginBase::buildExposedFiltersGroupForm

Could someone provide steps to reproduce this?

I'm not seeing the popup from the screenshot in the issue summary.

Added steps to reproduce

Believe this could be a symptom of
https://www.drupal.org/project/drupal/issues/2839344

It looks like the Remove checkboxes have been fixed.

I found other cases: The textfields for numerical filters. I think it's called the "in operator".

I think I have a fix, and will update the IS and create an MR. I think this is testable in Nightwatch.

I was wrong about the Remove checkboxes. They are still missing labels.

The strange thing is that it looks like they're not supposed to be visible. There's this comment in the code, and they don't appear when the admin theme is Stark.

// No title is given here, since this input is never displayed. It is
// only triggered by JavaScript.

Yeah, the Remove checkboxes have display: none in the views_ui module and in Claro.

Claro then overrides that with .form-boolean. It's probably an accident because it's a generic selector. I haven't checked Gin.

I think there's a bigger issue of whether they should be visible at all, but I'm planning to give them a hidden label due to #933004: Test that all form elements have a #title for accessibility (which will require a #title property).

The Remove checkboxes are also visible in Gin. Based on #3375806-14: Views 'Rearrange' dialog show the 'Remove' checkbox, which should be visually hidden, it looks like they should be hidden with the js-hide class in another issue.

Does this need to be a nightwatch test or can it be javascript? Just because I've heard that nightmatch may eventually be removed.

To be robust, it really needs to check for the computed accessible names.

It would be possible to check the underlying HTML (like looking for label elements), but to me that's indirect because the end goal is the computed name that users perceive, not the specific HTML.

It's also more brittle because tests could fail or have false positives if the page output has another naming method for some reason. Tests would have to keep up with the HTML changes. They could, but that would bring its own maintenance problems...

AFAIK, our current functional javascript tests can't compute the accessible name, and it's not easy to do it with vanilla JS.

Nightwatch can do it for individual elements with the getAccessibleName() function, but a full Axe scan will check the whole page.

I did it this way because it looks in line with #2857808: Automate Accessibility Checks for Core (esp Phase 2), and Views / Views UI don't have good coverage. It's a starting point for adding more complex cases.

Even if "standard" Nightwatch tests get replaced there's no good alternative for Axe tests until #3338664: Migrate Nightwatch Axe tests to PHPUnit lands.

I have to admit that I don't love the specifics of the test, though. It would be better if it used findByLabelText() in the setup for the page. It would probably be more robust if it created a simple test view instead of depending on an existing view that comes with the installation profile. But these won't matter if the test is going to be converted to a functional javascript test with #3338664: Migrate Nightwatch Axe tests to PHPUnit.

Not saying it has to change but isn't this now just checking for labels? There existing javascript or functional test that could be expanded for this.

Not saying it has to change but isn't this now just checking for labels? There existing javascript or functional test that could be expanded for this.

The computed accessible names could come from label elements, but they could also be established in other ways like aria-label or aria-labelledby.

PHPUnit / Functional Javascript can't get computed accessible names yet, to my knowledge. The computation is complex, so using Axe takes advantage of its accessible name computation.

There existing javascript or functional test that could be expanded for this.

I realize that I missed "javascript" here...

The navigation module has its own "a11y" test, and it's in a separate file from the other JS tests. Looks like that was done in #3393400: Implement Nightwatch tests for Navigation module.

I was trying to follow that precedent for views_ui.

Will leave for others but personally I think less nightwatch the better

FWIW, there were some changes related to this already made on #933004: Test that all form elements have a #title for accessibility.

That MR includes a check for empty #title properties, which is catching most of the remaining cases from this issue (by way of ExposedFormUITest.php).

I confirmed by applying the rest of the changes here in ::buildExposedFiltersGroupForm(), and the tests went green. So it functions as a rough test that the changes were made.

It does not catch the missing name for the first item in the table, because that is removed in a theme function.

It may make sense to roll the remaining PHP changes from this issue into #933004: Test that all form elements have a #title for accessibility and closing this one as a duplicate.

If this strategy is palatable, I'll make the changes in that MR.

Also, the name for the radio button in the top-left of the table next to "" should probably be "Any", if it isn't already.

I made a comment on the MR to check this.

I went ahead and put these changes into #933004: Test that all form elements have a #title for accessibility.

As part of splitting up #933004: Test that all form elements have a #title for accessibility, I've refreshed the MR.

I removed the Nightwatch test and am hoping we can skip the addition of tests for now since the goal of #933004: Test that all form elements have a #title for accessibility is to add a single test for all cases.

The current failing test looks unrelated and passes locally (albeit with unrelated deprecation notices). I created a random test failure issue.

Would someone please rerun the failing job? I can't.

I manually applied the patch to a Drupal 11 environment (I couldn't run the actual branch, it requires PHP >= 8.5 which DDEV doesn't support yet). The code paths are identical, so I believe the results hold, but please factor in this limitation.

Test setup: built-in content view, grouped exposed filter on status, tested via the filter configuration dialog in Views UI.

Results verified via DevTools inspection:

Operator <select> label now present in DOM, correctly associated:

<label for="..." class="form-item__label visually-hidden">Operator</label>
<select id="..." name="options[group_info][group_items][1][operator]">...</select>

Remove checkbox label now present:

<label for="views-removed-1" class="form-item__label visually-hidden">Remove</label>
<input type="checkbox" id="views-removed-1" ...>

"Any" radio (Default column) label now present:

<label for="..." class="form-item__label visually-hidden">- Any -</label>
<input type="radio" value="All" checked="checked">

I hope this is useful, happy to be corrected on anything I missed.