155. Goodbye, Dashicons - CourtneyR.dev's 2nd Brain

155. Goodbye, Dashicons ![rw-book-cover](https://www.wppodcast.org/wp-content/uploads/sites/3/2024/05/background.png) 🔗 **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 disagreement over which reads better. Historical context given for scale: Dashicons debuted in WordPress 3.8 "Parker" (December 12, 2013) as part of the MP6 admin redesign, replacing sprite-sheet icons with a vector icon font — 167 icons at launch, 197 after WordPress 3.9 added 30 more. **WordCamp US: WordPress and the PHP community.** An unnamed group of contributors held an informal talk under Chatham House Rule — meaning, by the rule's own definition, that what was said can be reported but not attributed to any individual speaker. The diagnosis reported: much of the PHP community reportedly doesn't consider WordPress developers "real" PHP developers, attributed partly to WordPress's long backward-compatibility window (perceived as a drag on PHP's own evolution) and to WordPress's limited participation in PHP's own feature-decision process. That compatibility window creates a concrete downstream problem: plugin dependencies increasingly don't support PHP versions as old as the ones WordPress still admits. The hard number given: PHP 7.4 still runs on roughly 18% of websites, with little incentive to upgrade beyond security, since 7.4 no longer receives patches. Ideas discussed, none committed: a hosting-side coordinated upgrade push, making PHP 8.x fast enough that speed itself becomes the upgrade argument, worry that a syntax-breaking PHP 9 could make a single WordPress core codebase compatible with both PHP 7.4 and PHP 9 impossible, resuming a WebAssembly conversation (now more plausible given WordPress's existing WASM use in Playground), upstreaming WordPress's HTML API work into PHP itself, and a wish-list idea to load plugins with unsafe dependencies under restricted, "untrusted" permissions. Concrete stated follow-up: checking whether the distribution of old WordPress versions in the wild has shifted, and exploring automatic compatibility warnings to plugin developers. **Code Reference gets runnable examples.** WordPress 7.1 already ships the first two Playground-powered "Run" buttons on Code Reference pages, executing a documented function's example directly in the browser with no local setup; more are planned for 7.2. These snippets are authored directly inside each function's DocBlock in WordPress core, in a syntax the source says differs slightly from a normal code example; a handbook page detailing the format is promised but not yet published per the source. **bbPress 2.6.15.** A security-and-compatibility release fixing five security flaws (one with its own CVE) and hardening permission checks across editing/splitting/merging topics and replies, updating profiles, viewing private/hidden forums, verifying imported passwords, and clearing some PHP warnings in forum requests. The source names the flaw count and the CVE's existence but not the CVE identifier itself, nor the specific vulnerability classes. **Licensing note.** The episode closes stating it's distributed under a Creative Commons BY-NC-SA 4.0 license as a derivative of the Spanish-language podcast — which also explains this episode's unusually long, clause-dense sentences (average 30 words/sentence measured across the transcript; see Learning Styles Assessment): the text reads like edited translation rather than native English broadcast script. ## 🗒️ Notes **Dashicons → SVG (the episode's title story)** - Scope as stated: admin bar and sidebar menu icons only, via a rendering function introduced in WordPress 7.1. - Version target: the intro deck states WordPress 7.2; the transcript body never repeats a version number for the patch itself, only for the underlying 7.1 function it depends on. Treat "7.2" as stated once, not independently confirmed within the body. - Three named problems with icon fonts: (1) unpredictable screen reader announcement from undefined Unicode code points, (2) breakage under Windows High Contrast/forced-colors, (3) visible-boxes failure mode vs. SVG's silent failure. - Team is explicitly asking for more feedback on the ticket because the change is highly visible. - Two open/contested details: search icon now faces the opposite direction from the Dashicon it replaces; Posts icon may switch from pushpin to pen glyph, with active internal disagreement. - History: Dashicons shipped in WordPress 3.8 "Parker" (Dec 12, 2013) as part of the MP6 admin redesign, replacing sprite-sheet icons; 167 icons at launch, 197 after WordPress 3.9. - Not stated: whether the broader `dashicons-*` icon-font classes used by third-party plugin/theme UIs are being deprecated on any timeline, or whether this patch is scoped to core admin chrome only. **WordPress 7.1.1 maintenance release** - Ships September 17, 2026. - Justification given: elevated volume/severity of forum, Trac, and Gutenberg-repo reports since 7.1 shipped — source doesn't quantify this or name who made the assessment. - Scope rule (standard for x.x.1 releases): only 7.1-cycle regressions or features deliberately deferred to cycle-end; no new features. **Gutenberg 23.9** - Insert-block button now available directly from a block's own toolbar (galleries, nested group blocks). - Global Styles: per-block custom-override indicator dot; filter to isolate touched blocks. - Group block: independent horizontal/vertical spacing under flexible/grid layout. - theme.json can now style form labels. - Global Styles extended to blockquotes, input fields, dropdowns. - Custom duotone palettes addable from the Global Styles panel (not limited to theme-supplied duotones). - Unspecified accessibility/performance internals; one named example — faster block selection in long posts. **WordCamp US: WordPress ↔ PHP community relationship** - Informal talk, Chatham House Rule — reportable content, no individual attribution possible by design. - Reported diagnosis: much of the PHP community doesn't consider WordPress developers "real" PHP developers. - Two named causes: WordPress's backward-compatibility commitment (perceived as slowing PHP's evolution) and WordPress's limited participation in PHP feature-decision discussions. - Downstream friction: plugin external dependencies increasingly drop support for PHP versions WordPress core still admits. - Hard number: PHP 7.4 still runs on ~18% of sites; no post-EOL security patches, and little other upgrade incentive reported. - Discussed but not committed: hosting-side coordinated upgrade push; PHP 8.x speed as an upgrade lever; risk that a syntax-breaking PHP 9 makes single-codebase 7.4+9 compatibility impossible; resuming WebAssembly conversation (WordPress already uses WASM in Playground); moving WordPress's HTML API work into PHP itself; restricted/"untrusted" permission loading for plugins with unsafe dependencies (wish-list level). - Concrete follow-up named: check whether real-world old-WordPress-version distribution has shifted; explore automatic PHP-compatibility warnings to plugin developers. **Code Reference runnable examples** - WordPress 7.1: first two Playground-powered "Run" buttons live now; more planned for 7.2. - Examples run in-browser, no local setup, defined inside each function's DocBlock in core itself, syntax slightly different from a normal example. - A handbook page documenting the format is promised, not yet published per the source. **bbPress 2.6.15** - Five security flaws fixed, one with its own CVE (identifier not given in the source). - Hardened: editing/splitting/merging topics and replies; updating profiles; viewing private/hidden forums; imported-password verification. - Also fixes PHP warnings in some forum requests. **Licensing** - Distributed under CC BY-NC-SA 4.0, as a derivative of the Spanish-language WPpodcast. ## 📚 References - [Replacing Dashicons in the admin bar and menu — Make WordPress Core](https://make.wordpress.org/core/2026/09/04/replacing-dashicons-in-the-admin-bar-and-menu/) - [WordPress 7.1.1 release schedule — Make WordPress Core](https://make.wordpress.org/core/2026/09/02/wordpress-7-1-1-release-schedule/) - [What's new in Gutenberg 23.9 (2 September) — Make WordPress Core](https://make.wordpress.org/core/2026/09/02/whats-new-in-gutenberg-23-9-2-september/) - [WordCamp US 2026 — WordPress/PHP conversation — Make WordPress Core](https://make.wordpress.org/core/2026/09/03/wordcamp-us-2026-php-conversation/) - [Runnable code examples are now live in the Code Reference — Make WordPress Core](https://make.wordpress.org/core/2026/09/04/runnable-code-examples-are-now-live-in-the-code-reference/) - [bbPress 2.6.15 is out — bbPress.org](https://bbpress.org/blog/2026/09/bbpress-2-6-15-is-out/) - [Podcast en español (source this episode derives from)](https://www.wppodcast.es/) - [Creative Commons BY-NC-SA 4.0 license](https://creativecommons.org/licenses/by-nc-sa/4.0/) - [WPpodcast — home](https://www.wppodcast.org/) ## 🗣️ Paraphrase The episode's title story is that WordPress is quietly retiring the icon font it's used in the admin interface since 2013. The stated reason isn't a visual refresh — it's that icon fonts, as a technical pattern, are broken for accessibility in three specific ways: screen readers can't reliably announce characters that live in undefined Unicode territory, high-contrast and forced-colors modes mangle them because the operating system treats them as plain text, and a failed or slow font load leaves visible junk on screen instead of nothing. SVG doesn't have any of those three problems by construction. The patch is real but not finished: it only touches the admin bar and sidebar menu so far, two icons (search, Posts) are still being argued over, and the team says explicitly it hasn't gotten enough feedback on how visible this change will be to end users. Everything else in the episode is standard weekly maintenance: a bug-fix-only point release landing September 17, a Gutenberg minor with small editing conveniences, an off-the-record talk about WordPress's uneasy standing in the wider PHP world (backward compatibility as both WordPress's core promise and its reputational liability, with 18% of the web still running an unpatched PHP version), a documentation feature that lets you run WordPress code examples straight from the docs page, and a bbPress security release patching five flaws, one serious enough to carry its own CVE. ## 📰 Newsletter This week's WPpodcast digest (Aug 31–Sep 6) leads with real news for accessibility-minded devs: WordPress is moving off Dashicons in the admin bar and sidebar menu, in favor of SVG icons rendered through a function that shipped in 7.1. The stated case for the switch is solid — icon fonts occupy undefined Unicode territory that screen readers handle inconsistently, they break under Windows High Contrast/forced-colors modes because the OS treats them as text, and a failed font load shows as broken-looking boxes where an SVG would just quietly not render. Two open items worth watching on the ticket: a mirrored search icon and a possible pushpin-to-pen swap for Posts — and it's still unclear whether this touches the `dashicons-*` classes plugin and theme authors use directly, so audit your own admin UI before assuming nothing changes. Also in the mix: 7.1.1 lands September 17 (bug fixes only), Gutenberg 23.9 tightens up block-insertion and Global Styles, the Code Reference now has "Run" buttons powered by Playground, bbPress 2.6.15 patches five security issues including one CVE, and a WordCamp US Chatham House Rule talk surfaced a hard number worth remembering: PHP 7.4 still runs roughly 18% of the web. ## ✅ Action Items #### DevRel - Developer experience: the Code Reference's new Playground-powered "Run" buttons are a concrete DX win worth spotlighting in docs/talks once the promised handbook page on authoring runnable DocBlock examples ships. - Education: the Dashicons→SVG rationale (Unicode ambiguity, forced-colors breakage, fail-silent vs. fail-visible) is a ready-made case study for an accessibility workshop or office-hours session on icon fonts vs. SVG generally, not just in WordPress. #### OSPO - Policy & Governance: the WordCamp US PHP-relationship talk (backward compatibility vs. PHP community perception) is exactly the kind of cross-project tension OSPO-style governance forums exist to formalize — currently living only in an off-the-record Chatham House Rule conversation. - Security Management: the bbPress 2.6.15 CVE is a concrete item for vuln-intake tracking; confirm the CVE ID and whether any dependent plugin in your own stack needs the update. #### Community - Cross-project: the WordCamp US talk's concrete follow-ups (checking real-world old-WordPress-version distribution; automatic PHP-compatibility warnings to plugin devs) are trackable deliverables worth a status check at the next contributor gathering. #### WordPress - **Core:** track the "Replacing Dashicons in the admin bar and menu" ticket — the team is explicitly asking for more feedback, and the search-icon-direction and Posts pushpin/pen questions are still open. - **Core Performance:** Gutenberg 23.9's faster long-post block selection is a shippable, measurable perf win worth a before/after benchmark note. - **Accessibility:** this is the week's most substantive accessibility item outside a dedicated accessibility release — worth a direct a11y-team review of the Dashicons ticket against WCAG 1.1.1, 1.4.11, and 4.1.2 (see Accessibility Assessment below) before it ships. - **Documentation:** the Code Reference's runnable-example format needs its promised handbook page before contributors can add their own; flag for the docs team as a concrete open deliverable. - **Plugins / Themes:** audit whether your own plugin or theme references `dashicons-*` classes directly — the source doesn't state whether third-party usage is in scope for this patch or only core's own admin chrome. - **Hosting:** the PHP 7.4 (~18% of sites) adoption number is directly actionable for hosts considering a coordinated upgrade push, one of the ideas raised (not committed) at WordCamp US. - **Training:** the how-to-do vs. how-to-think distinction doesn't apply here, but the Code Reference "Run" button is a natural fit for a hands-on training module once documented. #### The WPOCC - Not applicable to this source — no fellowship, funding, or WPOCC-specific governance content. #### FAIR - Not applicable to this source — no federation, provenance, or governance-artifact content. ## 🧪 Hypotheses - H1: Replacing Dashicons with SVG in the admin bar/sidebar menu measurably reduces screen-reader announcement errors compared to the current icon-font implementation, testable with NVDA/JAWS/VoiceOver against both versions of wp-admin. - H2: The current Dashicons implementation renders visibly differently (color loss, shape loss, or invisibility) under Windows High Contrast Mode / `forced-colors` compared to the SVG replacement. - H3: The SVG patch as shipped is scoped to core admin chrome only, and does not alter behavior of `dashicons-*` classes referenced directly by third-party plugin/theme code. - H4: WordPress's PHP-version support floor (currently admitting versions as old as PHP 7.4-era code) measurably correlates with the rate of unsupported/abandoned Composer dependencies in the plugin ecosystem. - H5: A coordinated hosting-side PHP upgrade push moves the 18%-on-7.4 number down faster over a fixed window than security-only messaging has to date. ### 📊 Methodology - For H1/H2: recruit AT users (screen reader and forced-colors/high-contrast users) to test both the current Dashicons admin bar and a build of the SVG patch; log announcement errors and visual-rendering failures per icon, compared against a scripted checklist derived from the three failure modes named in the source. - For H3: diff the patch itself (once merged) against every `dashicons-*` CSS class reference in a representative sample of popular plugins/themes to confirm scope empirically rather than relying on the source's silence on the question. - For H4: cross-reference WordPress's minimum-PHP-version policy history against Packagist/Composer abandonment and PHP-version-constraint data for the top N WordPress-ecosystem packages. - For H5: A/B two hosting cohorts (coordinated-upgrade messaging vs. status-quo security messaging) and track PHP-version distribution over a fixed quarter. ### ❓ Questions - Does the Dashicons→SVG patch touch the `dashicons-*` icon-font classes used directly by third-party plugins and themes, or is it scoped to core's own admin bar and sidebar menu only? The source is silent on this. - What specifically resolves the search-icon-direction and Posts pushpin-vs-pen disagreements, and on what timeline, given the team says it hasn't gotten enough feedback yet? - Who is "the team" acknowledging elevated 7.1 report volume, and what's the actual number behind "volume and severity"? Not stated. - Given the Chatham House Rule framing, is there a public, attributable writeup of the WordCamp US PHP conversation anywhere, or does this episode represent the only public record of that discussion's content? - Does the intro deck's "WordPress 7.2" target for the Dashicons patch reflect a confirmed release-scoping decision, or a reasonable guess based on the 7.1 function it depends on? The transcript body never restates the version. ### 🔮 Future Research - No before/after accessibility audit is cited for the Dashicons patch — an actual AT (assistive technology) test matrix against the three named failure modes would convert this from a plausible mechanism to a verified fix. - No data given on how many active plugins/themes reference `dashicons-*` classes directly, which is the single biggest unknown for backward compatibility here. - No public record cited for the WordCamp US PHP talk beyond this episode's summary — worth checking whether Make WordPress Core, PHP.net, or php-fig publish any follow-up on the discussed ideas (WebAssembly, HTML API upstreaming, restricted-permission plugin loading). - No specifics given on the bbPress CVE (identifier, CVSS score, affected code path) — worth pulling directly from the bbPress security advisory once published. ### 💡 Implications - **Practice.** Any theme or plugin author using `dashicons-*` classes in their own admin UI should treat this patch as a prompt to audit that dependency now, before the scope question in Questions above is resolved by default (i.e., by the patch shipping without warning to third-party code). - **Policy/governance.** The WordPress↔PHP relationship item is a genuine cross-project governance question (backward compatibility as a stated core value vs. a documented ecosystem cost) surfaced only in an off-the-record forum; it would benefit from a public, attributable governance thread rather than living solely in a Chatham House Rule summary. - **Security.** The bbPress CVE is immediately actionable — sites running 2.6.14 or earlier should update. The PHP 7.4 adoption number (18%) is a live security exposure independent of WordPress core, since 7.4 receives no further security patches. - **Education.** The three named icon-font accessibility failure modes are a clean, transferable teaching example for any UI work — not just WordPress admin — since the underlying mechanism (Unicode PUA glyphs, forced-colors text handling, fail-visible vs. fail-silent asset loading) applies to any icon-font-based interface. - **Funding models.** Not applicable to this source. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level ≈ 15.8 (college level). Basis: 1,083 words across 36 sentences (≈30.1 words/sentence average) and 1,803 estimated syllables, computed directly against the transcript text. The long, clause-dense sentences are consistent with the episode's own stated origin as a translated derivative of the Spanish-language WPpodcast — this reads like edited translation, not native spoken English. #### 👀 Visual learners - **Present:** none in the captured artifact — the html_content is text-only (a written transcript plus podcast-app badge images with no descriptive alt text). - **Improve:** a before/after screenshot pair (current Dashicons admin bar vs. the SVG patch) and a labeled diagram of the three failure modes (undefined Unicode point, forced-colors remap, fail-visible vs. fail-silent) would make the accessibility argument far more legible than prose alone. #### 🔊 Aural learners - **Present:** this is a podcast episode natively; the audio itself (not captured in html_content) is the primary aural artifact. - **Improve:** none needed for the audio format itself; a written show-notes page (this artifact) already serves non-aural learners as a complement. #### 🗣️ Verbal learners - **Present:** the episode defines its technical terms in-line as it introduces them (e.g., what "forced color settings" means functionally, what MP6 was). - **Improve:** an explicit glossary entry distinguishing "icon font" from "SVG icon" from "forced-colors mode" would help readers unfamiliar with any one of the three. #### 🧩 Kinesthetic learners - **Present:** the Code Reference item describes a genuinely hands-on artifact (the in-browser "Run" button) that a reader could try immediately. - **Improve:** a direct link to a live Code Reference page with a working "Run" button, and a link to the Dashicons ticket for readers who want to leave feedback directly, would convert description into action. #### 🧠 Logical learners - **Present:** the Dashicons rationale is structured as three explicit, numbered-in-substance failure mechanisms, and the PHP item pairs a diagnosis with a concrete number (18%) and several named response options. - **Improve:** a decision table mapping each of the three icon-font failure modes to its corresponding WCAG success criterion (done in Accessibility Assessment below) would make the standards linkage explicit rather than left to the reader. #### 🧑‍🤝‍🧑 Social learners - **Present:** the team's explicit request for more feedback on the Dashicons ticket is itself a social/collaborative hook — the item asks for participation, not just consumption. - **Improve:** a direct pointer to where and how to leave that feedback (the ticket link is present in this note's References, but the source itself doesn't spell out the mechanism) would lower the barrier to acting on the request. #### 🧘‍♀️ Solitary learners - **Present:** the whole episode is a self-contained weekly digest, consumable start to finish without external interaction. - **Improve:** none needed; the format already suits self-paced, solitary consumption. #### 🌿 Naturalistic learners - **Present:** none — no ecological or systems-in-nature framing anywhere in the transcript. - **Improve:** not a natural fit for this content; no changes recommended. ### 📊 Accessibility Assessment *Two layers assessed here: (1) the technical substance of the Dashicons→SVG accessibility fix the source reports on, engaged on its own mechanical terms, and (2) the captured artifact's own accessibility as a piece of web content. The source itself is a transcript page, not the admin UI it describes, so most of (2) is thin by nature — the real accessibility content is (1).* #### Screen reader semantics - **The reported mechanism, engaged directly.** Dashicons is a webfont: each icon is a glyph mapped to a Unicode code point, typically injected via CSS `content:` on a pseudo-element or via a literal character in markup. WordPress's Dashicons specifically use Private Use Area (PUA) code points — Unicode ranges reserved for exactly this kind of vendor-specific glyph, with no assigned semantic meaning in the Unicode standard. That's precisely why the source's claim holds up mechanically: a screen reader encountering a PUA code point has nothing standard to announce. Depending on the assistive technology, the font-fallback chain, and whether the surrounding markup includes `aria-hidden="true"` plus a `.screen-reader-text` label (the pattern WordPress core generally does apply around its own icon usage, though the source doesn't confirm whether every admin-bar instance is correctly labeled), the result ranges from silence, to a generic "private use character" announcement, to literally reading a stray symbol mid-sentence — exactly the failure the source describes. This maps to **WCAG 2.2 SC 1.1.1 Non-Text Content (A)**: an icon-font glyph is, to the accessibility tree, indistinguishable from text content, so it inherits text-content expectations (readable, meaningful) that a purely decorative glyph can't satisfy without deliberate `aria-hidden` + text-alternative wrapping — a pattern icon fonts make easy to forget precisely because the glyph *looks* like it's "just an icon," not text requiring the same alt-text discipline as an `<img>`. - **Improve:** SVG icons sidestep this class of bug structurally, but only if the migration itself is done correctly — an inline `<svg>` needs `aria-hidden="true"` and (in most implementations) `focusable="false"` to avoid becoming an unlabeled, unexpectedly focusable node in some browsers, and any icon conveying meaning on its own (not paired with visible text) still needs an accessible name via `aria-label` or a visually-hidden text node. The source doesn't confirm this pattern was followed in the patch; it's worth checking directly once the ticket lands. #### Keyboard navigation - **Not observed directly** — the source describes an icon *rendering* change, not an interaction change, so focus order and keyboard operability of the admin bar/sidebar menu items themselves shouldn't change. **One concrete migration risk worth flagging:** unlike a font glyph (never independently focusable), an `<svg>` element can become an unexpected tab stop in some browser/AT combinations if `focusable="false"` isn't set explicitly — a common regression in icon-font-to-SVG migrations generally. Relevant if not already handled: **SC 2.1.1 Keyboard, SC 2.4.3 Focus Order.** #### Contrast and readability - **The reported mechanism, engaged directly.** The source's claim that icon fonts "break with Windows high contrast mode... because the system treats them as text" is literally accurate: forced-colors mode (the modern, cross-browser generalization of Windows High Contrast Mode, specified in the CSS Color Adjustment Module) remaps a constrained palette onto elements based on their *type* — text gets `CanvasText`, backgrounds get `Canvas`, and so on. A font glyph is, to the rendering engine, text — so its fill color gets forcibly remapped, and depending on how the glyph's "background" (if any) is styled, shape and color can collapse into indistinguishable sameness or disappear. An inline SVG's `<path fill>` is *not* automatically treated as text by forced-colors mode, which cuts both ways: it can be told to respect forced-colors explicitly (via `forced-color-adjust` and `context-fill`/system color keywords) for more predictable, intentional behavior, but it also won't get the "free" (if unreliable) system remapping a text glyph gets by default if the developer doesn't add that handling. Net effect: the source's claim is directionally correct, and the fix genuinely requires deliberate forced-colors CSS on the SVG side to be a real improvement, not just an automatic one. Maps to **SC 1.4.11 Non-Text Contrast (AA)** most directly; **SC 1.4.3 Contrast (Minimum)** if any icon carries a text label rendered in the same problematic way. - **Improve:** confirm the patch includes explicit `forced-colors` media-query handling for the new SVGs rather than assuming the swap alone resolves the problem. #### Text resizing and reflow - **Not observed directly**, but mechanically relevant: SVG icons defined with a `viewBox` scale cleanly at any zoom level without the sub-pixel blur or hinting artifacts an icon-font glyph can show at unusual font-size/zoom combinations — a minor, real plus for **SC 1.4.4 Resize Text** and **SC 1.4.10 Reflow**, not claimed explicitly by the source but a genuine side benefit of the SVG approach. #### Media and captions - **Present:** this artifact is itself a written transcript of an audio podcast episode, which satisfies the base text-alternative requirement for the audio (**SC 1.2.1 Audio-only**) at the episode level. - **Not observed:** whether the transcript published alongside the actual audio player on wppodcast.org is auto-generated or editor-reviewed for accuracy isn't stated in this captured content. #### Forms and interactions - **Not applicable** — no forms or interactive controls appear in the captured artifact. #### Standards reference - Directly engaged above: WCAG 2.2 AA **1.1.1** (Non-Text Content — the core Dashicons mechanism), **1.4.11** (Non-Text Contrast — forced-colors), **1.4.3** (Contrast, conditional), **1.4.4 / 1.4.10** (Resize/Reflow — SVG scaling benefit), **2.1.1 / 2.4.3** (Keyboard/Focus Order — SVG migration risk), **1.2.1** (Audio-only, satisfied by the transcript itself). The forced-colors mechanism itself is defined outside WCAG proper, in the CSS Color Adjustment Module Level 1 and the `forced-colors` media feature — WCAG 1.4.11 is the closest AA-level success criterion covering its practical effect, since no SC directly names forced-colors mode as of WCAG 2.2. ### 🌍 DEIB Assessment #### Cultural breadth - **Present:** the episode itself is explicitly a derivative translation of a Spanish-language original podcast, distributed under a shared Creative Commons license — a genuine cross-language, cross-audience distribution model rather than an English-only production. - **Improve:** the source doesn't name the translator/adapter or describe the translation process; crediting that work explicitly would strengthen the attribution chain the CC license already implies. #### Inclusive language - **Present:** consistent, plain technical register throughout; no idiomatic phrasing likely to translate poorly, consistent with content that already went through one language conversion. - **Improve:** none needed; the register is already direct and low-idiom. #### Neurodiversity support - **Present:** the episode is chunked into clearly separable topical items (release, Gutenberg, Dashicons, PHP talk, docs, bbPress, licensing), aiding scanning and re-listening to a specific segment. - **Improve:** no spoken or written segment markers (timestamps, chapter titles) are present in the captured content — adding them would help listeners/readers who rely on structure to navigate a single-track audio episode or its transcript. #### Representation - **Present:** the host, Alicia Ireland (pronouns not stated in the source; they/them used here per policy), is named directly; the WordCamp US talk is deliberately anonymized by Chatham House Rule, so no individual contributor is named or over/under-represented in that segment. - **Improve:** not assessable further from this artifact — no other individuals are named or described. #### Psychological safety - **Present:** neutral, informational tone throughout; the PHP-relationship item reports a documented tension without inflammatory framing on either "side" (WordPress core vs. the broader PHP community). - **Improve:** none needed; no sensitive or high-stakes material requiring a content warning. ### ✅ Logical Validity #### Strong reasoning - **Causal/mechanistic reasoning on icon fonts vs. SVG.** The claim that icon fonts fail accessibility in three specific, named ways (undefined Unicode announcement, forced-colors text-handling breakage, fail-visible vs. fail-silent loading) is not just asserted — each failure mode has a verifiable technical mechanism (see Accessibility Assessment), and the mechanisms genuinely predict the described symptoms. This is the strongest reasoning in the episode and it holds up independently of the source's own authority. - **Numeric grounding on PHP adoption.** The PHP 7.4-at-18% claim gives the ecosystem-friction argument a concrete, falsifiable anchor rather than leaving "old PHP is still common" as a vague assertion. #### Fallacies - **Unattributed generalization ("much of the PHP community").** Location: the WordCamp US item's framing that "much of the PHP community doesn't consider WordPress developers 'real' PHP developers." Why it's weak: this is reported as a settled diagnosis from an off-the-record talk under Chatham House Rule, with no survey data, poll, or named source — "much of" quantifies nothing. Fix: flag explicitly as a perception reported by unnamed contributors at one talk, not a measured finding, which this note does above by labeling it "reportedly." - **Unattributed severity claim.** Location: the 7.1.1 justification that report "volume and severity" since 7.1's launch justifies earlier-than-usual advance notice. Why it's weak: no number, ticket count, or named team member backs the claim; "volume and severity" is asserted, not shown. Fix: a linked dashboard of open regression tickets, or a stated count, would convert this from assertion to evidence — the source's own linked release-schedule post may contain this detail, which this note cannot confirm without fetching it. #### Tone of voice - Informational, first-person-plural at the open/close ("you're listening to," "thanks for listening"), otherwise third-person reporting register throughout the body — consistent with a scripted news-roundup rather than a personal essay or opinion piece. No hedging language undermines the technical claims; the two open Dashicons questions (icon direction, pushpin vs. pen) are the only places the episode itself signals uncertainty, and it signals them directly rather than glossing over them. ### 🛡️ DARVO Analysis - **Deny:** Not applicable to this source — there is no accusation of wrongdoing against any named or accused party anywhere in the transcript. The closest candidate, the WordCamp US "WordPress developers aren't 'real' PHP developers" perception, is a reported community sentiment about an institution (WordPress), not an accusation an accused party is denying — no WordPress representative is quoted responding to or denying this framing in the source. - **Attack:** Not applicable — no critic or accuser is named or attacked. The PHP-relationship item is reported neutrally, listing causes (backward compatibility, limited participation in PHP's own process) without characterizing the PHP community's perception as illegitimate or attacking its holders. - **Reverse victim/offender:** Not applicable — no victim/offender framing appears anywhere in the episode; every item is either a technical status update (release, patch, security fix) or a reported-but-unresolved community tension, not a conflict narrative with a victim and an offender. - **Actual rhetoric, since DARVO doesn't apply:** the episode's dominant rhetorical mode is transparent hedging on unresolved items — "the team is explicitly requesting more feedback," "a couple of details remain open," "still at wish-list level," "there's already debate over which fits better." Rather than presenting the Dashicons patch or the PHP-relationship discussion as settled, the source repeatedly flags exactly where consensus hasn't formed yet. That's the opposite of a DARVO pattern: it's disclosure of open disagreement rather than concealment or deflection of it. ## 🎯 Conclusion The Dashicons→SVG patch is the episode's real story, and it holds up under direct technical scrutiny: icon fonts genuinely fail screen readers, forced-colors modes, and asset-load resilience in the specific ways the source describes, and SVG genuinely fixes the underlying mechanism rather than just the appearance. What the source doesn't resolve — scope beyond core's own admin chrome, a confirmed release version in the transcript body itself, and two still-open icon-direction regressions — are the concrete things worth tracking before calling this "done." Practical next step for a reader: if you maintain a plugin or theme that references `dashicons-*` classes directly, check the linked core ticket now rather than after the patch ships, and if you run bbPress, confirm your version against 2.6.15's CVE fix this week. ## 🔄 Refactor Appendix — 155. Goodbye, Dashicons > Density: 5 Literature atoms (H4), 2 Permanent candidates (H4). > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > Atomicity: one declarative sentence per atom. ### 📚 Literature Atoms (H4) #### [H1] Icon fonts read unpredictably to screen readers > [!quote] > 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 **Context & use**: - Stated as the first of three named reasons for replacing Dashicons with SVG icons in the admin bar and sidebar menu. - Mechanically accurate: Dashicons uses Private Use Area Unicode code points, which carry no standard semantic meaning for assistive technology to announce. **Tags**: #xref #aphorisms **Highlight**: [source](https://www.wppodcast.org/podcast/goodbye-dashicons/)  #### [H2] Icon fonts break under forced-colors mode > [!quote] > they break with Windows high contrast mode and other forced color settings, because the system treats them as text **Context & use**: - Second of the three named Dashicons→SVG rationale points. - The mechanism is literal: forced-colors mode remaps elements by content type, and a font glyph is treated as text regardless of its visual role as an icon. **Tags**: #xref **Highlight**: [source](https://www.wppodcast.org/podcast/goodbye-dashicons/)  #### [H3] SVGs fail invisibly where icon fonts fail as boxes > [!quote] > the result is boxes or strange symbols that look like a broken site, while an SVG simply doesn’t display if it fails **Context & use**: - Third named rationale point; contrasts icon-font failure (visible, broken-looking) against SVG failure (silent). - Directly supports the case that SVG is a strictly better default for admin-UI icons, independent of aesthetics. **Tags**: #xref **Highlight**: [source](https://www.wppodcast.org/podcast/goodbye-dashicons/)  #### [H4] Dashicons launched in WordPress 3.8 with 167 icons > [!quote] > Dashicons first appeared in WordPress 3.8 Parker, released December 12, 2013. **Context & use**: - Historical anchor for the icon set being replaced; part of the MP6 admin-redesign project. - Icon count grew from 167 at launch to 197 after WordPress 3.9 added 30 more — context for the scale of what SVG is replacing. **Tags**: #xref **Highlight**: [source](https://www.wppodcast.org/podcast/goodbye-dashicons/)  #### [H5] New SVG search icon faces the opposite direction > [!quote] > the search icon ends up facing the opposite direction from the Dashicon it replaces **Context & use**: - One of two named, still-open regressions in the SVG patch (the other: a possible Posts pushpin-to-pen swap under active debate). - Concrete evidence the patch isn't a clean 1:1 icon swap — worth a directionality QA pass before shipping any icon-family migration. **Tags**: #xref **Highlight**: [source](https://www.wppodcast.org/podcast/goodbye-dashicons/)  ### 🧠 Permanent Candidates (H4) #### [P1] Icon-font accessibility bugs are structural, not incidental **Claim** (Courtney's voice): When I choose between an icon font and inline SVG for UI icons, I treat the icon font's undefined-Unicode-glyph and text-like-rendering mechanics as a built-in accessibility liability I can't patch away later, not an implementation detail. **Evidence pointer**: [[#H1]] (also [[#H2]], [[#H3]]) **Scope & conditions**: Holds for any UI pattern rendering icons as font glyphs or ligatures (webfont icon sets generally, not just Dashicons); less relevant to raster sprite icons, which don't inherit forced-colors text-handling or PUA-announcement risk in the same way. **Links** (≥1 with annotation): - [[WCAG non-text content]] — because extends: SC 1.1.1 is the standards home for this exact failure class. - [[Forced colors mode]] — because applies-in: any admin or dashboard UI tested under Windows High Contrast / `forced-colors`.  #### [P2] Icon-family swaps need an explicit directionality QA pass **Claim** (Courtney's voice): Before shipping an icon-set replacement, I check every directional or orientation-sensitive glyph (search, back/forward, arrows) by eye against the set it replaces, rather than assuming a same-name icon swap preserves orientation. **Evidence pointer**: [[#H5]] **Scope & conditions**: Applies to icon-library or icon-family migrations at any scale (webfont-to-SVG, icon-set major-version bumps); less relevant to single-icon spot fixes already reviewed individually. **Links** (≥1 with annotation): - [[#H1]] — because extends: both are migration edge cases the source shows the team is still resolving in the open ticket, not problems solved by the swap itself.  ### ✏️ Fleeting Queue - [F1] Does the Dashicons→SVG patch extend to `dashicons-*` classes used directly by third-party plugins/themes, or only core's own admin bar and sidebar menu? — https://make.wordpress.org/core/2026/09/04/replacing-dashicons-in-the-admin-bar-and-menu/ #xref - [F2] Test current screen reader (NVDA/VoiceOver) behavior against the live Dashicons admin bar before assuming the described unpredictability, rather than taking the mechanism as sufficient proof of the symptom. — #xref ### → Things 3 (max 2 actions) - [ ] Check the "Replacing Dashicons in the admin bar and menu" core ticket for current status on the search-icon-direction and Posts pushpin/pen questions — context #wordpress-core #things - [ ] Confirm the bbPress 2.6.15 CVE identifier and check whether any site or plugin in active use depends on an older bbPress version — context #security #things  📄 **Full text:** [[Full Document Contents/Articles/155. Goodbye, Dashicons.md|155. Goodbye, Dashicons by wppodcast.org]] ## Highlights - Screen readers announce them unpredictably, since they occupy Unicode code points with no defined meaning and sometime ([View Highlight](https://read.readwise.io/read/01m25w24pzwmepsxn7r3jgq324)) - Note: The accessibility case for SVG over icon fonts — Private Use Area code points have no defined semantics. - Tags: xref, accessibility - they break with Windows high contrast mode and other forced color settings, because the system treats them as text ([View Highlight](https://read.readwise.io/read/01m25w27qq2ac6kwde8r9rkh3h)) - Note: Second failure mode: forced-colors treats glyphs as text. Maps to WCAG 1.4.11. - Tags: accessibility, xref