fix articles page sort, filter, search

[StephDriver]

closes #5464
closes #5471

[StephDriver]

These changes are all about the articles page.

• fix a bug in OLH that meant the sort wasn't working.
• improve accessibility so that page is compatible with keyboard and screen reader
• improve accessibility (readability) by changing button labels to sort, filter and search instead of a mix of apply and those terms. Nice and clear which one applies which.
• changes css so that the clear all and apply all buttons in the filter are quieter than the filter itself.
• tweak css so that the elements within the sort block are neatly aligned (as previously in Clarity, but not great in other themes).

Added two template tags

• one is for including aria in form fields - this was needed to make the date fields screen reader compatible, but is likely to be useful elsewhere. A template tag is needed because you need to pass in the relevant ID to the relevant field, and hte id may only be known through loops of the calling template, i.e. not static.
• other is for adding ids that aren't duplicates to elements that otherwise would be duplicated due to the way they are generated (e.g. in a loop). IDs being needed for describedby and labelledby but also needing to be unique on the page for valid HTML.

[joemull]

Mostly looks good. Two questions

[joemull]

I thought we weren't changing this theme any more? Visual changes to the Material theme will interfere with people's custom styling (they often use Material for custom styling) and increase the volume of support queries during the 1.x LTS term

[StephDriver]

During the previous 1.9 work I got the focus-visible working across Material. for some reason this part was either missed, or the change lost during a rebase, so this felt like it was simply fixing something already supposed to be complete.

[joemull]

Sorry, I'm not talking about focus-visible styles, I'm talking about the secondary quieter button styles. The visual change there will be something that stands out on the page, won't it? Is it strictly necessary? With this change we'd be effectively introducing a new style of button for a theme that we want to reduce the maintenance burden for, and it might have the opposite effect.

[StephDriver]

I mostly did that because it looked pretty confusing to me without that change. But I take the point, it's not strictly necessary, more something that was quick while I was there on a page that is unlikely to get more attention any time soon. Having go the rest of it working, the two minutes that required seemed a good use of time to reduce confusion (and the other themes were like that, so not unprecidented. It felt like fixing an oversight.

But I take your point. And I certainly don't think it's worth debating so I've remove that change.

[joemull]

Why is aria needed here? Do we know why VO does not use the standard relationship established by id and for to create the expected behavior?

[StephDriver]

Yes, this came from actual testing with VO. And then some digging into why it wasn't working, trying of different solutions until I found one that did provide the right information.

[joemull]

Testing it only establishes that it is happening, but have you been able to discover why it does that? Asking why is relevant because manually overriding the relationship between elements with ARIA in this way goes against well-accepted guidance and good practice about how to use HTML and ARIA for accessibility. At the least, it is worth uncovering why so that we can be sure we are not working against a VO feature. At most, we can document the reason in a code comment so that when reading this code in the future, we will not think it is a mistake and remove it.

[StephDriver]

This is from my browser history when I was investigating this problem.

• https://stackoverflow.com/questions/62882886/safari-voiceover-issue-when-reading-input-field
• https://stackoverflow.com/questions/35215298/safari-osx-voiceover-not-reading-aria-label-for-input
• https://bugzilla.mozilla.org/show_bug.cgi?id=1611428
• https://dev.to/mfranzke/voiceover-bug-on-ios-safari-blocks-date-time-related-inputs-especially-in-react-4f61
• Modal Dialog Example: Input labels not read by VoiceOver w3c/aria-practices#669
• https://bugs.webkit.org/show_bug.cgi?id=294649
• https://hassellinclusion.com/blog/input-type-date-ready-for-use/

Collectively from these I concluded:

1. My test results were not unique - the root cause had been a known problem for some time.
2. Aria could not be relied upon for Date fields.
3. a work around to make the field usable with screen readers that didn't rely on the standard "lable for" OR a custom date input field was needed. The workaround was the smaller code-change.

[joemull]

See comments above (not attached to this review but separate--apologies)