# Icon Fonts Carry a Structural Accessibility Liability ## Claim An icon font's undefined-Unicode-glyph and text-like rendering behaviour is a built-in accessibility liability that cannot be patched away later, so the choice between an icon font and inline SVG is an accessibility decision made at selection time. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - The mechanisms are inherent to the delivery format: glyphs land in private-use code points that assistive technology and font-substitution both mishandle. - Font substitution is the unfixable part — when the icon font fails to load, the private-use code point renders as whatever the fallback supplies. - Inline SVG moves the problem to markup, where it is at least addressable with role and label attributes. - Explains why WordPress's Dashicons retirement is an accessibility change rather than only a visual refresh. ## Evidence From the WordPress podcast episode on retiring Dashicons, which traces the icon-font rendering mechanics behind the decision. ## Links - [[An Icon Needs a Visible Label Not Just an Accessible Name]] — the complementary requirement — format choice and labelling are separate obligations - [[Icon-Family Swaps Need a Directionality QA Pass]] — the migration hazard created by acting on this claim - [[Format Choice Is an Accessibility Control Exercised Before Remediation]] — the general principle this is a worked instance of - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — the build-time thread on decisions that foreclose remediation.