1. Home
  2. SiteLint
  3. Accessibility Rules
  4. accessible-svg


Print this article


The rule determines if the svg have an accessible description.


Making accessible and cross-browser compatible svg is a challenge. It may convey information’s or be purely decorative. Here we are checking if in any way founded svg is accessible.

How to fix it

  • Including an <svg> title and description
    <svg xmlns="" version="1.1" viewBox="0 0 400 200" aria-labelledby="title description">
      <title id="title">Example title</title>
      <desc id="description">Example description</desc>
  • If the svg is purely decorative add aria-hidden="true" and eventually focusable="false" (see notes about limitations).
    Example code for decorative svg
    <svg xmlns="" version="1.1" viewBox="0 0 400 200" aria-hidden="true">

Why do inline <svg> elements in IE and Edge cause tab-ordering issues?

Note about focusable attribute: inline <svg> elements in Internet Explorer and Edge up to 13 are focusable by default, which may cause tab-ordering issues. For example, if a link or button has an <svg> icon, the user must click tab twice to move focus to the next element, as pressing tab instead moves focus to the <svg> element. If supports for IE or Edge up to 13 is not required, the focusable attribute can be safely omitted.

Example code with support for IE browser
<a href="">
  <svg xmlns="" version="1.1" viewBox="0 0 400 200" aria-hidden="true" focusable="false"></svg>

What’s the best approach for embedding SVGs in HTML, and when should I use the <img> element instead?

Embed the <svg> markup directly in the HTML document, as it exposes the <svg> DOM structure to assistive technologies. The <img> HTML element should only be used for <svg> that do not require user interaction and do not contain any dynamic components (scripting or animation).


Accessibility, WCAG 2.1

Was this article helpful to you? No Yes

How can we help?