SiteLint documentation and guidelines

Missing accessible name for the SVG content

Description

Rule id: accessible-svg.

The rule determines if the svg has an accessible description.

Context

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="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 400 200" aria-labelledby="title description">
  <title id="title">Example title</title>
  <desc id="description">Example description</desc>
</svg>
  • 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="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 400 200" aria-hidden="true">
</svg>

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="https://www.example.com">
  <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 400 200" aria-hidden="true" focusable="false"></svg>
</a>

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).

Standard

Accessibility, WCAG 2.1