A new controversy has surfaced regarding accessible themes, with the WordPress community taking a very clear stance.

www.wppodcast.org\/wp-json\/podlove-web-player\/shortcode\/publisher\/8186","data":{"version":5,"show":{"title":"WordPress Podcast (English)","subtitle":"WordPress Community Information","summary":"Information, news, and interviews about the WordPress Community.","poster":"https:\/\/www.wppodcast.org\/podlove\/image\/68747470733a2f2f7777772e7770706f64636173742e6e65742f77702d636f6e74656e742f75706c6f6164732f73697465732f332f323032302f30382f7770706f64636173742d7371756172652e706e67\/500\/0\/0\/wordpress-podcast-english\/b82f2aa9ac1de4bff143d83f8545c46f","link":"https:\/\/www.wppodcast.org\/podcast"},"title":"Accessible Themes-For What?","subtitle":"","summary":"","publicationDate":"2026-08-18T00:00:00+00:00","duration":"00:00:00.000","poster":"https:\/\/www.wppodcast.org\/wp-content\/cache\/podlove\/fb\/d06fd2860a0c83389790378c4df5a2\/accessible-themes-for-what_500x.png","link":"https:\/\/www.wppodcast.org\/podcast\/accessible-themes-for-what\/","chapters":[],"audio":[],"files":[{"url":"https:\/\/www.wppodcast.org\/podlove\/file\/375\/s\/webplayer\/wordpress-podcast-en-e152.mp3","size":"0","title":"WordPress Podcast","mimeType":"audio\/mpeg"}],"contributors":[{"id":"5","name":"Alicia Ireland","avatar":"https:\/\/www.wppodcast.org\/podlove\/image\/68747470733a2f2f7777772e7770706f64636173742e6f72672f77702d636f6e74656e742f706c7567696e732f706f646c6f76652d706f6463617374696e672d706c7567696e2d666f722d776f726470726573732f696d616765732f636f6e7472696275746f722d64656661756c742d6176617461722e706e67\/150\/150\/0\/alicia-ireland\/42077858656eea35e0e704dd75b5206d","role":{"id":"1","slug":"host","title":"Host"},"group":null,"comment":null}]}}, {"url":"https:\/\/www.wppodcast.org\/wp-json\/podlove-web-player\/shortcode\/config\/default\/theme\/wppodcast-blocks","data":{"activeTab":"chapters","subscribe-button":null,"share":{"channels":[],"outlet":null,"sharePlaytime":false},"related-episodes":{"source":"podcast","value":null},"version":5,"playlist":"https:\/\/www.wppodcast.org\/wp-json\/podlove-web-player\/shortcode\/podcast","theme":{"tokens":{"brand":"#15803D","brandDark":"#15803D","brandDarkest":"#15803D","brandLightest":"#fff","shadeDark":"#000","shadeBase":"#000","contrast":"#000","alt":"#fff"},"fonts":{"ci":{"name":"Outfit","family":["sans-serif"],"src":[],"weight":800},"regular":{"name":"Outfit","family":["sans-serif"],"src":[],"weight":300},"bold":{"name":"Outfit","family":["sans-serif"],"src":[],"weight":700}}},"base":"https:\/\/www.wppodcast.org\/wp-content\/plugins\/podlove-web-player\/web-player\/"}}]); podlovePlayer(player, "https://www.wppodcast.org/wp-json/podlove-web-player/shortcode/publisher/8186", "https://www.wppodcast.org/wp-json/podlove-web-player/shortcode/config/default/theme/wppodcast-blocks").then(function() { player && player.classList.remove("podlove-web-player-loading"); }); });

Remember that you can listen this program from:

Program transcript

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from August 10 to 16, 2026.

The Accessibility team spent two years updating, for the first time in fourteen years, the criteria for the accessibility-ready label on WordPress repository themes, moving from WCAG 2.0 to WCAG 2.1 Level AA and reviewing over a hundred themes in the repository. The work was scheduled to be finalized before September 30 until Matt Mullenweg intervened directly to declare the initiative “permanently postponed” and added that any committer can override suggestions from the Accessibility team. The response from Joe Dolson, the team lead, was immediate: the program is voluntary and will continue until the scheduled date. Amber Hinds, who had led the rewrite, asked Mullenweg to clarify whether the intent is for any theme to use the label without review — something that technically already happens, precisely because of the problem the team has spent years trying to solve. The question remains unanswered.

Mullenweg’s ambiguity isn’t just an internal matter. EU Directive 2016/2102 requires public sector websites to meet WCAG 2.1 Level AA, and WordPress powers a huge proportion of those sites in Europe. If the accessibility-ready label stops having verification, whoever installs a theme marked as such on a public website could be breaking their country’s law. Ryan Boren, a heavyweight former committer, called it a way to end a discussion without arguing. Eric Eggert, an accessibility expert with experience in transposing EU directives, directly questioned the leadership style and treatment of volunteer contributors. Elena Brescacin, a blind user and regular WordCamp speaker, reminded everyone that accessibility isn’t just for people with permanent disabilities: anyone can need keyboard access, high contrast, or voice navigation at any point in their life.

The result is an unusual impasse: Dolson says the team continues, Mullenweg says it’s over, and what happens on October 1 with themes that haven’t requested review remains unresolved.

In parallel, Anne McCarthy, release lead for 7.1, proposed creating a canonical “Accessibility Labs” plugin, following the Performance Labs model, as a space to test accessibility features before integrating them into core. Dolson has expressed support, with one condition: that there be a real path to core. Without that guarantee, the plugin could become a repository of features that never get integrated — precisely what’s happened with other accessibility initiatives over the years.

The first version of the WordPress Contributor Toolkit is here, the desktop app that started in April as the “Core Dev Environment Toolkit” and solves the biggest barrier to taking the first step in core development: setting up a complete wordpress-develop environment without having to install Git, Node, or Docker by hand. Available for Windows, macOS with Apple Silicon, and Linux, this version is a leap from the previous one: it doesn’t just leave the environment ready, but accompanies you through the entire contribution journey, from linking a Trac ticket to submitting your final work.

Another practical update is that the same site can now host work on multiple tickets at once, each in its own branch, without having to repeat the full install each time, and there’s a button to update to the latest development version without losing in-progress work. This version arrives just in time for the Contributor Day at WordCamp US, explicitly designed so both first-time contributors and those facilitating those sessions can focus on the ticket itself rather than wrestling with environment configuration.

Third round of security patches in just over a month: WordPress 7.0.4 fixes a remote code execution vulnerability for authenticated users with Author role or higher, through malicious file uploads on sites using Imagick and Ghostscript to process images. The flaw was reported, again, by the pwn.ai team, and has CVE-2026-65640. As has become routine, patches are being backported to the 4.7 branch, and WordPress 7.1 RC3, released the same day, already incorporates them.

Speaking of that RC3: the 7.1 beta continues on schedule, with over 90 fixes since RC1 — 37 in the editor and 57 in core — and coincides with an important cycle milestone: a complete string freeze, so from now on Polyglots can translate the final version without fear of text changes. The release date remains August 19.

Looking ahead, official planning for WordPress 7.2 has kicked off, with a proposed release date between December 8-10, coinciding with the State of the Word. The Core team is seeking volunteers for the Release Squad: Release Lead, coordination, Tech Leads, Triage Lead, and Test Lead, with a deadline to apply by August 28.

The Training team has announced that hands-on activity kits are now available on Learn WordPress: complete, ready-to-use packages for anyone wanting to run a WordPress training session without preparing materials from scratch. Each kit includes a facilitator’s guide and slides, all designed to work on WordPress Playground without needing to install anything or create accounts, with a duration of 60 to 90 minutes and a tangible result by the end of the session.

Eleven kits are available, with highly varied topics: from first steps in contributing to the project or creating content with blocks, to more technical sessions like debugging for developers with tools like Query Monitor and Xdebug, or ecommerce with WooCommerce. There are also two kits focused on AI — one for managing a local site with Claude Desktop via natural language through the MCP adapter, and another for using the WordPress AI plugin directly from the desktop — plus accessibility, SEO, security, and Playground kits.

WordPress Credits, the year-old program connecting students worldwide with real WordPress contributions, has debuted a public dashboard with data updated weekly: enrolled students, participating institutions, contributions flowing into the project, built sites, and testimonials from those experiencing it firsthand.

In parallel, a proposal has been launched to address an obvious gap in the program: right now, when a student graduates, there’s no defined next step, and all the momentum built up gets cut off just when that person is most equipped to keep contributing. The proposal suggests turning WordPress Credits into the first rung of a longer journey, with a clear path toward official WordPress Developer certification and WordPress Jobs, plus concrete contribution projects specifically designed for graduates who want to return, in collaboration with the Make teams themselves.

The ecosystem-level piece most worth noting is a model already being explored with companies: they finance certification exam seats for graduates, unlockable when the student completes a verifiable contribution after graduating, in exchange for preferential access to that talent. The plan executes in three phases: basic infrastructure first, a pilot focused on the development track next, and expansion to other tracks later, with a 25% retention target for that pilot.

The official WordPress browser extension is now available for Chrome and Chromium-based browsers through the Chrome Web Store, and for Safari on macOS from the Mac App Store. It’s an open source project that solves a well-known problem: the WordPress admin bar, always visible at the top of the screen when you’re logged in, gets in the way on sites with fixed headers or scroll effects, and disabling it from your profile also loses its quick access shortcuts. The extension hides that bar but keeps the most-used shortcuts one click away in the browser bar icon itself, with the full bar back in just two clicks if you need it.

The extension’s icon alerts while browsing whether the site runs WordPress and whether you’re logged in, without being intrusive. On a site you administer, it takes you directly to the dashboard or to the editor of that specific page, post, taxonomy, or template you’re viewing — including block theme templates, which open directly in the Site Editor. It locally saves the list of sites you’re logged into, so they’re available even when browsing a completely different website.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!