WordPress 7.1 Accessibility Change May Break Some Plugins  🔗 **Source:** [WordPress 7.1 Accessibility Change May Break Some Plugins](https://www.searchenginejournal.com/wordpress-7-1-accessibility-change-may-break-some-plugins/584820/) > [!note]+ Document Notes > tags: [wordpress, accessibility, wp-7-1, list-tables, plugin-compatibility, screen-readers] > author: [Search Engine Journal] > source: [Search Engine Journal] > reference: [https://www.searchenginejournal.com/wordpress-7-1-accessibility-change-may-break-some-plugins/584820/] > date created: 2026-08-07 00:00 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: WordPress 7.1 Accessibility Change May Break Some Plugins (Search Engine Journal) > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [🔗 References](#-references) - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [📚 References](#-references-primary) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🧱 Refactor Appendix](#-refactor-appendix) ### 🔗 References - Article: https://www.searchenginejournal.com/wordpress-7-1-accessibility-change-may-break-some-plugins/584820/ (published 2026-08-06, ~920 words) - WordPress Trac #32892 — the eleven-year-old ticket being closed - WordPress Trac #31654 — referenced within #32892 for the underlying semantics argument - WordPress 7.1 release schedule: 2026-08-19 - WCAG 2.2 — `1.3.1 Info and Relationships`, the criterion this change serves ## 📝 Summary - **What happened.** WordPress 7.1 (due 2026-08-19) changes the HTML structure of admin post list tables: the checkbox column moves from `<th>` to `<td>`, the post-title column becomes the row header `<th scope="row">` with an `aria-label` carrying the post title, and collapsed responsive cells move to flex layout. - **Why it matters.** It fixes a real, specific screen-reader failure — rows were announced by the checkbox column's "Select All" label rather than the post title, and locked posts made it worse because the lock icon had no announceable label. The ticket had been open **eleven years**. - **Key stakeholders.** Plugin and theme developers who target admin list-table markup; screen-reader users; site owners running admin-customising plugins; the Accessibility and Plugins teams. - **Risks and tradeoffs.** A genuine breaking change for CSS/JS selectors targeting `<th>`/`<td>` in admin post lists. Public-facing markup is unaffected. The recommended mitigation — support both markup shapes — is correct but places the burden on every affected plugin. - **Bottom line.** A well-scoped, correct accessibility fix with an honest breaking-change disclosure. The article is competent, practically useful, and unusually clear about who is and is not affected. ## 📖 Main Content - **The four changes.** The checkbox column changes from a row header `<th>` to a regular `<td>`; the post-title column changes from `<td>` to the row header `<th scope="row">`; the post-title row header gains an `aria-label` containing the post title; collapsed cells in responsive view move to flex layout. - **The underlying defect.** Semantically, a table's row header should identify the object the row is about. WordPress used the checkbox cell — labelled "Select %s" — as the row header, so screen readers announced rows by the selection control rather than the content. - **The edge case that sharpens it.** Quoted from Trac #32892: > [!quote] when a post is locked and the lock icon appears, the icon has no label or text that can be announced so screen readers will read out the column header "Select All". A user navigating a list of locked posts hears "Select All" repeatedly — a phrase carrying no information about which post they are on. - **The semantics argument, verbatim from the ticket.** > [!quote] The row header should be the cell with the main object the table refers to: the Post title, the Plugin name, etc. Note the scope implied: this pattern exists across *all* admin list tables (posts, attachments, plugins, users), so the same correction logically extends beyond post lists. - **Eleven years open, closed nine days ago.** The article notes the timeline explicitly — an accessibility defect with a clear diagnosis and an agreed fix sat unresolved for over a decade. - **Who breaks.** Themes containing only public-facing markup are unaffected. At risk: plugins or admin customisations whose CSS or JavaScript targets specific `<th>`/`<td>` elements in admin post list tables — typically anything adding columns, controls, or information to post lists. - **Guidance for users.** Check the plugin's changelog after 7.1 ships (the article's suggested method — search plugin name plus "changelog" — is serviceable if crude); update confirmed-compatible plugins before upgrading; test unconfirmed ones on staging. - **The SEO plugin check.** The article reports reviewing publicly available code for Yoast SEO, Rank Math, and All in One SEO and finding no selectors that appear to depend on the changed structure — while explicitly hedging that this is > [!quote] not a guarantee. Doing the check at all is more diligence than most coverage of this kind offers. - **Guidance for developers, including the vibe-coding caveat.** Beyond the standard "audit your selectors," the article makes a genuinely current point: > [!quote] there are many people nowadays who are vibe coding their own plugins so it's important for non-developers who rely on AI to code their plugins to also audit any CSS or JavaScript selectors. This is a real and growing category — plugin authors who did not write, and may not be able to read, their own selectors. - **Support both shapes.** The before/after markup is reproduced, and the advice is to write CSS and JS that works against old and new structures simultaneously, since plugins must support multiple WordPress versions. ### 🗒️ Notes - Public-facing site output is not affected; this is admin-only. - The `aria-label` on the row header is what carries the post title to assistive tech. - The flex-layout change to collapsed responsive cells is mentioned but not explained; it is the least-documented part of the change here. - The article is written for an SEO-practitioner audience, which explains the SEO-plugin focus. ## 📚 References (primary) - WordPress Trac #32892 (primary — the ticket, its rationale, and the quoted edge case) - WordPress Trac #31654 (the semantics precedent cited inside #32892) - The official WordPress developer-note announcement containing the before/after markup - WCAG 2.2 SC 1.3.1 Info and Relationships — the standard this serves - Changelogs for Yoast SEO, Rank Math, All in One SEO ## 🗣️ Paraphrase - **The change.** Admin post list tables swap which cell is the row header — checkbox out, post title in — and add an `aria-label`. - **The reason.** Screen readers were announcing rows by the selection checkbox, not by the post, which is semantically wrong and practically useless. - **The worst case.** Locked posts produced "Select All" with no indication of which post was locked. - **The age.** Reported eleven years ago; closed nine days before publication. - **The blast radius.** Admin only. Plugins keyed to the old `<th>`/`<td>` structure may break; public-facing themes will not. - **The advice.** Users check changelogs and test on staging; developers audit selectors and support both markup shapes. ## 📰 Newsletter **An eleven-year-old accessibility bug is getting fixed, and it might break your admin plugin** WordPress 7.1 lands 19 August with a small structural change to admin post list tables that is worth two minutes of your attention. Right now, the row header in those tables is the *checkbox* column, labelled "Select All." So a screen-reader user tabbing through your posts list hears "Select All" over and over instead of hearing post titles. It gets worse with locked posts: the lock icon has no announceable label, so there is nothing else to fall back on. Trac #32892 has been open on this since 2015. The fix is straightforward semantics. The checkbox cell becomes a plain `<td>`, the post title cell becomes the row header `<th scope="row">`, and it picks up an `aria-label` with the post title in it. If your plugin adds a column or a control to the posts list and targets `th` or `td` in its CSS or JavaScript, check it. Public-facing themes are fine — this is admin-only. One note the article gets right and most coverage would miss: a lot of people are now shipping plugins they generated with AI and cannot necessarily read. If that's you, this is exactly the kind of change that will break something quietly. Search your code for selectors touching `th`/`td` in list tables, and write them to match both the old and new markup, because you'll need to support both for a while. **Links:** [the article](https://www.searchenginejournal.com/wordpress-7-1-accessibility-change-may-break-some-plugins/584820/) · Trac [#32892](https://core.trac.wordpress.org/ticket/32892) ## ✅ Action Items - **DevRel** - `#action/h1` This is a clean teaching case for "accessibility fixes are breaking changes too" — a category developers systematically under-plan for. - `#action/h2` Write the selector-audit guide the article gestures at: how to find `th`/`td` dependencies in a plugin and make them version-tolerant. - `#action/h3` The vibe-coded-plugin angle deserves its own piece — an audience that ships code it cannot read needs different upgrade guidance than developers do. - **OSPO** - `#action/h3` Note the governance data point: eleven years from report to fix on a diagnosed accessibility defect with an agreed solution. - **Community** - `#action/h2` Amplify ahead of 19 August to plugin authors specifically; the window between now and release is the whole mitigation opportunity. - **WordPress (by team)** - Accessibility: the win. Also worth stating publicly whether the same correction is planned for the *other* list tables (plugins, users, attachments), since #32892's reasoning covers all of them. - Plugins: expect compatibility reports after 19 August; the affected surface is admin-column plugins. - Themes: explicitly unaffected where markup is public-facing only — worth saying loudly to prevent unnecessary churn. - Core: the dual-markup support burden falls on every affected plugin; a documented helper or selector guidance would reduce it. - Documentation: publish the before/after markup and a "support both versions" pattern in the developer handbook, not just a dev note. - Support: prepare for "my admin columns look wrong after updating" tickets in the week following release. - Training: good, small, concrete example for a semantics-and-ARIA lesson. - Marketing: an eleven-year accessibility fix shipping is a genuinely good story. - Core Performance, Core AI, Core Program Team, Mobile, Playground, Photos, TV, Polyglots, Meta, CLI, Hosting, Tide, Openverse, Design: Not applicable to this source — a targeted admin-markup change offers these teams nothing specific. - **The WPOCC** - `#action/h3` Eleven years open is a usable data point in any argument about contributor capacity and accessibility prioritisation — it is the "public toilets" problem from the Crossword episode in concrete form. - **FAIR** - Not applicable to this source — no federation, distribution, or repository-independence content. ## 🧪 Hypotheses 1. Plugins adding admin post-list columns break at a measurable rate on 7.1. *Testable directly after 19 August via support forum volume and plugin changelogs.* 2. AI-generated plugins break at a higher rate than hand-written ones, because generated selectors are more likely to be brittle and less likely to be audited. *Testable, novel, and directly relevant to the article's own vibe-coding caveat.* 3. Screen-reader task completion on the posts list improves measurably after the change. *Testable with assistive-technology users; nobody will run it, but it is the claim that justifies the break.* 4. The same row-header defect persists in other admin list tables after 7.1. *Trivially checkable and implied by the ticket's own scope.* 5. Most affected plugins will ship dual-markup support rather than a hard version gate. *Observable from changelogs.* ## 📊 Methodology **Of the source:** competent trade journalism, not research. Its factual backbone is primary — direct quotation from Trac #32892 and reproduction of the official before/after markup — which is better sourcing than most WordPress news coverage. The one piece of original work is a **code review of three SEO plugins** for affected selectors, reported as finding none, with an explicit hedge that this is not a guarantee. Method, scope, and depth of that review are not described, so it should be read as a spot check rather than an audit. No data on how many plugins target the affected markup, and no testing of the change itself. **Of this analysis:** full article text read from Reader's `html_content` capture (~920 words). All claims trace to explicit statements in the article. Trac ticket content is as quoted by the article and was **not independently verified against Trac**. The WCAG 1.3.1 mapping and the observation that the ticket's reasoning extends to other list tables are my own additions, flagged as such. ## ❓ Questions - Does the same fix land for plugins, users, and attachments list tables, or only posts? The ticket's reasoning covers all of them. - Why eleven years? What was the actual blocker — agreement, capacity, or fear of exactly this breakage? - How many plugins in the directory target `th`/`td` in admin list tables? That is a mechanically answerable question and nobody appears to have asked it. - Was the change tested with actual screen-reader users, or only against the semantic standard? - What is the flex-layout change to collapsed responsive cells actually doing, and does it carry its own breakage risk? - Is there a core-provided way to target the row header stably across versions, or must every plugin write defensive selectors? ## 🔮 Future Research - Mechanical scan of the plugin directory for selectors depending on admin list-table structure — would quantify the blast radius before release rather than after. - Post-release study of breakage rates in AI-generated versus hand-written plugins. - Assistive-technology user testing of the before/after experience, which would convert a semantics argument into an outcomes argument. - Broader question: how many other long-open accessibility tickets are blocked primarily by breaking-change risk? ## 💡 Implications - **Practice.** Accessibility corrections are breaking changes, and should be planned, communicated, and versioned like any other. - **Policy.** An eleven-year-old defect with a known fix is a prioritisation outcome, not an accident. - **Security.** Not applicable to this source — no security dimension, though the selector-audit discipline is the same muscle. - **Education.** A compact, real example for teaching semantic tables, `scope="row"`, and `aria-label`. - **Funding.** Accessibility remediation is precisely the unglamorous, broadly-beneficial maintenance work that the Crossword and Sustain documents in this batch both identify as chronically under-resourced. ## 🧠 Learning Styles Assessment - **Visual.** Moderately served — before/after code blocks are the strongest element and carry most of the explanatory load. No screenshots of the admin table or of screen-reader output. - **Aural.** Not applicable to this source — text-only article with no audio component. - **Verbal.** Well served. Clear, plain prose with descriptive question-form subheadings ("What Is Changing?", "What Should Plugin Users Do?") that make it scannable. - **Kinesthetic.** Well served in the practical sense — concrete instructions to check changelogs, test on staging, and audit selectors. - **Logical.** Well served. Change → reason → who is affected → what to do. Clean and complete. - **Social.** Not served — single-voice reporting with no discussion or dissent, though it does quote the Trac ticket's community deliberation. - **Solitary.** Well served — short, self-contained, actionable alone. - **Naturalistic.** Not applicable to this source — no classification or natural-world content. - **Reading level.** Roughly grade 11–13. Prose is accessible, but it presumes comfort with HTML table semantics, `scope`, ARIA, CSS/JS selectors, and staging environments. The audience split is visible: "What Should Plugin Users Do?" is written for non-developers, while the markup discussion is not. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA — evaluating the article, and noting the pleasing recursion that an article about an accessibility fix should meet the same bar. 1. **Perceivable — text alternatives.** ⚠️ Not verifiable from the capture. The only image is a stock featured image, credited to Shutterstock; decorative, so low risk either way. 2. **Perceivable — time-based media.** ✅ Not applicable — no audio or video. 3. **Operable — keyboard.** ⚠️ Not verifiable from the captured text; standard publication template. 4. **Operable — enough time.** ✅ Static text, self-paced. 5. **Understandable — readable.** ✅ Good. Technical terms are used in context with enough scaffolding for a non-developer to follow the practical advice, even if the markup section is beyond them. 6. **Understandable — predictable.** ✅ Strong. Question-form headings create a predictable structure and let readers jump to the section relevant to their role. 7. **Robust — compatible.** ✅ Semantic headings and code blocks present in the captured markup. Code samples are in text rather than images, which matters — screenshot-only code would have been inaccessible to the very users this change serves. **Note rather than fix:** the article never describes what the *improved* experience sounds like to a screen-reader user. It explains the broken behaviour well ("Select All") but not the corrected one, which would have made the benefit concrete. ## 🌍 DEIB Assessment - **Cultural breadth.** Narrow but unproblematic given the subject. Entirely English-language, US-published, WordPress-ecosystem framing. The change itself has global impact since admin list tables are universal, and nothing in the piece assumes a specific locale beyond the SEO-industry framing. - **Inclusive language.** Good. Notably, it uses **"WordPress users with screen readers"** rather than deficit-framed alternatives, and treats the affected users as people with a legitimate blocked task rather than as an edge case to be accommodated. The one mild slip is describing the impact as affecting "a small number of users," which is true of the *breakage* but risks reading as a comment on the *beneficiaries*. - **Neurodiversity support.** Strong for its length. Question-form headings, short paragraphs, bulleted change list, explicit role-based sections ("users" vs "developers"), and before/after code side by side. A reader can extract exactly the part that applies to them without reading the whole piece — genuinely good information design. - **Representation.** Limited by format. No named author byline in the capture, no quoted community members beyond the Trac ticket text itself. The accessibility contributors who spent eleven years on this go uncredited, which is a real omission in a story that is fundamentally about their persistence. - **Psychological safety.** Not applicable in the interpersonal sense — no dialogue or conflict. Worth noting the tone toward the least-expert audience segment: the vibe-coding passage could easily have been contemptuous and instead is straightforwardly helpful, telling people who cannot read their own plugin code exactly what to search for. That is a small act of inclusion toward a group frequently mocked in developer media. ## ✅ Logical Validity **Strong reasoning** - **The problem statement is precise and mechanism-level.** It does not merely assert an accessibility issue; it explains that the row header is semantically wrong, what screen readers therefore announce, and why locked posts make it worse. Cause and effect are correctly identified. - **Scope is honestly bounded in both directions.** Public-facing themes unaffected; admin plugins targeting the changed markup at risk. It neither inflates the alarm nor buries the break. - **The dual-markup recommendation is correct and non-obvious.** Because plugins support multiple WordPress versions, "just update your selector" would be wrong advice; supporting both is right. - **The SEO-plugin spot check is hedged appropriately** — it reports what was found, states the method's limits, and still tells readers to verify. - **The vibe-coding caveat is a genuine insight**, identifying a class of maintainer who will be affected and cannot self-diagnose. **Fallacies** 1. **Hasty generalisation from a limited code review.** *Located:* the claim that Yoast, Rank Math, and All in One SEO are "unlikely to break" based on a review that "found no selectors that appear to rely on" the changed structure. *Why it's weak:* three plugins, unstated method, and public code review cannot see minified assets, dynamically constructed selectors, or admin JS loaded conditionally. *Mitigating:* explicitly hedged as "not a guarantee" and paired with advice to check anyway. Honest, but the headline reassurance will travel further than the caveat. 2. **Appeal to authority via search.** *Located:* > [!quote] just Google the name of the plugin plus the keyword "changelog". *Why it's weak:* search results are not authoritative for compatibility, and the wordpress.org plugin page has a canonical changelog. Recommending a search engine over the canonical source is worse advice than it appears. 3. **Unsupported prevalence claim.** *Located:* "not likely to impact most users" and "a small number of users." *Why it fails:* no data supports the estimate. Nobody has counted how many plugins target this markup — a mechanically answerable question the article does not attempt. *Fix:* say the blast radius is unmeasured. 4. **Omission of the counterfactual benefit.** *Located:* throughout. The breakage is quantified in detail; the improvement is described only as "improves accessibility." How many users benefit, and how much, is never estimated — which structurally frames the change as cost-with-vague-benefit. *Fix:* describe the corrected screen-reader experience concretely. 5. **Incomplete scope reporting.** *Located:* the Trac quote explicitly covers "all the List Tables in the admin... the Post, Attachment, Plugin, User," but the article discusses only post lists. Readers may conclude other list tables are unaffected when the article simply does not say. **Tone of voice.** Measured, practical, service-oriented. It reads as advisory rather than alarmist — the headline says "may break" and the body immediately narrows who. There is no editorialising about WordPress leadership, no framing of accessibility work as burden, and no contempt toward less-technical readers. The register shifts deliberately between the user section (plain, procedural) and the developer section (markup-level), which is appropriate for a mixed audience. Genuinely useful trade writing. ## 🛡️ DARVO Analysis **Not applicable to this source.** No accusation of wrongdoing is made against any person or organisation, so the pattern has nothing to attach to. - **Deny.** ⚪ Absent. The article does the opposite of denial regarding the breaking change — it leads with it in the headline and quantifies who is affected. - **Attack.** ⚪ Absent. No individual, team, or plugin vendor is criticised. Even the eleven-year delay is stated as fact without blame attached, and plugin developers are addressed as competent professionals ("should already know to audit their software"). - **Reverse victim and offender.** ⚪ Absent. There is no victim/offender construction. A weaker article might have framed accessibility requirements as imposing costs on developers — the "burden" framing common in this genre — and this one conspicuously does not. Do not tag this document with any `#darvo/*` value. ## 🎯 Conclusion **Bottom line.** A correct, narrowly-scoped accessibility fix, honestly reported. The substance: admin post list tables get the post title as row header instead of the checkbox, so screen readers stop announcing every row as "Select All" — a defect that was worst precisely where it mattered most, on locked posts. It ships 19 August and it will break plugins whose CSS or JS targets the old `<th>`/`<td>` arrangement. The article's practical advice is sound, its dual-markup recommendation is right, and its vibe-coded-plugin caveat identifies a genuinely new risk category. Its weaknesses are all of the same kind: the breakage is described precisely while the benefit stays abstract, and the "unlikely to break" reassurance about major SEO plugins rests on a spot check the article itself declines to guarantee. **Next steps.** 1. Before 19 August, grep any plugin you maintain for selectors touching `th`/`td` in list tables, and make them tolerate both shapes. 2. Check whether the same fix is landing for the plugins/users/attachments list tables — the ticket's reasoning covers them and the article does not say. 3. Cross-link to the Crossword/Josepha atoms: an eleven-year-old accessibility ticket is "public toilets" work in its most literal form. 4. Note as a data point for the AI-generated-plugin thread running through this batch — this is the first concrete upgrade event that will test whether vibe-coded plugins are more fragile. ## 🧱 Refactor Appendix ### Literature Split Pad #### L1 — The row header was the checkbox, so screen readers announced "Select All" `#atom/literature/h1` > [!quote] when a post is locked and the lock icon appears, the icon has no label or text that can be announced so screen readers will read out the column header "Select All" Claim: semantic misuse of `<th>` produced a concrete, daily failure for screen-reader users — worst on locked posts, where no fallback label existed. Source: Trac #32892 as quoted. #### L2 — Row headers should identify the row's subject `#atom/literature/h1` > [!quote] The row header should be the cell with the main object the table refers to: the Post title, the Plugin name, etc. Claim: the correct semantic anchor is the content, not the control. Note the ticket's scope covers *all* admin list tables, not only posts. #### L3 — Accessibility fixes are breaking changes `#atom/literature/h2` Claim: correcting `<th>`/`<td>` roles breaks plugin CSS and JS keyed to the old structure. Public-facing themes unaffected; admin customisations at risk. #### L4 — Support both markup shapes, not just the new one `#atom/literature/h2` Claim: because plugins span multiple WordPress versions, defensive selectors matching old and new markup are required — "update your selector" would be wrong advice. #### L5 — Eleven years from report to fix `#atom/literature/h3` Claim: a diagnosed accessibility defect with an agreed solution remained open for over a decade. A prioritisation outcome, not an accident. #### L6 — Vibe-coded plugins are a new fragility class `#atom/literature/h2` > [!quote] there are many people nowadays who are vibe coding their own plugins so it's important for non-developers who rely on AI to code their plugins to also audit any CSS or JavaScript selectors Claim: a growing population ships code it cannot read and cannot self-diagnose against upstream changes. ### Atomic Split Pad - **Z1 — Semantics carry meaning to non-visual users `#atom/zettel/z1`.** Markup roles are not decoration; the choice of which cell is a header determines what an assistive technology says out loud. Visual correctness and semantic correctness are independent properties. - **Z2 — Remediation has migration cost `#atom/zettel/z1`.** Fixing a long-standing defect breaks whatever grew around it. The longer the defect persists, the more depends on it, and the more the fix costs — which is itself an argument for fixing sooner, not later. Links to `[[public-toilets-problem]]`. - **Z3 — Version-tolerant selectors `#atom/zettel/z1`.** When downstream consumers span multiple upstream versions, correctness means matching every supported shape, not the newest one. Applies to CSS selectors, APIs, and data schemas alike. - **Z4 — Unreadable ownership `#atom/zettel/z1`.** Generated code creates maintainers who own artifacts they cannot inspect. Upgrade guidance written for developers does not reach them, and the failure surfaces silently. Links to `[[skills-as-source]]` — the inverse problem. ### Fleeting Queue - `#atom/fleeting/f1` Eleven years open. That's the Josepha "public toilets" argument with a ticket number attached — best concrete example I've seen for that piece. - `#atom/fleeting/f1` Does the fix extend to plugins/users/attachments list tables? The ticket says it should. Worth checking Trac directly rather than trusting the article's narrower framing. - `#atom/fleeting/f1` 7.1 on 19 August is the first real upgrade event that will test whether AI-generated plugins break at a higher rate. Genuinely novel, measurable question — watch the support forums. - `#atom/fleeting/f1` Nobody has counted how many directory plugins target `th`/`td` in list tables. That's a grep away and would have quantified the blast radius pre-release. - `#atom/fleeting/f1` The article describes the broken screen-reader experience vividly and never describes the fixed one. Common pattern in a11y coverage — cost gets concrete, benefit stays abstract. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/WordPress 7.1 Accessibility Change May Break Some Plugins.md|WordPress 7.1 Accessibility Change May Break Some Plugins by searchenginejournal.com]] ## Highlights - These changes will have no effect on themes that only contain public-facing markup. But there is a chance of breaking plugins or admin customizations that modify post list tables because of CSS and JavaScript that target specific <th> and <td> elements in WordPress admin post list tables. ([View Highlight](https://read.readwise.io/read/01kzec2e0r55t8r83m5nnc3r7n)) - Note: L3 — Accessibility fixes are breaking changes. Blast radius honestly bounded in both directions: public-facing themes unaffected, admin plugins targeting the old th/td arrangement at risk. Action before 19 Aug: grep any plugin you maintain for selectors touching th/td in list tables and make them tolerate BOTH shapes — "just update your selector" is wrong advice, since plugins span multiple WP versions. Unmeasured though: nobody has counted how many directory plugins target this markup, and that's a grep away. - Tags: atom/literature/h2, atom/zettel/z1, accessibility, plugin-compatibility - “One more good reason to address this issue is that, when a post is locked and the lock icon appears, the icon has no label or text that can be announced so screen readers will read out the column header “Select All”;” ([View Highlight](https://read.readwise.io/read/01kzec1ydwmta4hwnaqpeqj5ye)) - Note: L1 — The concrete failure, quoted from Trac #32892. Because the checkbox column was the row header, screen readers announced every row as "Select All" instead of the post title — and locked posts made it unrecoverable, since the lock icon carries no announceable label. Open for ELEVEN YEARS, closed nine days before this article. This is the Josepha "public toilets" argument with a ticket number attached: a diagnosed defect with an agreed fix, unresolved for a decade because the work was unglamorous. - Tags: accessibility, atom/literature/h1, screen-readers, wordpress - WordPress software developers should already know to audit their software for changes. But there are many people nowadays who are vibe coding their own plugins so it’s important for non-developers who rely on AI to code their plugins to also audit any CSS or JavaScript selectors that specifically target <th> or <td> elements in WordPress admin post list tables, because those selectors may stop working when the element type changes in WordPress 7.1. ([View Highlight](https://read.readwise.io/read/01kzec22ph322a5wpcpvvcs2g0)) - Note: L6 — A genuinely new fragility class: maintainers who ship code they cannot read and therefore cannot self-diagnose against upstream changes. Upgrade guidance written for developers does not reach them, and the failure surfaces silently. WP 7.1 on 19 August is the first concrete upgrade event that could TEST whether AI-generated plugins break at a higher rate than hand-written ones — measurable via support-forum volume and changelogs. Note the tone: helpful rather than contemptuous toward a group developer media usually mocks. - Tags: wordpress, atom/literature/h2, plugin-compatibility, atom/zettel/z1