155. Goodbye, Dashicons  🔗 **Source:** [155. Goodbye, Dashicons](https://www.wppodcast.org/podcast/goodbye-dashicons/) > [!note]+ Document Notes > --- > tags: [dashicons, svg-icons, screen-reader-accessibility, php-compatibility, wordpress-core-development] > author: wppodcast.org > source: WPpodcast > reference: https://www.wppodcast.org/podcast/goodbye-dashicons/ > date created: 2026-09-10 > --- > > [!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: 155. Goodbye, Dashicons > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ 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--155-goodbye-dashicons) > ### 🔗 References > - [Dashicons→SVG rationale and open questions — Main Content](#-main-content) > - [Full item-by-item digest — Notes](#️-notes) > - [WordPress-team action mapping — Action Items](#-action-items) > - [Icon-font accessibility mechanism — Accessibility Assessment](#-accessibility-assessment) > - [Literature atoms and permanent candidates — Refactor Appendix](#-refactor-appendix--155-goodbye-dashicons) > ## 📝 Summary > - **What happened.** This is WPpodcast's weekly WordPress news roundup for August 31–September 6, 2026, hosted by Alicia Ireland (they/them, pronouns not stated in the source). The anchor story: a core patch is underway to replace Dashicons — WordPress's built-in icon font, in the admin bar and sidebar menu — with SVG icons, using a rendering function that shipped in WordPress 7.1. The intro deck states the icons "appear set to disappear in WordPress 7.2." Six other items round out the episode: the WordPress 7.1.1 maintenance release (September 17), Gutenberg 23.9, an informal WordCamp US talk on WordPress's relationship with the PHP language and community, runnable code examples landing in the Code Reference, a bbPress 2.6.15 security release, and the podcast's Creative Commons licensing note. > - **Why it matters.** The Dashicons item is a genuine accessibility fix, not a redesign for its own sake: the source names three concrete failure modes of icon fonts — unpredictable screen reader announcement, breakage under forced-colors/high-contrast modes, and font-load failures rendering as boxes instead of failing invisibly like an SVG would. That's a real, well-documented class of web accessibility bug, and the fix (SVG) is the standard remedy. The episode also surfaces a genuine ecosystem tension (WordPress's PHP backward-compatibility commitment vs. the broader PHP community's release cadence) with a hard adoption number: PHP 7.4 still runs on roughly 18% of sites. > - **Key stakeholders.** WordPress core contributors shipping the icon patch and reviewing feedback on the open ticket; plugin and theme authors whose UI code references Dashicons classes; screen reader and forced-colors users of wp-admin; hosts and plugin developers navigating the PHP 7.4→9 compatibility window; bbPress site admins running affected versions. > - **Risks and tradeoffs.** The source states the SVG swap covers the admin bar and sidebar menu specifically — it does not state whether the broader `dashicons-*` icon font (used directly by countless third-party plugins and themes for their own admin UI) is being deprecated, frozen, or left alone. That's a real backward-compatibility gap this note flags but cannot resolve from the source text. Two concrete regressions are still open on the ticket itself: the new search icon faces the opposite direction from the Dashicon it replaces, and the Posts icon may switch from a pushpin to a pen — both are exactly the kind of small, visible UI change that breaks muscle memory and screenshots in existing documentation. > - **Bottom line.** The Dashicons→SVG patch is a well-reasoned, mechanism-driven accessibility fix with real remaining unknowns — plugin/theme scope, icon-direction regressions, and no confirmed release version beyond the "7.2" stated in the intro deck (the transcript body never repeats that version number). The rest of the episode is standard core/ecosystem reporting: one maintenance release, one Gutenberg minor, one unnamed-source PHP-relationship discussion, one documentation feature, and one security release with a CVE. > ## 📖 Main Content > The episode opens by stating plainly that the icons WordPress has used in its admin interface since version 3.8 are being phased out: "they'll be replaced with vector graphics" in WordPress 7.2, per the intro deck. The body of the episode explains this as one item among seven in the weekly digest, but it's clearly the one the episode is titled after. > **The 7.1.1 maintenance release.** WordPress 7.1.1 is scheduled for September 17, 2026. The source states the core team is giving this release more advance notice than usual because of "the volume and severity of reports received in forums, Trac, and the Gutenberg repository since 7.1's launch" — language that signals a rockier-than-typical release cycle, though the source doesn't quantify "volume and severity" or attribute the statement to a named person. As with any x.x.1 release, scope is limited to regressions introduced during the 7.1 cycle and features deliberately deferred to the end of that cycle — no new features. > **Gutenberg 23.9.** Framed as small editing conveniences: an insert-block button now lives on a block's own toolbar (so adding an image to a gallery, or a block inside a group, no longer forces a selection change or a scroll to find the global inserter); Global Styles gains a per-block indicator dot for custom style overrides, with a filter to see only touched blocks; the Group block gets independent horizontal/vertical spacing under flexible or grid layout; theme.json can now style form labels; Global Styles extends to blockquotes, input fields, and dropdowns; and users can add a custom duotone palette from the Global Styles panel rather than being limited to theme-supplied duotones. The source also notes unspecified "internal improvements for accessibility and performance," singling out faster block selection in long posts. > **Dashicons → SVG — the mechanism, not just the aesthetic.** The source is explicit that "the reason isn't just aesthetic," and names three specific, verifiable problems with icon fonts as a UI pattern: > 1. Screen readers announce icon-font glyphs unpredictably, because they occupy Unicode code points that carry no defined meaning — sometimes surfacing as a stray, meaningless character read aloud mid-sentence. > 2. Icon fonts break under Windows High Contrast Mode and other forced-color settings, because the operating system treats the glyph as text and remaps it through the system's constrained color palette. > 3. When the font file fails to load or loads slowly, the fallback is visible boxes or garbled symbols that read as a broken page; an SVG that fails to load simply doesn't render anything. > These are real, well-established accessibility failure modes for icon fonts as a category (see Accessibility Assessment below for the underlying mechanism and the WCAG mapping) — the source isn't overstating the problem class, even though it doesn't cite a specific bug report, screen reader test, or ticket number for any of the three claims. > The source also states the change is "very visible to the user," and that the team is "explicitly requesting more feedback than it's gotten so far on the ticket" — a signal that the open questions below aren't yet settled. Two are named directly: the new search icon ends up mirrored relative to the Dashicon it replaces, and the Posts icon may drop its pushpin glyph for a pen, with active disag The icons that have displayed WordPress since version 3.8 appear set to disappear in WordPress 7.2, where they’ll be replaced with vector graphics. [](https://www.wppodcast.org/apple/) [](https://www.wppodcast.org/spotify/) [](https://www.wppodcast.org/pocketcasts/) #### Program transcript Hello, I’m Alicia Ireland, and you’re listening to [WPpodcast](https://www.wppodcast.org/), bringing the weekly news from the WordPress Community. In this episode, you’ll find the **information from August 31 to September 6, 2026**. There’s now a schedule for the first maintenance release of the current version: [WordPress 7.1.1 arrives September 17](https://make.wordpress.org/core/2026/09/02/wordpress-7-1-1-release-schedule/). The team itself acknowledges that the volume and severity of reports received in forums, Trac, and the Gutenberg repository since 7.1’s launch justify preparing this maintenance release with more advance notice than usual. As is standard for these releases, 7.1.1 focuses exclusively on bug fixes: only tickets that are regressions introduced during the 7.1 cycle itself or features deliberately postponed to the end of that cycle get in — no new features. Gutenberg 23.9 is also available, focused mainly [on small day-to-day editing conveniences](https://make.wordpress.org/core/2026/09/02/whats-new-in-gutenberg-23-9-2-september/). You no longer have to hunt for the insert block button when it’s hidden: you can now add directly from the block’s own toolbar, so adding another image to a gallery or a new block inside a group no longer forces you to change selection or scroll to find it. Global Styles, for their part, gain a small indicator dot on each block that has a custom style override, with the option to filter and see at once only the blocks you’ve touched by hand, instead of having to review them one by one. Among the other updates, independent horizontal and vertical spacing between elements stands out for the Group block with flexible or grid layout, the ability to customize form label styling from theme.json, and Global Styles support for blockquotes, input fields, and dropdowns. You can also add your own duotone color palette from the Global Styles panel itself, instead of relying only on those the theme offers. The rest are internal improvements for accessibility and performance, including noticeably faster block selection in long posts. There’s a patch underway that replaces the Dashicons in the admin bar and sidebar menu with the new WordPress SVG icons, [leveraging the new function that arrived with 7.1](https://make.wordpress.org/core/2026/09/04/replacing-dashicons-in-the-admin-bar-and-menu/). The reason isn’t just aesthetic: icon fonts like Dashicons have several underlying problems. Screen readers announce them unpredictably, since they occupy Unicode code points with no defined meaning and sometimes read as a meaningless character in the middle of a sentence; they break with Windows high contrast mode and other forced color settings, because the system treats them as text; and when the font file fails to load or loads slowly, the result is boxes or strange symbols that look like a broken site, while an SVG simply doesn’t display if it fails. The change is very visible to the user, so the team is explicitly requesting more feedback than it’s gotten so far on the ticket. A couple of details remain open: the search icon ends up facing the opposite direction from the Dashicon it replaces, and the Posts icon might stop being a pushpin in favor of a pen, though there’s already debate over which fits better. Dashicons first appeared in WordPress 3.8 Parker, released December 12, 2013. They arrived alongside the admin redesign — the MP6 project — replacing the old icon sprites with a vector icon font, sharper at any resolution. The initial version included 167 icons; in WordPress 3.9 another 30 were added, reaching 197. A group of contributors held an informal talk at WordCamp US, under Chatham House rules, [about WordPress’s relationship with the PHP language and its community](https://make.wordpress.org/core/2026/09/03/wordcamp-us-2026-php-conversation/). The underlying diagnosis is well known: much of the PHP community doesn’t consider WordPress developers “real” PHP developers, partly because WordPress’s backward compatibility commitment is perceived as slowing PHP’s own evolution, and WordPress barely participates in discussions where new PHP features are decided. That same long compatibility window creates real friction in the plugin ecosystem, whose external dependencies no longer always support PHP versions as old as the ones WordPress still admits. The data that weighs most heavily is adoption: PHP 7.4 still runs on roughly 18% of websites, with little recent incentive to update beyond security, since those old versions no longer receive patches. There was talk of pushing from the hosting side with a coordinated upgrade, of making PHP 8.x noticeably faster so speed becomes the weighty argument, and underlying concern about PHP 9: if it brings major syntax changes, it could become impossible to maintain a single WordPress version compatible with both PHP 7.4 and PHP 9. The rest of the talk revolved around tightening ties with the PHP project: resuming the conversation about WebAssembly, which was once dismissed due to lack of interest but now makes more sense given WordPress’s existing use of WASM in Playground; bringing WordPress’s HTML API work to PHP, rather than keeping it internal only; and the idea — still at wish-list level — that plugins with unsafe dependencies could be loaded with restricted permissions, marking as untrusted any code depending on them. As concrete follow-up, there’s talk of reviewing whether the distribution of old WordPress versions itself has changed, and exploring sending automatic warnings to plugin developers when their code isn’t compatible with a given PHP version. The **Code Reference** debuts [truly executable code examples, powered by WordPress Playground](https://make.wordpress.org/core/2026/09/04/runnable-code-examples-are-now-live-in-the-code-reference/): WordPress 7.1 already includes the first two, with more planned for 7.2. On reference pages there’s now a “Run” button that executes the code snippet directly in the browser, without leaving the documentation or setting up anything locally. These interactive snippets are defined directly in each method’s DocBlock, within WordPress code itself, with syntax slightly different from a normal code example. The team promises to publish soon a handbook page with all the details for anyone wanting to document their own functions with this same format. It’s time to update forums with **bbPress** because version 2.6.15 fixes [five security flaws and several compatibility improvements](https://bbpress.org/blog/2026/09/bbpress-2-6-15-is-out/). The patches strengthen permissions when editing topics and replies, splitting or merging topics, updating user profiles, and viewing private or hidden forums; password verification for imports from other systems is also hardened and PHP warnings are fixed in some forum requests. One of the flaws has its own CVE. And finally, this podcast is distributed under a [Creative Commons license](https://creativecommons.org/licenses/by-nc-sa/4.0/) as a derivative version of the [podcast in Spanish](https://www.wppodcast.es/); you can find all the links for more information, and the podcast in other languages, at [WPpodcast .org](https://www.wppodcast.org/). Thanks for listening, and until the next episode!, 155. Goodbye, Dashicons, wppodcast.org, 01m25rr8f22j1hj8bghgbaa4f7.