Closed (duplicate)
Project:
Drupal core
Version:
11.x-dev
Component:
views.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
9 Sep 2025 at 21:42 UTC
Updated:
12 Jan 2026 at 16:46 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
kentr commentedComment #3
kentr commentedFirst draft in issue branch. Still needs tests.
Comment #5
kentr commentedComment #6
acbramley commentedNightwatch tests are extremely inefficient and are likely being phased out eventually (see #3467492: [policy, no patch] Replace Nightwatch with Playwright).
The test here can be rewritten as a functional test that just checks for the label and uses a test view that's already defined in yaml.
Comment #7
kentr commentedChecking just for the
labelelement is brittle because there are multiple ways to nameelementsform controls. It's more robust and more closely resembles user interaction to use a tool that gets the computed name. AFAICT, PHPUnit can't do this out of the box even with the selenium webdriver, but Axe and Nightwatch can.This Nightwatch test also uses a full Axe check that covers the whole page and can be expanded to cover more exposed filter cases, in line with #2857808: Automate Accessibility Checks for Core. Views doesn't have good coverage.
#3338664: Automated A11y tests in PHPUnit was chosen to replace the Nightwatch + Axe tests, but it's stalled.
It may start moving soon, but if it doesn't:
Even if standard Nightwatch tests move to Playwright, the accessibility tests will have no replacement until until #3338664: Automated A11y tests in PHPUnit lands. I vote for having better accessibility test coverage in the interim and converting tests to PHPUnit then.
I tried to use one of the existing test views but didn't find a means outside of PHPUnit. Using one of the existing standard views (like Frontpage or Content) seems brittle because they may be removed from the testing profile. This is how I arrived at creating a simple test view in the test.
Comment #8
cboyden commentedThis is not just an issue with numeric filters, it is a general issue with exposed filters where the operator is also exposed. For example, if you follow the steps in the issue summary and also add exposed Content type and Tags filters with exposed operators, you will see the same problem.
Comment #9
cboyden commentedUpdated issue summary with steps to reproduce and screenshots showing three types of exposed filters/operators with errors.
Comment #10
cboyden commentedComment #11
kentr commented@cboyden It looks like the errors for the Content type and tag / vocabulary filters are fixed by #933004: Test that all form elements have a title for accessibility. I see the errors in
11.xbut not with the MR from that issue.Based on the scoping docs, the precedent set by that issue, and a (very old) comment by @sun regarding the earlier effort to fix missing titles, I'm going to roll these
#titlefixes into #933004: Test that all form elements have a title for accessibility.That issue adds a check for empty
#titleproperties, which should catch these cases for now and defer the question of better accessible name tests and / or Axe coverage.It did catch the original numeric filter problem in this issue, and that particular test passes locally when I apply the changes from this MR to
NumericFilter.php.Closing as duplicate of #933004: Test that all form elements have a title for accessibility.