WordPress 7.1 changes list tables so the post title cell acts as the row header instead of the selection checkbox, adds structural indicators for subpages, and supplies useful context for untitled content. Those improvements can be lost when plugins replace title columns, inject nested links, reorder cells, or render custom list tables with older assumptions.
Use this for editorial teams and plugin developers working with Posts, Pages, Media, Users, Plugins, WooCommerce orders, custom post types, and custom wp-admin list tables.
Quick answer
Build rows with normal titles, long titles, untitled drafts, hierarchical pages, several custom columns, bulk-select checkboxes, row actions, and filtered views. Navigate by table, row, column, checkbox, heading, and link commands with a screen reader. Confirm each value is announced with the correct row context and that keyboard focus remains visible through sorting, filtering, pagination, and bulk actions.
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 |
|---|
| Standard post | Title, author, date, checkbox | Every cell includes the correct row context |
| Untitled draft | No visible post title | Useful excerpt or label identifies the row |
| Subpage | Parent and nested page | Hierarchy is understandable without visual indentation |
| Plugin table | Custom primary column and row actions | Row header and focus remain correct |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Preserve the current WordPress primary column and row-header semantics. | Record the generated table semantics for Core screens and every plugin-provided list table. | Every row has one useful header that identifies the content. |
| Give custom columns unique headers and ensure each data cell keeps its association. | Include titled, untitled, private, draft, hierarchical, translated, and long-title fixtures. | Checkboxes and repeated row actions announce the correct item context. |
| Repair untitled and hierarchical labels without duplicating visible content. | Test header associations for checkbox, title, author, taxonomy, date, status, and custom business columns. | Untitled and hierarchical items remain distinguishable. |
| Reinitialize semantics after AJAX filtering, sorting, and pagination. | Exercise row actions, sorting, filters, pagination, bulk selection, screen options, and AJAX refreshes. | Filtering, sorting, pagination, and AJAX updates preserve semantics and visible focus. |
What to check first
- Record the generated table semantics for Core screens and every plugin-provided list table.
- Include titled, untitled, private, draft, hierarchical, translated, and long-title fixtures.
- Test header associations for checkbox, title, author, taxonomy, date, status, and custom business columns.
- Exercise row actions, sorting, filters, pagination, bulk selection, screen options, and AJAX refreshes.
- Compare the failing custom table with a current Core Posts table before changing global CSS or screen reader text.
Field notes
- Test with enough rows to require pagination and bulk actions.
- Keep row-action labels specific because repeated Edit links need row context.
- Do not hide the visible title solely to improve screen reader output.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
screen,row_fixture,row_header,checkbox_context,custom_columns,row_actions,result
posts,normal,correct,correct,correct,correct,pass
pages,untitled,excerpt,correct,correct,correct,pass
orders,custom-primary,missing,ambiguous,correct,partial,fix
Why this usually happens
- Custom list-table code may mark the checkbox or a decorative cell as the primary context.
- Injected columns can break header relationships when their IDs or scopes are duplicated.
- AJAX refresh code may rebuild rows without the semantics present on the initial page.
Decision rule
Block release when a user cannot identify the current row, selection checkbox, custom-column value, or row action without guessing. Cosmetic differences are acceptable only when the semantic relationship remains correct.
Production verification checklist
- Every row has one useful header that identifies the content.
- Checkboxes and repeated row actions announce the correct item context.
- Untitled and hierarchical items remain distinguishable.
- Filtering, sorting, pagination, and AJAX updates preserve semantics and visible focus.
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.
- Preserve the current WordPress primary column and row-header semantics.
- Give custom columns unique headers and ensure each data cell keeps its association.
- Repair untitled and hierarchical labels without duplicating visible content.
- Reinitialize semantics after AJAX filtering, sorting, and pagination.
- Retest keyboard focus and screen reader navigation on every supported admin screen.
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, 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.
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, repair a WordPress admin list table.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references