Media filtering behavior should be the same in list and grid mode displays

[Fab1en]

When the Media Library is displayed using the grid layout, selecting an entry in the filtering drop-down menu applies it right away. For example, selecting "Unattached" hides all medias that are attached to a post.

On the other side, when the list layout is used, selecting an entry in the filtering drop-down menu does nothing until I click on the "Filter" button. That makes me think the functionality was broken for about 10 minutes before I realize my mistake.
Moreover, the "Filter" button is replacing the "Bulk Select" button when list view is activated, so I did not noticed its presence.

I think there is a need to make this more homogeneous : triggering the form submission upon dropdown menu selection in javascript would be easy.

This is linked to #29744

[wonderboymusic]

I like this - patched

[wonderboymusic]

In 31582:

When viewing media in List mode, auto-submit the form for attachment filters when the value of a <select> changes. This makes it behave similar to Grid mode and "feels" more performant, even though it is a full page load.

Fixes #30333.

[helen]

I've requested that the accessibility group look at this - typically, this kind of navigation is disruptive when navigating via keyboard. The full page refresh means that focus and place are lost.

[joedolson]

I think that this can be a workable scenario. The problem with behavior that's triggered on a change event related to a few factors: a) whether a page refresh is triggered (which effects all users, and can be disorienting and irritating) b) what kind of feedback is made available to the user and c) where focus moves.

In this case, I'd suggest that an effective solution would be to introduce a feedback indicator that provides the user with a notice of how the resultset changed - e.g., '124 results', or something to that effect, but kept the focus on the control in use, so the user can easily change again, if that wasn't what they wanted to do.

So we'd need an ARIA live region that read out the changes in the result set and to set the focus on the control that was activated. #31368 would be pertinent for this.

I think that this would give screen reader users a comparable experience with this change action.

[afercia]

I think there is a need to make this more homogeneous :

I agree, but should be the opposite :) Every kind of "automatically" triggered action is always very problematic for keyboard users and screen reader users and, generally, should be avoided.

We could try and test the proposed solution, it tries to address the change of context issue. Whatever the final solution, I see here the need to give feedback to screen reader users about what's happening in the page and the results set change.

By the way I'd like to point out that for keyboard users the only way to explore the content of a select is using the arrow keys. When they get the options available, they move out of the select with their tab key and... boom: the media grid will update its content even if that wasn't the user's real intention.

Worth nothing also that browsers fire the change event in different ways, e.g.:

• Firefox gets the specs right and fires the event only if the value was changed and only after the select loses focus (tabbing away from the select)
• Chrome instead fires the event immediately after the select value gets changed, when it's still focused (and that's really, really, bad). The only way to avoid this is to actually "open" the select (Alt+Down-arrow).

Do you really want Chrome users trigger a media library update each time they press the down-arrow key?

This Chrome bug would be a good enough reason for me to just stick with standards and use a nice, reassuring, button to trigger the update. Just use controls for what they're supposed to be used.

There's a whole literature on this subject. Years and years of debates and discussions about web standards and accessibility, and this issue rises up again :)

(Ensure) "changes of context are initiated only by user request or a mechanism is available to turn off such changes." Reference: ​http://www.w3.org/TR/WCAG20/#consistent-behavior

does nothing until I click on the "Filter" button. That makes me think the functionality was broken

I agree "Filter" doesn't mean so much for the average users. Maybe "update" better reflects what's really happening on the page?

Thanks very much Helen for bringing this to the accessibility team attention.

[helen]

What should we do here? I'm inclined to revert this for now, this is a degraded experience due to the full page refresh, which in itself means that grid and list experiences cannot be the same right now anyway.

[adamsilverstein]

Replying to helen:

What should we do here? I'm inclined to revert this for now, this is a degraded experience due to the full page refresh, which in itself means that grid and list experiences cannot be the same right now anyway.

I agree the auto-refresh on selection is confusing/degraded, and further changes the interface from other list views (posts, etc).

One possible enhancement would be to disable the Filter button until the dropdown is changes. This would give (sighted) users feedback indicating the button was ready to be clicked to apply the filtering action (I like 'Update' as well, but again this would be different than other list views). Not sure best way to make the action clearer for a11y, does the 'filter' button provide the context required to make its purpose clear?

[afercia]

I would keep it simple, the updates should happen only by user request and just use a proper label for the button.
Worth noting that when there are multiple selects, automatically triggering the update on change won't allow users to set multiple criteria for the update. Say I want to get only "audio" attachments and only from "December 2014": I'm forced to do that in two steps... and the first update usually happens exactly while I'm setting my choice on the second select :)

[wonderboymusic]

I'm inclined to revert this for now

I am not married to this - *I* liked it better, but if it is not jiving with others or there are a11y concerns, do as you must.

[helen]

In 31692:

Media library: Revert [31582], as it introduces navigation difficulties for many users.

see #30333.

[helen]

Punting / suggest close - this needs far more consideration than seems worth it.