Better accessible name for Filters button and tab

[obulat]

Problem

#826 added a counter to the filters button and filters tab. The labels for these filters appear in two places:

• VFilterButton on wider viewports (explicitly generated by the aria-label here, currently of the form {count} Filters in English)
• VFilterTab on smaller viewports (implicitly generated by the textual content of the tab, either Filters or {count} Filters depending on whether or not filters are applied)

Screenshots

Wider viewports:

Smaller viewports:

Description

Two things will need to be addressed here:

1. Unifying the accessibility information available for both viewport sizes. Having an explicit aria-label is useful rather than relying on the textual content, since the order of the number and the word describing Filters could be different in other languages.
2. Determining if {count} Filters is indeed the most accessible language here.

On the latter point, visually the button/tab conveys the notion that the filters are available under this button (if none are currently applied) or it shows the number of filters currently applied to the search along with the impression that the button is a controller for the filters pane. What is the best way to convey this meaning via text? Would something like Filters: {count} enabled or Filters: {count} applied be appropriate? Does {count} Filters work as-is?

[AetherUnbound]

I've added more information to the issue body, and asked for some input from the accessibility Make WordPress Chat channel. If we're able to garner some advice on the appropriate wording for this, then this issue can be worked on. Until then, I'm going to moved it to blocked.

[joedolson]

Having an explicit aria-label is useful rather than relying on the textual content, since the order of the number and the word describing Filters could be different in other languages.

I'm not sure that's actually relevant, since both the aria-label and the visible text should be translated. There are some specific accessibility problems caused by having a mismatch between the accessible name and the visible text, because voice control will respond to the accessible name, and if that doesn't match the visible name a user of voice control won't be able to trigger the button easily.

I think the most valuable change might just be word order; the action word should be first, with the supplemental values second. E.g. Filters (2). Adding additional terminology like (2 applied) could be useful, but isn't absolutely critical. In my opinion, it's better to have the visible text be the accessible name of the control than to add extra terms to try and add support for screen readers.

If we believe that Filters (2) is enough information for sighted people to figure out what it means, then we should accord screen reader users the same level of ability to interpret the interface. It's only necessary to add additional context if there is context that is clearly available to sighted users that is not available to screen reader users.

[AetherUnbound]

Thank you so much for your input @joedolson! That approach makes sense to me, @WordPress/openverse-frontend & @fcoveram - what are your thoughts?

[sarayourfriend]

Sounds good to me! It doesn't necessarily require a visual change, FWIW @AetherUnbound. You can set aria-hidden on the icon-or-filter-count component so that screen readers ignore it, then either add an sr-only text with the parenthised count in a more obvious position relative to the tab/button name, or set it directly on aria-label of the element.

The other PR I mentioned to you, #3941, did something along those lines to give clearer information for the screen reader to delineate the information that was otherwise available only visually... but did so without changing the visual presentation of the page.

The issue Madison mentioned about the word order was because of a difference in the desktop and mobile version of this bit of UI. The desktop button explicitly sets aria-label using a single translated string that includes the placeholder for the number of applied filters. The mobile version does not, and instead gets its accessible button name from the joined content of the button, rather than a single unified and translated string that incorporates the number when needed. We should fix that in the mobile version, for sure, so that they are translated together and identically 👍

[fcoveram]

Sounds good to me! It doesn't necessarily require a visual change, FWIW @AetherUnbound. You can set aria-hidden on the icon-or-filter-count component so that screen readers ignore it, then either add an sr-only text with the parenthised count in a more obvious position relative to the tab/button name, or set it directly on aria-label of the element.

+1 to this. There are hidden elements in WordPres.org changes to enhance accessibility, so this approach sounds great to me.