WCAG 2.2 Guidelines for Web Icons and SVGs
Ensure your SVG icons are fully accessible. A developer's checklist for meeting WCAG 2.2 guidelines, covering touch targets, contrast, and aria attributes.
Web Content Accessibility Guidelines (WCAG) dictate how to make web content more accessible to people with disabilities. With the release of WCAG 2.2, there are specific, measurable criteria that directly impact how you design and implement SVG icons.
If your site fails these checks, you aren’t just alienating users—you could be exposing your business to legal liability.
Here is the definitive developer’s checklist for WCAG 2.2 compliant SVG icons.
1. Target Size (Minimum) (Criterion 2.5.8)
The Rule: The size of the target for pointer inputs (mouse clicks, finger taps) must be at least 24 by 24 CSS pixels.
While WCAG 2.1 recommended 44x44px, WCAG 2.2 introduced the Target Size (Minimum) (AA level) which explicitly sets a hard floor at 24x24px to prevent elements from being too small to click on mobile devices.
How it affects SVGs:
If you have a tiny 16x16 “Close” icon, the bounding box of the clickable area around the icon must be padded to reach 24x24.
<!-- Bad: Target is too small (16x16) -->
<button style="padding: 0; border: none;">
<svg width="16" height="16">...</svg>
</button>
<!-- Good: Target is 32x32 due to padding, satisfying WCAG 2.2 -->
<button style="padding: 8px; border: none;">
<svg width="16" height="16">...</svg>
</button>2. Non-text Contrast (Criterion 1.4.11)
The Rule: The visual presentation of user interface components and graphical objects must have a contrast ratio of at least 3:1 against adjacent colors.
How it affects SVGs:
Your icon color cannot be a light, low-contrast gray (#cbd5e1) on a white background (#ffffff). You must ensure the path’s fill or stroke meets the 3:1 ratio.
Furthermore, if the icon represents a state change (like a checkbox or a toggle), the difference between the “on” and “off” states must be discernible to users with low vision.
3. Text Alternatives (Criterion 1.1.1)
The Rule: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
How it affects SVGs: You must categorize every SVG icon in your codebase as either Decorative or Functional/Informative.
Decorative Icons
If the icon is purely visual candy (like an arrow next to a “Read More” text link), it must be hidden from screen readers to reduce noise.
<a href="/post">
Read More
<svg aria-hidden="true" focusable="false">...</svg>
</a>(Note: focusable="false" fixes an old IE11 bug, still good practice if supporting legacy).
Functional Icons
If the icon stands alone as a button (e.g., a magnifying glass for search), it must have an accessible name. Do not rely on <title> tags inside the SVG, as screen reader support is notoriously inconsistent.
The best practice is using aria-label or visually hidden text.
<!-- Method 1: aria-label on the interactive wrapper -->
<button aria-label="Search site">
<svg aria-hidden="true">...</svg>
</button>
<!-- Method 2: Visually hidden text (often preferred for robust translation support) -->
<button>
<span class="sr-only">Search site</span>
<svg aria-hidden="true">...</svg>
</button>4. Focus Visible (Criterion 2.4.7)
The Rule: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
How it affects SVGs:
If your SVG is part of a button or link, you must ensure a clear focus ring appears when navigating via the Tab key. Never set outline: none on interactive elements without providing an alternative focus style (like box-shadow or an animated SVG stroke).
.icon-button:focus-visible {
outline: 2px solid #2563eb;
outline-offset: 4px;
}Summary
Accessibility is not a bolt-on feature; it starts in the design phase and is enforced in code. By ensuring your interactive SVG targets are at least 24x24px, maintaining a 3:1 contrast ratio, and correctly handling aria-hidden, you guarantee your interface is compliant with WCAG 2.2 and usable by everyone.