Admin list filter fields are inconsistently labelled.

Problem/Motivation

Consistency survey propmpted by 🐛 View Search Filter's Label isn't Associated with Input Active .

The filters at the top of various admin listings make inconsistent use of form labels, descriptions, title attributes, and placeholders.

Accessibility issues

• Some inputs have no programatically associated label, so accessible name calculation falls back to the title attribute.
• Some inputs have title attributes that only mouse users benefit from, vs. a Form API #description which is available to all users.

Survey of listing filters in Drupal core

• Content (admin/content) - This one is doesn't filter until submitting a form. 1 text input and 3 selects.
  • label: "Title" or "Content type", or "Published status" or "Language".(associated using for). These are node entity fields.
  • description: none (no aria-describedby)
  • placeholder: none
  • title: none
• Comments (admin/content/comment) - This one is doesn't filter until submitting a form. There are two text inputs, and one select.
  • label: "Subject" or "Author name" or "Language" (associated using for). These are comment entity fields.
  • description: none (no aria-describedby)
  • placeholder: none
  • title: none
• Files (admin/content/files) - This one is doesn't filter until submitting a form. 2 text inputs, 1 select.
  • label: "Filename" or "MIME type" or "Status" (associated using for). These are file entity fields.
  • description: none (no aria-describedby)
  • placeholder: none
  • title: none
• Place block dialog (admin/structure/block)
  • Label: "Filter" (NOT associated with input, with a visually-hidden class
  • description: none (no aria-describedby)
  • placeholder: "filter by block name"
  • title: "Enter a part of the name to filter by"
• Custom block library (admin/structure/block/block-content) - This one is doesn't filter until submitting a form. 1 text input, 1 select
  • Label: "Block description" or "block type" (associated using for). These are block entity fields.
  • description: none (no aria-describedby)
  • placeholder: none
  • title: none
• Views (admin/structure/views)
  • Label: "Filter" (NOT associated with input, with a visually-hidden class
  • description: none (no aria-describedby)
  • placeholder: "fFilter by view name, machine name, description, or display path"
  • title: "Enter a part of the view name, machine name, description, or display path to filter by."
• Views options dialogs (on any view configuration page, e.g. admin/structure/views/view/content, dialog presented after pressing add button for Fields, Filter Criteria, Sort Criteria, Header, Footer, No results Behaviour, etc. , )
  • label: "Search" or "Category" (associated using for). One text input, one select input.
  • description: none (no aria-describedby)
  • placeholder: none
  • title: none
• Extend (admin/modules)
  • label: "Filter modules" (associated using for, with a visually-hidden class
  • description: "Enter a part of the module name or description" (associated with aria-describedby)
  • placeholder: "filter by name or description"
  • title: no title attribute
• Uninstall (admin/modules/uninstall)
  • label: "Filter modules" (associated using for, with a visually-hidden class
  • description: "Enter a part of the module name or description" (associated with aria-describedby)
  • placeholder: "filter by name or description"
  • title: no title attribute
• Testing (admin/config/development/testing)
  • label: "Search" (associated using for
  • description: none (no aria-describedby)
  • placeholder: "Enter test name…"
  • title: "Enter at least 3 characters of the test name or description to filter by."
• URL Aliases (admin/config/search/path) - This one is doesn't filter until submitting a form.
  • label: "Path alias" (associated using for). Visually-hidden label, but nested in a details/summary group called "Filter Aliases", which makes 3 different terms!
  • description: none (no aria-describedby)
  • placeholder: none
  • title: none
• People (admin/people) - This one is doesn't filter until submitting a form. 1 text input, 3 select.
  • label: "Name or email contains", "Status", "Role", or "Permission". (All associated using for). These are user entity fields.
  • description: none (no aria-describedby)
  • placeholder: none
  • title: none

Proposed resolution

Establish better consistency among these and/or consider whether the differences are justifiable.
They can be grouped in certain prupose + behaviours, in which case aim for consistency in each group pattern:

• dynamic JS filters, no form submission
• config entity filters, usually only 1 or 2 filters.
• content entity filters, usually have several filters (typically 3+), require form submission, typically have bulk operations

Accessibility:

• prefer a concise <label for> instead of falling back to lengthy title attributes.
• prefer visible Form API #description to HTML title attribute, as this is more robust and reaches more users.

Remaining tasks

TBD - use child issues where appropriate.

• 🐛 View Search Filter's Label isn't Associated with Input Active . Fix form filter on main views listing page, use an for attribute to associate the label.
• NEEDS CHILD ISSUE: Fix "place block" form filter, use an for attribute to associate the label.

User interface changes

TBD. Consistency for accessibility and usability.

API changes

None.

Data model changes

None/