Views exposed form + form fields: Improve AT usability

[alisonjo315]

For this task, use the exposed filter form on the News listing page (via PR #89).

1. Add aria-describedby to form fields:
   • Some form fields have description/help text under them, in addition to field labels
   • These fields would be more accessible/assistive-tech-user-friendly if the description text were programmatically associated with its field, via aria-describedby.
2. Add role="Search" aria-label="Filter results" to the <form> element.
   • Based on WA fix during Kavli project.
   • (Whether or not the lack of these attributes is a strict failure is a little squishy -- or it was a little squishy when we talked about it on #cd-lassp-kavli-wa-issues in June 2023 -- but it is an AT UX improvement, so let's do it, or at least try!)

Thing 1

Example markup, based on text search/filter on Einaudi > News (edited for length):

<div class="js-form-item form-item js-form-type-textfield form-item-text-search js-form-item-text-search">
  <label for="edit-text-search--2">Search</label>
  <input type="text" id="edit-text-search--2" name="text_search" value="" aria-describedby="edit-text-search--2--description">
  <div id="edit-text-search--2--description" class="description">
    Simple text search.
  </div>
</div>

Thing 2

On Kavli, we had to add a template/theme suggestion in .theme, then a custom template. Full details can be seen in this commit:
bd294671c7d

• As far as I could tell, each views exposed form needs its own template file.
• With that ^^ in mind (as you'll see in the commit details), we created an "include" template file, that could be reused as needed, per-view-exposed-form.

Example markup, based on text search/filter on Kavli > News and Events:

<form action="/news-events" method="get" id="views-exposed-form-news-page-listing" accept-charset="UTF-8" role="search" aria-label="Filter results">

---

To do

⚠️ Alison: Refresh this to-do list!

• Decide: We should do this, right?
• Decide: Just target views exposed forms, right?
  • Only other public-facing fields I can think of are webforms, and we don't have Webform included with our base Drupal implementation. (Site search, yes, but the site search text field doesn't have help text.)
• Create template override (core/modules/system/templates/input.html.twig)
  • May need to add template suggestion to cwd_base.theme.
• Test / review / release
• Optional: Create companion issue on cwd_claro for content entry fields. (Why not make those forms more usable, right?)

---

Suggested by Hank on Slack, with this reference: https://www.tpgi.com/using-aria-describedby-to-provide-helpful-form-hints/

[sg667]

Yes, this should be done - I believe we have even done this already on some of our sites, potentially not all though as not all sites have form fields with additional descriptive text. (Although I may just be thinking of Laravel stuff, not Drupal)

While I'm not the most knowledgeable on the team about form creation on Drupal, is this going to add an optional field to add descriptive text when creating forms?

[alisonjo315]

Thanks for the feedback @sg667!

The field description/help text is already an optional thing you can fill in when you configure exposed filtering forms on Views. In other words, when you set up a listing page, if that listing page has filtering options for end users (i.e. "filter this list of news by category / text"), when you configure those filters, you can set a label and a description. (Technically, the label is also optional?! I never noticed that before lol, wow.)

Below is a screenshot/excerpt of the configuration form for a views filtering field.

Does that make sense and answer your question, or not really?

[alisonjo315]

Wrinkle: There are no views on our Drupal demo site that have exposed forms, so we can't actually show/test it on our demo site! -- maybe let's add an exposed filter to a view on our demo site?? https://github.com/CU-CommunityApps/cd_drupal_upstream/issues/80