WordPress 7.1 introduces wp_get_icon for server-rendered SVG icons, and a visible follow-up proposal replaces Dashicons in the admin bar and menu with WordPress icons. Plugin CSS that targets font families, pseudo-elements, line height, fixed glyph widths, fill, or text color can render black, misaligned, invisible, duplicated, or inaccessible icons when the markup becomes SVG.
Use this for plugin and theme developers, agency admin customizations, white-label dashboards, accessibility testing, RTL sites, high-contrast environments, and extensions that add toolbar or sidebar menu nodes.
Quick answer
Inventory every admin menu and toolbar icon plus CSS selectors that mention dashicons, font-family, content, before, line-height, width, height, color, fill, or stroke. Render the plugin on WordPress 7.1 using its current icon, a wp_get_icon SVG, missing icon, decorative icon, and labeled icon. Test normal and compact menus, collapsed sidebar, hover, current item, focus, RTL, dark admin schemes, 200 percent zoom, Windows forced colors, and no custom CSS. Prefer currentColor-aware fill rules scoped to the plugin icon class, and do not depend on SVG stroke until the supported sanitizer contract allows it.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Decorative | No label | Hidden from screen reader |
| Informative | Translated label | Announced once |
| Forced colors | High contrast | Visible icon and focus |
| Missing icon | Unknown name | Usable fallback |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory font-glyph assumptions | Record WordPress version, icon source, collection and name, label behavior, menu and toolbar node IDs, admin color scheme, plugin CSS selectors, SVG attributes, and fallback. | Plugin menu and toolbar icons remain visible and aligned in every supported state and color scheme. |
| Register a fill-based SVG | Search styles and PHP for dashicons, font-family, pseudo-element content, wp_get_icon, wp_register_icon, fill, stroke, currentColor, fixed dimensions, and menu-image assumptions. | Decorative icons are hidden from assistive technology, while informative icons have one translated name. |
| Scope currentColor CSS | Test expanded and collapsed menus, toolbar, hover, active, focus-visible, submenu, badge, long translated labels, RTL, zoom, reduced motion, forced colors, and custom admin schemes. | Forced-colors mode, keyboard focus, RTL, collapsed menus, and 200 percent zoom remain usable. |
| Test accessibility and forced colors | Inspect accessible name, aria-hidden state, duplicate spoken labels, SVG dimensions, computed color and fill, vertical alignment, pointer target, focus ring, and DOM order. | Legacy pseudo-elements and font rules do not duplicate or override the SVG, and an unknown icon has a clear fallback. |
What to check first
- Record WordPress version, icon source, collection and name, label behavior, menu and toolbar node IDs, admin color scheme, plugin CSS selectors, SVG attributes, and fallback.
- Search styles and PHP for dashicons, font-family, pseudo-element content, wp_get_icon, wp_register_icon, fill, stroke, currentColor, fixed dimensions, and menu-image assumptions.
- Test expanded and collapsed menus, toolbar, hover, active, focus-visible, submenu, badge, long translated labels, RTL, zoom, reduced motion, forced colors, and custom admin schemes.
- Inspect accessible name, aria-hidden state, duplicate spoken labels, SVG dimensions, computed color and fill, vertical alignment, pointer target, focus ring, and DOM order.
- Remove plugin CSS, test an unknown icon that returns an empty string, and verify a text or established fallback keeps the command understandable.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
echo wp_get_icon(
'my-plugin/star',
array( 'size' => 24, 'class' => 'my-plugin-icon' )
);
// CSS: .my-plugin-icon { fill: currentColor; }
// Provide a usable fallback if the function returns an empty string.
Why this usually happens
- A Dashicon is a font glyph, while wp_get_icon returns sanitized SVG markup.
- Color cascades through text but an SVG shape may need fill set to currentColor.
- Stroke attributes are not currently preserved through the server icon sanitization path.
- A pseudo-element remains active and renders beside the new SVG.
Decision rule
Ship the icon change only when the command remains visible, aligned, focusable where appropriate, and named correctly across menu states, schemes, RTL, zoom, forced colors, and missing-icon fallback.
Production verification checklist
- Plugin menu and toolbar icons remain visible and aligned in every supported state and color scheme.
- Decorative icons are hidden from assistive technology, while informative icons have one translated name.
- Forced-colors mode, keyboard focus, RTL, collapsed menus, and 200 percent zoom remain usable.
- Legacy pseudo-elements and font rules do not duplicate or override the SVG, and an unknown icon has a clear fallback.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory font-glyph assumptions
- Register a fill-based SVG
- Scope currentColor CSS
- Test accessibility and forced colors
- Provide a missing-icon fallback
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the public page, stored record, API response, accessibility tree, queue, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, cache, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test a WordPress 7.1 plugin.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references