Reconsider the usage of infinite scrolling across the admin

[afercia]

As accessibility team, we've often discussed and we're aware of some a11y issues in the WordPress admin but haven't formalized them in a Trac ticket yet. That's because they're general, broad, issues and they probably can't be solved soon, as they have a big impact on the way some relevant parts of the user interface are built. They would require some extensive discussion and research. Nevertheless, if we're not going to at least open a discussion, the solution is not going to happen 🙂 . During the last accessibility weekly meeting we've decided to open a series of tickets and use a special keyword to group them, something like a11y-task. This is the first ticket of the series.

Infinite scrolling (sometimes known as "endless scrolling") can be a serious accessibility barrier. It's used in the admin in a few places, for example:

• Media Grid
• Add Themes screens
• Customizer > Add menu items
• Editor > Insert/Edit link > Search
• any other places?

For a comprehensive view of all the potential issues, I'd refer to the list of resources below. I'd recommend everyone to have a look at those posts.

I'd say the issues can be grouped in three different categories: accessibility, usability, and performance. Just to mention some of the most relevant ones:

• a11y: it's impossible or very hard for keyboard users to reach content placed after an infinite scrolling region: think for example at the Media Grid, where tabbing through attachments loads more and more attachments (potentially hundreds or thousands of them) forcing users to keep tabbing indefinitely
• a11y: no audible feedback or instructions about how infinite scrolling works, the current and total number of items, or when new items get loaded
• usability: infinite scrolling often breaks the browser's history
• usability: there's no JS fallback
• performance: memory footprint can be huge, especially when loading hundreds of big images, see the Theme install screens

Resources mostly focused on accessibility:

​http://adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html
​http://simplyaccessible.com/article/infinite-scrolling/
​http://www.webaxe.org/infinite-scrolling-and-accessibility/
​http://www.ssbbartgroup.com/blog/infinite-scrolling-impact-on-assistive-technologies-series-1/

Resources mostly focused on usability:

​https://webmasters.googleblog.com/2014/02/infinite-scroll-search-friendly.html
​https://www.nngroup.com/articles/infinite-scrolling/
​https://www.sitepoint.com/ux-infinite-scroll-good-bad-maybe/
​http://www.webdesignerdepot.com/2015/11/how-infinite-scrolling-breaks-ux/
​https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/
​https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/

Resources focused on memory footprint:

​http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5
​https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/
​http://dannysu.com/2012/07/07/infinite-scroll-memory-optimization/

Maybe for the future: the ARIA role feed
​https://www.w3.org/TR/wai-aria-1.1/#feed
(at the time of writing, ARIA 1.1 is still a Candidate Recommendation, and as far as I know, no assistive technologies support the role feed)
See also: ​http://www.ssbbartgroup.com/blog/differences-aria-1-0-1-1-additions-role/

See #19815, #28927, #28998.

[afercia]

About performance, I'm not familiar with profiling tools so anyone with better skills than me is greatly welcome to help measuring memory footprint issues. Checking the data reported by the Activity Monitor on my operating system I've noticed the browser's memory usage can easily go way higher than 1.5 GB after scrolling for a while in the Theme Installer screen. This is on a modern, powerful macbook pro. I can't imagine what happens on less powerful hardware or mobile devices. Not a surprise that, on mobile devices, sometimes browsers simply crash, as reported in #28927.

Worth reminding the Theme installer screen loads hundreds of big images, often 1200 by 900 pixels images. Also, unfortunately some themes use a non-optimized screenshot.png image which in some cases weights more than 2 MB. The theme installer screen then displays these images in an area of about 380 pixels, depending on the display's size, so I'd say loading such big images is highly inefficient. Ideally, the theme submission process should check for non-optimized images, or require an additional, smaller, image with a file size limit. Maybe consider alternative image sources and srcset and sizes, by the way these should be generated on the .org side.

Not to mention mobile bandwidth consumption.

[joedolson]

This is something that is very important, and needs to be done. We're marking it as future release, and will work on these issues as time allows.

[afercia]

Related: #28927.

[afercia]

See @melchoyce comment on https://core.trac.wordpress.org/ticket/28927#comment:10

FWIW, I think we should consider mimicking Google here — load a bunch of images, and then after a certain point add a "load more" button to the end, both on desktop and mobile.

[afercia]

#50143 reported one more case where users experience is not that great with the Media Library infinite scrolling.

[audrasjb]

Changing this umbrella ticket to a task, as we only keep it open to track other tasks/tickets.

[afercia]

Moving to 5.6 as this is a task that will span across multiple release cycles.

[afercia]

See related #50105. This ticket was discussed during today's accessibility bug-scrub: given the Beta 1 period is approaching fast and considering #50105 would need greater visibility and a good amount of time for in depth testing, the teams agreed to punt to future release. Since this is a task, it will be likely re-added to the next release milestone.

[joedolson]

In 50829:

Media: Remove infinite scroll from media library and modal.

Replace infinitely autoloading behavior on scroll with a user-controlled load more button. Fix a long standing accessibility issue in the media library. Infinite scroll poses a wide range of problems for accessibility, usability, and performance.

This change modifies the library to load 40 items in the initial view, with a load more button to load the next 40 items and a button to move focus from the load more region to the first of the most recently added items.

The text for communicating the jump target was broadly discussed, agreeing that the text incorporated here would most concisely and clearly convey the purpose of the button, and any further detail is learnable from use.

Props afercia, adamsilverstein, joedolson, audrasjb, francina
Fixes #50105. See #40330.

[SergeyBiryukov]

In 50831:

Docs: Correct @since tags for new properties and functions related to infinite scrolling in Media Library.

Follow-up to [50829].

See #50105, #40330, #52628.