YALB-1233: Improved term picker with ChosenJS

[dblanken-yale]

YALB-1233: Improved term picker with ChosenJS

Description of work

• Add Chosen module
• Add composer-merge-plugin to handle jjj/chosenjs dependency through composer
• Change Page, Post, and Event tag entry to use chosen
• Change Event category to use chosen
• Change View block's include/exclude fields to use chosen
  • Change listing of include/exclude fields to be sorted by name for easy traversal
• Changed chosen dropdown colors to provide proper contrast for accessibility
• Updated help text associated with content types to convey that they cannot add items

Functional testing steps:

Locally

• Perform a fresh install using npm run setup
• Ensure that the chosen directory exists afterward in ./web/libraries

Locally or Remotely

• Create multiple tags and categories beforehand as you cannot add while creating content types
• Create/edit a post and verify that you can use chosen to select tags
  • Verify while creating that you can view the help by clicking the ? mark and that it is clear and concise
  • Verify that upon save, you can edit and see the tags pre-selected
• Create/edit a page and verify that you can use chosen to select tags
  • Verify while creating that you can view the help by clicking the ? mark and that it is clear and concise
  • Verify that upon save, you can edit and see the tags pre-selected
• Create/edit an event and verify that you can use chosen to select tags and categories
  • Verify while creating that you can view the help by clicking the ? mark and that it is clear and concise
  • Verify that upon save, you can edit and see the tags pre-selected
• On the page created above, add a view block
  • Ensure that you can add include/exclude items and save
• Validate that the correct items are displayed in the view based on the items you selected
• Edit the view and ensure that the items you selected before have been pre-selected
• Think about if there are any places I've missed using Chosen on: so far my focus has been on the content type tags/categories, and the view block filter.

Accessibility testing steps:

• Do the above functional testing steps on the remote site and verify that the selected drop down items and the unselected drop down items have a proper contrast ratio that meet A/AA standards.
• Document any other findings that we could possibly create a ticket for and discuss at another time for fixes to either this platform or to chosen upstream.

[github-actions]

Created multidev environment pr-334 for yalesites-platform.

[github-actions]

Created multidev environment pr-334 for yalesites-platform.

[github-actions]

Created multidev environment pr-334 for yalesites-platform.

[joetower]

@dblanken-yale CSS additions looks great to me!

[myvaughn]

I will defer to @kara-franco on this, but I approve use of this control for now with the CSS fixes Dave was able to make. This control is better than the Autocomplete Deluxe that was being considered. Longer term, we might consider building our own component for this or wait to see what Drupal core comes up with as a replacement for autocomplete. Since we don't want new terms to be added with this control, the Drupal core option may never be what we want, however.

[kara-franco]

The CSS tweaks for the selected menu items looks great! The colors pass the color contrast triangle: https://contrast-triangle.com/?linkColor=%23058260&textColor=%23082538

For future updates/fixes we can:

• Replace the negative tabindex on the remove/close buttons with tabindex=0
• Enhance the focus indicator color for the remove/close buttons
• Add an aria-label="Remove" to the x buttons
• When a SR user selects the term, feedback needs to be given (Combobo example)

Reference screenshot:

Combobo example: https://dequelabs.github.io/combobo/demo/

[codechefmarc]

Tested this on the multidev and all looked good to me! I'm approving, but a few notes:

1. You can add links into the description box for the tags/categories that can open a new tab to add new terms. Not sure if we want to do that or not. I seem to recall that Franz liked that you can't easily add terms - that it has to be a deliberate action so your solution is probably just fine.
2. I see you've added a few methods to the ViewsBasicManager that will get the terms and the labels - with vocab. Nice! So, is the code here (https://github.com/yalesites-org/yalesites-project/pull/334/files#diff-f1390886a6a1a2acfda94028c41660896cd1781aba805deb4a13e6e6671a710dL221-L227) needed anymore? (Same goes for terms_exclude field) I didn't test, but I assume you can get rid of the #selection_handler and the #selection_settings and even delete the view I created called "Taxonomy Lookup" (located here: /admin/structure/views/view/taxonomy_lookup)? It all works as coded now, but perhaps test trying to remove that code and delete the view since your code replicates that and we don't want orphaned things in there. Thanks!

[dblanken-yale]

@codechefmarc You are absolutely right. I was unsure if those settings were only related to the previous autocomplete or not, so didn't touch them. I removed them and all looks to work well. Thanks for that feedback.

Yes, I was hesitant to provide the link as well. I figure if it's decided it's too verbose, we can update that quickly. :D