Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 3 Next »

SVGs

Scalable Vector Graphics (SVG) are vector-based graphics, defined in XML and supported by most modern browsers. They are created with graphic software such as Adobe Illustrator and can be edited with a text editor. SVGs are built from vector shapes, images and text objects, and can be interactive and dynamic. SVGs look good on any device and are optimal for responsive design due to being resolution independent with seamless scaling.

SVGs aid in the accessibility of graphics on the web by benefitting users who may utilize assistive technologies or experience color blindness. SVGs increase the usability of content for all users across all media devices. There are some challenges. Screen readers can interpret SVGs differently and some browsers have issues with animation.

Summary

SVG as img src

  • All SVG <img> elements SHOULD be set to role="img".
  • All informative or actionable SVG <img> elements MUST have meaningful, concise alternative text (via alt, aria-label, or aria-labelledby).

Inline SVGs

  • All <svg> elements MUST be set to role="img".
  • All informative or actionable <svg> elements MUST have meaningful, concise alternative text (via <title>element).
  • The alternative text (<title>) of an <svg> element MUST be programmatically associated with the <svg> element via aria-labelledby.
  • All text within the image that needs to be spoken by a screen reader MUST be associated with the <svg> element using aria-labelledby.
  • The total number of characters of alt text associated with the <svg> element SHOULD NOT exceed 250 characters.

Complex Alternative Text

  • Complex <svg> images MUST have meaningful, concise alternative text AND MUST have a more complete long description.
  • A <desc> element MUST be used to provide a detailed description of a complex <svg> if it is not provided in any other way.
  • The <desc> attribute of an <svg> element MUST be programmatically associated with the <svg> element (via aria-labelledby).

Text in SVGs

  • Text within <svg> elements SHOULD be eliminated OR SHOULD be kept to a minimum.
  • All <text> elements inside <svg> elements MUST be referenced in the alternative text of the <svg> element, or in a long description.

SVG Color Contrast

  • SVG images SHOULD include a base background color behind the important parts of the image, at a minimum.
  • SVG images SHOULD be styled to ensure compatibility with Windows High Contrast Mode

Animated SVGs

  • SVG animations SHOULD use JavaScript, rather than the <animate> element.
  • SVG animations MUST not flash or blink at a rate of 3 times per second or more.
  • SVG animations MUST NOT auto-play for more than 5 seconds.
  • SVG animations MUST allow users to pause the animation.
  • SVG animations SHOULD NOT distract the user from the main purpose of the web content.

Interactive SVGs

  • Interactive <svg> objects MUST be fully keyboard-accessible.
  • Interactive <svg> objects MUST be fully touchscreen-accessible.
  • Interactive <svg> objects MUST communicate the applicable name, role, and value of controls, events, and semantic elements within the <svg> object.

Embedding SVGs

There are several ways to add an SVG into an application:

  1. Embed the SVG by using the <img> tag and reference the source.
  2. Embed the SVG directly into code, using the <svg> element.
  3. Embed the SVG in an <iframe> or <embed> tag, or referenced as the data attribute through an <object>.

It is recommended to either utilize the <img> tag or <svg> element when embedding SVGs. It is not recommended to utilize the <iframe>, <embed> or <object> elements due to poor support by assistive technologies.

SVGs as Image

Benefits of utilizing the <img> tag:

  • The code file size will be smaller than embedding the <svg> element inline.
  • The image can be cached by the browser.

Challenges of utilizing the <img> tag:

  • JavaScript and CSS cannot be applied to the <svg> contents to animate or manipulate images.
  • The SVG source is not directly available in the DOM and may provide less predictable results for assistive technologies if the image is complex.

Example - reference the SVG in the src of an img

<img src="somesvg.svg">

Suggested - All SVG <img> elements SHOULD be set to role="img".

To ensure the widest range of assistive technologies recognize the SVG as an image, add role="img" to the <img>element.

<img src="somesvg.svg" role="img">

Required - All SVG <img> elements MUST have meaningful, concise alternative text (via alt, aria-label, or aria-labelledby).

When adding an SVG element via an <img> element, it is important to add concise, meaningful alternative text via alt, aria-label, or aria-labelledby attributes within the <img> element. The content of the alternative text is determined the same way it is for any <img> element, in the sense that the purpose or meaning of the element should be described by the alternative text.

Good Example: Using alt to provide alternative text.

<img src="somesvg.svg" role="img" alt="a concise description of the image">

Good Example: Using aria-label to provide alternative text.

<img src="somesvg.svg" role="img" aria-label="a concise description of the image">

Good Example: Using aria-labelledby to provide alternative text.

<p id="caption1">This is a caption above an image</p>
<img src="somesvg.svg" role="img" aria-labelledby="caption1">

SVGs as Inline

Benefits of utilizing the <svg> tag:

  • JavaScript and CSS can be applied to the <svg> contents to animate or manipulate the image.

Challenges of utilizing the <svg> tag:

  • Assistive technology support is not consistent..
  • Increased code size.
  • Cannot be cached.

Example - embedding SVG inline

<html>
   <body>
      <svg></svg>
   </body>
</html>

Required - All <svg> elements MUST be set to role="img".

Add role="img" to the <svg> element to ensure recognition across the widest range of assistive technologies.

<svg role="img">

Required - All informative or actionable <svg> elements MUST have meaningful alternative text (via the <title> element).

Add concise, meaningful alternative text via the <title> element of the <svg>. The content of the alternative text must describe the purpose or meaning of the image.

The <title> needs to be the first-child of its parent element. This is pertinent because an <svg> element can have multiple titles, depending on whether it contains multiple containers (or groupings) of graphical elements.

Good Example: Using the <title> as an equivalent for alternative text.

In the example below, the <title> contains the same text as the caption of the chart and serves as the concise text alternative for the image.

<svg role="img"> 
<title>Good Equivalent for Alternative Text</title>

Required - The alternative text (<title>) of an <svg> element MUST be programmatically associated with the <svg> element via aria-labelledby.

The challenge with <title> alone is that not all browsers expose <title> through the Accessible API and not all screen readers actually make use of it. Most modern browsers offer full support of ARIA so by adding the aria-labelledby attribute in the <svg> tag and then tying it directly to the <title> will now make use of the information based on the ARIA attribute.

Good Example: Using aria-labelledby to help expose the <title> element to browsers.

<svg role="img" aria-labelledby="svgTitle">
<title id="svgTitle">Good Equivalent for Alternative Text</title>

Required - The <desc> attribute of an <svg> element MUST be programmatically associated with the <svg> element (via aria-labelledby).

The challenge with <desc> is that not all browsers expose this information through the Accessible API and not all screen readers actually make use of it. Most modern browsers offer full support of ARIA so by adding the aria-labelledby attribute in the <svg> tag and then tying it directly to the <desc> will now make use of the information based on the ARIA attribute.

Good Example: Using aria-labelledby to help expose information to Browsers.

<svg role="img" aria-labelledby="svgTitle svgDescription"> 
   <title id="svgTitle">Good Equivalent for Alternative Text</title>
   <desc id="svgDescription">This is the description of the Good Equivalent for Alternative Text.</desc>
</svg>

Suggested - Text within <svg> elements SHOULD be eliminated OR SHOULD be kept to a minimum.

Text within <svg> elements remains crisp and readable no matter the size. The challenge is that when used as alternative text, screen readers will treat all of the <text> elements as one continuous string of text, which can be confusing if the <text> elements are meant to identify separate parts of the image, or if they are not meant to be read together as a single string of text.

The recommendation is to limit the amount of text in an <svg> element to only the essential items or eliminate it altogether. If possible, place the text outside of the <svg> element, in the regular flow of the HTML document.

Required - If <text> elements are needed inside <svg> elements, they MUST be referenced in the alternative text of the <svg> element, or in a long description.

If an SVG contains text that must be spoken by a screen reader and is not already included in the <title> or <desc>elements, it must be associated with the <svg> element using aria-labelledby.

There is a challenge with <text> elements. If <title> or role="img" is not added to an <svg> element, some screen readers will ignore that it is <svg> and read the text within it. Behavior of screen readers are not consistent so the results are not consistent. The <title> element is essentially a requirement, but won't be recognized by all screen readers unless you also add role="img". Once you add both <title> and role="img", the behavior of screen readers changes. Instead of treating the <text> element as text, screen readers treat the <svg> element as an image, and they ignore the <text>element inside. Until screen readers are consistent with <svg> elements, it is recommend to ensure that all informative text within the <svg> element is referenced via aria-labelledby.

Note: If some of the text in the <svg> element would not make sense as part of the alternative text, do not reference it via aria-labelledby.

Good Example: Using aria-labelledby to associate text with the <svg> element.

<svg role="img" aria-labelledby="svgTitle svgDescription objectDescription"> 
   <title id="svgTitle">Good Equivalent for Alternative Text</title>
   <desc id="svgDescription">This is the description of the Good Equivalent for Alternative Text.</desc>
   <g id="objectDescription">
      <rect x="100" y="00" width="100" height="100"></rect>
      <text>This is the description of the text of the object for Good Equivalent for Alternative Text.</text>
   </g>
</svg>

Required - Complex <svg> images MUST have meaningful, concise alternative text AND MUST have a more complete long description.

Users who are blind will struggle to understand complex graphics unless a detailed text description is provided. If 250 characters or so is insufficient to describe an image, you must use another method.

There are several ways of providing a long description for SVGs:

  1. Provide the long description in the context of the HTML document itself.
  2. Provide a button that expands a collapsed region that contains the long description.
  3. Provide a button to open a dialog that contains the long description.
  4. Provide a link to a long description on another page via a normal link text.

Suggested - The length of all associated alternative text (including <title> and <desc>) for the <svg> element SHOULD be concise (no more than about 250 characters).

The total number of characters in the alternative text referenced by the aria-labelledby attribute, including both the <title> and <desc> elements is more than 250 characters, other methods should be used.

As discussed previously, there is no technical limit nor policy restriction on the length of alternative text, but the alternative text is not as usable as regular text for several reasons:

  • Screen readers read the entire string of text at one time, and users cannot resume where they left off if they pause while in the middle of reading the alternative text.
  • Screen reader users cannot navigate the text (e.g. by word, character, etc.).

If more text is required to describe the image in a meaningful way, consider using one of the following techniques for complex images that makes the content available to all users:

  1. Provide the long description in the context of the HTML document itself.
  2. Provide a button that expands a collapsed region that contains the long description.
  3. Provide a button to open a dialog that contains the long description.
  4. Provide a link to a long description on another page via a normal link text.

SVG Color Contrast

Suggested - SVG images SHOULD include a base background color behind the important parts of the image, at a minimum.

If an SVG image does not have a background color set, the background color of the image itself will change when the user switches into Windows High Contrast Mode. That may or may not be a problem for a given image, but if large portions of the SVG image are transparent, and if they depend on a particular background color on the web page to look correct, the SVG image will probably be difficult to discern when the background color changes.

Note: It is not necessary to completely fill the background rectangle of an SVG image. Parts of the SVG image can remain transparent as long as there are no transparent parts within the SVG that would cause the image to become difficult to understand if those colors were to change. For example, if the assumption is that the background color of the page is white, and if parts of the SVG image are white only because the color of the web page is showing through, those parts of the image will turn black if the user switches to Windows High Contrast Mode with a black background.

The background fill can be any shape, as long as it fills in the important parts of the image.

Suggested - SVG images SHOULD be styled to ensure compatibility with Windows High Contrast Mode

SVG images will retain their colors when the user switches into Windows High Contrast Mode.

Some SVG images will naturally look fine in Windows High Contrast Mode, so there is no need to create specific styles for them. In other cases, SVG images will not have the proper contrast in comparison with the background. This is especially true when CSS is used to style SVG image components. Windows High Contrast Mode overrides CSS colors, which can drastically change the look of the image (as well as the entire page around the image).

If the SVG image is problematic in Windows High Contrast Mode, one solution is to detect when Windows High Contrast Mode is being used and customize the styling of the SVG image accordingly. There are two basic approaches to detecting Windows High Contrast Mode:

  • Use proprietary CSS media queries (Edge and Internet Explorer only)
  • Use JavaScript to detect user-initiated changes to colors (the changes may be at the browser level or at the operating system level)

JavaScript tests are required for browsers other than Edge and Internet Explorer. This method can be more robust than the media detection method mentioned above and can take into account other high contrast software or user-specific styles.

Good Example: Media queries for common Windows High Contrast Mode themes

This method will work in Edge and Internet Explorer, but not in other browsers.

/* Styles for all high contrast modes: */
@media screen and (-ms-high-contrast: active) { }

/* Styles for the Windows "High Contrast Black" theme: */
@media screen and (-ms-high-contrast: white-on-black) { }

/* Styles for the windows "High Contrast White" theme: */
@media screen and (-ms-high-contrast: black-on-white) { }

Animated SVGs

The Benefits of Animated SVG Over Flash

An advantage that SVG animation has over alternatives like Silverlight and Flash is that SVG does not rely on a plug-in to work. Support for <svg> is better than support for Silverlight and Flash on mobile platforms.

Suggested - SVG animations SHOULD use JavaScript, rather than the <animate>element.

Animation could be as simple as changing styles or color, or complex with geometry transformations or showing/hiding sections of SVGs.The acceptable methods to accomplish animation are declarative by using Synchronized Multimedia Integration Language (SMIL) or Cascading Style Sheets (CSS), or through JavaScript DOM manipulation.

SMIL can be used to create animations without the use of CSS or JavaScript, but there is one major challenge, Internet Explorer does not offer support for SMIL. Internet Explorer will not render animation but it will render the final state of the image. As long as the other methods of creating the SVG in an accessible manner are followed, this should not be an issue from an accessibility standpoint.

Required - SVG animations MUST not flash or blink at a rate of 3 times per second or more.

Flashing or blinking content runs the risk of causing a seizure in some individuals.

Required - SVG animations MUST NOT auto-play for more than 5 seconds.

It is best if the animation does not play at all until the user activates the animation. As a compromise, the WCAG 2.0 guidelines allow the animation to auto-play for up to 5 seconds.

Required - SVG animations MUST allow users to pause the animation.

An animation that cannot be paused can be immensely distracting, especially for people with attention deficit disorder, or some kinds of cognitive disabilities.

Suggested - SVG animations SHOULD NOT distract the user from the main purpose of the web content.

Remember that just because you can technically do something, it doesn't necessarily mean you should. Generally speaking, the animation should serve a specific purpose, rather than simply adding movement to a static page.

Interactive SVGs

Required - Interactive <svg> objects MUST be fully keyboard-accessible.

Highlights of what it means to be fully keyboard-accessible include the following:

  • All links, buttons and controls must be keyboard-focusable and usable by keyboard users.
  • All focusable elements must have a visible focus indicator.
  • The scripting must manage the focus when activating, deactivating, and/or dismissing features (like dialogs, menus, etc.); the focus must be sent to the proper place at the proper time.
  • The <svg> object must not trap the keyboard focus.
  • The tab order (or arrow key order, if appropriate) must be logical.
  • All focusable elements must be visible on the screen (or become visible once focus lands on them).

Required - Interactive <svg> objects MUST be fully touchscreen-accessible.

Highlights of what it means to be fully touchscreen-accessible include the following:

  • All mouse-only actions have a touch equivalent action.
  • All keyboard-only actions have a touch equivalent action.
  • All gesture-dependent actions have an equivalent non-gesture method to achieve the same result (this rule exists because screen readers override and disable page-specific gestures in most cases; a click action is best for touchscreens).

Required - Interactive <svg> objects MUST communicate the applicable name, role, and value of controls, events, and semantic elements within the <svg>object.

Interactive <svg> objects must abide by the same types of accessibility principles that govern the use of custom ARIA widgets. Interactive <svg> objects may be coded as a custom ARIA widget. Button, checkbox, tablist, and others can be added to elements within ARIA widgets.

That said, support for interactive SVG, even when combined with ARIA, is sometimes spotty and must be tested thoroughly with screen readers before going live.

Code Example

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<?xml-stylesheet type="text/css" href="../css/style.css"?> /* Connect to external styles sheet - if needed */
<svg role="img" /* required */
      viewBox=" /* four numbers specific to file - required */" 
      class="" /* if needed */
      id="" /* if needed */
      aria-labelledby="sampleTitle sampleDesc" /* required */
      xmlns="http://www.w3.org/2000/svg" version="1.1" >
   <title id="sampleTitle">Sample Title</title> /* required */
   <desc id="sampleDesc">This is a sample description.</desc> /* if needed */
   /* svg elements would list here */
</svg>
  • No labels