Make WordPress Core

Opened 3 years ago

Last modified 10 months ago

#40330 new defect (bug)

Reconsider the usage of infinite scrolling across the admin

Reported by: afercia Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: a11y-task
Focuses: ui, accessibility, javascript Cc:
PR Number:


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:


Resources mostly focused on usability:


Resources focused on memory footprint:


Maybe for the future: the ARIA role 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.

Change History (8)

#1 @afercia
3 years ago

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.

Version 0, edited 3 years ago by afercia (next)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

3 years ago

#3 @joedolson
3 years ago

  • Milestone changed from Awaiting Review to Future Release

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.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.

3 years ago

#5 @afercia
2 years ago

Related: #28927.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

21 months ago

#7 @afercia
21 months ago

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.

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.

10 months ago

Note: See TracTickets for help on using tickets.