WordPress 7.1 enables media library infinite scrolling by default and provides a per-user opt-out. A single global choice can help one group while making another group's work harder. Editors selecting featured images, product managers maintaining large catalogs, contributors uploading one file, and screen reader users reviewing a long result set do not perform the same task. The site policy should come from role-specific completion evidence, not preference alone.
Use this for editorial managers, accessibility owners, WooCommerce teams, agencies, universities, government sites, and any installation with a large or highly reused media library.
Quick answer
Create representative accounts for each real role, record the per-user setting, and repeat the same search, filter, upload, attachment-detail, selection, and insertion fixtures with infinite scrolling on and off. Measure completion, focus, spoken context, errors, and time. Teach the user-level preference first. Adopt a site-wide policy only when the evidence shows one mode is consistently safer for the affected roles.
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 |
|---|
| Editor | Large grid and featured image | Can orient and complete the task |
| Product manager | Variable product gallery | Correct images remain selectable |
| Contributor | Upload and insert one file | No unnecessary policy burden |
| Screen reader user | Search, inspect, and exit modal | Context and focus stay predictable |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create representative role accounts and stable media fixtures. | Map roles to real media tasks, library size, grid or list view, and assistive technology. | Every role can reach search, filters, result items, details, selection, and modal exit. |
| Test both preference states with the same tasks and data volume. | Run identical search, date-filter, upload, caption, featured-image, gallery, and product-image fixtures in both preference states. | Focus remains visible and returns to the invoking control. |
| Teach users where the profile setting lives and record their choice. | Record focus order, screen reader announcements, result position, completion time, errors, and user choice. | The user preference survives logout and a new session. |
| Apply a site policy only when the accessibility owner approves the evidence. | Check whether builders, forms, product editors, and custom media fields preserve the Core preference. | The approved policy, exceptions, training, and next review date are documented. |
What to check first
- Map roles to real media tasks, library size, grid or list view, and assistive technology.
- Run identical search, date-filter, upload, caption, featured-image, gallery, and product-image fixtures in both preference states.
- Record focus order, screen reader announcements, result position, completion time, errors, and user choice.
- Check whether builders, forms, product editors, and custom media fields preserve the Core preference.
- Name the policy owner, exception process, training note, release gate, and review date.
Field notes
- Interview affected users after the fixture instead of choosing solely from automated checks.
- Keep role policy separate from personal preference unless risk evidence requires a standard.
- Retest after WordPress or a media-management plugin changes the modal.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
role,preference,library_size,task,assistive_tech,focus_result,completion,policy
editor,on,18420,featured_image,NVDA,partial,fail,opt_out
product_manager,off,18420,variation_gallery,none,pass,pass,keep
contributor,on,18420,upload_insert,none,pass,pass,user_choice
Why this usually happens
- Infinite result sets change the effective page boundary and can make orientation unclear.
- A per-user setting means support screenshots may not match the editor's actual mode.
- Plugin media fields can replace or wrap Core behavior and ignore the chosen preference.
Decision rule
Keep user choice when both modes allow safe completion. Prefer paging for a role when infinite scrolling repeatedly causes lost focus, unclear position, unreachable controls, or failed completion in that role's real tasks.
Production verification checklist
- Every role can reach search, filters, result items, details, selection, and modal exit.
- Focus remains visible and returns to the invoking control.
- The user preference survives logout and a new session.
- The approved policy, exceptions, training, and next review date are documented.
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.
- Create representative role accounts and stable media fixtures.
- Test both preference states with the same tasks and data volume.
- Teach users where the profile setting lives and record their choice.
- Apply a site policy only when the accessibility owner approves the evidence.
- Retest plugin media fields and review the policy after relevant updates.
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.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, cache, browser behavior, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email provider, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep exact versions, stable IDs, UTC timestamps, sanitized requests or logs, 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.
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.
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 media accessibility safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Capture support evidence that another team can reproduce
Use the WordPress 7.1 media infinite-scroll support ticket template to preserve the user setting, role, filters, attachment IDs, request sequence, focus, memory, and sanitized reproduction steps.
Helpful references