WordPress 7.1 enables media library infinite scrolling by default while providing a per-user opt-out. The WordPress accessibility team identifies infinite scrolling as an inaccessible pattern because the changing result set can make orientation, keyboard travel, screen reader review, and access to controls unpredictable. Site owners need to test both preference states instead of assuming the new default works for every editor.
Use this for editorial teams, universities, government sites, membership sites, agencies, and any WordPress installation where keyboard or screen reader users work with a large media library.
Quick answer
Create representative editor accounts, leave infinite scrolling enabled for one and disable it in the profile for another, then repeat the same search, date filter, grid navigation, attachment selection, upload, caption, and insertion tasks. Record focus order, announcements, visible labels, load behavior, and the ability to reach the end of results. Use the user preference or an approved filter only after the affected users confirm the workable mode.
What to check first
- Record WordPress build, browser, assistive technology, user role, media item count, grid or list view, and profile preference.
- Run search, date filtering, keyboard traversal, attachment detail, selection, upload, and insertion with infinite scrolling enabled.
- Repeat the exact fixture after the same user disables infinite scrolling in the profile.
- Check focus visibility, screen reader announcements, result position, end-of-list access, and escape behavior in media modals.
- Document whether a site-wide development filter or WP Accessibility plugin policy is needed for the editorial team.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Default profile | Large grid with infinite scrolling enabled | User can orient, filter, select, and exit |
| Opt-out profile | Same account fixture with paging behavior | All tasks remain reachable and predictable |
| Media modal | Featured image and gallery workflows | Focus stays visible and returns to invoker |
| Large library | Search then clear filter | Results and position are announced correctly |
Decision rule
Keep the default only when affected users can complete the same media tasks without losing orientation, focus, controls, or result context. Prefer the opt-out or approved filter when paging gives a materially more usable workflow.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Test both preference states with real editorial tasks and representative media volume.
- Teach users where the profile opt-out lives and record their chosen mode.
- Apply a site policy only when the accessibility owner approves the evidence.
- Retest plugin-provided media fields, featured images, galleries, and product media.
- Review the choice after Core or the WP Accessibility plugin changes the behavior.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Test both preference states with real editorial tasks and representative media volume. | Record WordPress build, browser, assistive technology, user role, media item count, grid or list view, and profile preference. | Every tested user can reach search, filters, result items, attachment controls, and modal exit. |
| Teach users where the profile opt-out lives and record their chosen mode. | Run search, date filtering, keyboard traversal, attachment detail, selection, upload, and insertion with infinite scrolling enabled. | Focus remains visible and returns to the invoking control. |
| Apply a site policy only when the accessibility owner approves the evidence. | Repeat the exact fixture after the same user disables infinite scrolling in the profile. | The chosen preference survives logout and a new session for that user. |
| Retest plugin-provided media fields, featured images, galleries, and product media. | Check focus visibility, screen reader announcements, result position, end-of-list access, and escape behavior in media modals. | Featured image, gallery, product, and form media workflows still work. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
// Site policy example after user testing
add_filter( 'media_library_infinite_scrolling', '__return_false' );
# Record user, preference, browser, assistive technology, task, result, and focus return.
Production verification checklist
- Every tested user can reach search, filters, result items, attachment controls, and modal exit.
- Focus remains visible and returns to the invoking control.
- The chosen preference survives logout and a new session for that user.
- Featured image, gallery, product, and form media workflows still work.
Why this usually happens
- An endlessly changing result set can move the effective page boundary and make the total collection unclear.
- A per-user preference means two editors on the same site can experience different navigation behavior.
- Plugins that replace media queries or modals may not preserve Core focus and announcement fixes.
Field notes
- Interview the affected editor instead of choosing a mode solely from an automated audit.
- Do not force a global policy until media workflows used by marketing, products, galleries, and forms have been tested.
- Keep the WordPress 7.1 known-regression note attached to the release decision.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, browser behavior, cache, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email route, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test WordPress 7.1 accessibility safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Turn the media preference into a role policy
After testing the user-level setting, use the WordPress 7.1 media infinite-scroll role policy audit to compare editor, catalog, contributor, and assistive-technology tasks before adopting site-wide guidance.
Helpful references