Accessible Graphics within Scalable Vector Graphics (SVG)

Overview

In this lesson, you will learn how to make Scalable Vector Graphics (SVGs) accessible to assistive technologies. Whereas canvas-based drawings rely on pixel rendering, SVGs on the web are part of the DOM and can carry semantic information directly. Titles, descriptions, and even ARIA attributes can be embedded within an SVG, which means the approach to make SVGs accessible is different compared to a canvas. However, SVGs do not allow you to control the rendering pipeline and this has pros and cons. In this lesson, you will consider accessible graphics within the context of SVGs.

Goals

You have the following goals for this lesson:

• Understand the difference between using <img> tags and inline <svg> for accessible graphics
• Learn how to add meaningful text alternatives using <title>, <desc>, and alt attributes
• Recognize common accessibility pitfalls when working with SVGs in interfaces and visualizations
• Learn how to apply ARIA attributes to enhance the accessibility of complex SVGs

Warm up

Think about how web pages are built. There are headings that give structure, landmarks that define regions, and buttons that announce their purpose. Now imagine drawing an entire interface using only SVG shapes. Buttons might be circles, rectangles could make up menus, and fancy paths could be icons. How might such an approach differ compared to rendering in a canvas?

Vocabulary

You will be learning about the following vocabulary words:

Web Content Accessibility Standards

This lesson covers the following standards:

• WCAG 2.2 - 1.1.1 Non-text content
• WCAG 2.2 - 1.3.1 Info and Relationships
• WCAG 2.2 - 2.1.1 Keyboard
• WCAG 2.2 - 4.1.2 Name, Role, Value

Explore

Accessible graphics are an essential part of creating an inclusive digital experience. Visual content such as icons, diagrams, and data visualizations often convey meaning that all users should be able to interpret. However without alt text or proper semantic labeling these visuals can be invisible or useless to users who rely on certain assistive technologies. More importantly, alternative description becomes increasingly problematic as graphics become more complex. Ultimately, graphics like charts or visualization need interactivity to make them accessible.

Scalable Vector Graphics (SVGs) offer a unique advantage when it comes to visual content. Unlike other common image formats that store information for every pixel, SVGs instead use mathematical formulas to describe lines and shapes. The data of an SVG is in text-based format that makes it both machine readable and human readable. Because of this, SVGs can be embedded directly into the structure of a web page along with semantic elements and accessible names.

It is important to contrast using SVGs with drawing graphics using the canvas element. A canvas allows for complex and high performance graphics but alone is not accessible. SVGs can be inherently part of the DOM and carry semantic information within its tags at the cost of lower performance for more complex graphics. However, they give you far less control. It is important to grasp that one is not better than the other and they are used for different purposes.

Using SVGs

There are two main ways to use SVGs in a web page. One way is using the <img> tag. Using an SVG as an image source works just like using a PNG or JPEG.

<img src='icon.svg' alt='Search Icon'>

When used this way the image can get an alt tag which makes it no more or less accessible like a regular image. You still get the benefit of the smoothness of SVGs since they are still calculated using mathematical formulas, but you do not have access to the internal SVGs elements. For simple or decorative images this way can be fine but so more complex images that need more markup you will have to embed the SVG inline. Take this example SVG:

<svg viewBox='0 0 20 20' role='img' aria-labelledby='title1'>
    <title id='title1'>Search icon</title>
    <circle cx='10' cy='10' r='8' fill='blue'/>
</svg>

If this is added directly into HTML then you gain full control over the structure and accessibility. You can add ARIA attributes and roles, and even label individual shapes or groups. And being part of the DOM also means you can use Cascading Style Sheets (CSS) or other tools (e.g., tailwind) to animate SVGs and Javascript to add additional functionality. Put another way, embedding and adding some tags can dramatically increase flexibility with accessibility systems.

Providing an Accessible Name

The SVG standard also includes two tags that add accessibility information. There is the <title> tag and the <desc> tag. The <title> tag is the accessible name of a given SVG or container SVG element. Think of the <title> tag as an equivalent to 'aria-label' but instead of an attribute it is also its own element in the structure. SVG renders also add a tooltip to elements of an SVG with a <title> so adding this tag not only adds accessibility but another visual element to enhance the graphic. The <desc> tag is for longer explanations or information for a given SVG element. Note that descriptions are supported across most browsers but not all screen readers consistently announce descriptions.

Here is an example SVG with titles and descriptions:

<svg width='150' height='300' viewBox="0 0 150 300" role="img" aria-labelledby="svgTitle svgDesc">
    <title id="svgTitle">Three Stack</title>
    <desc id="svgDesc">Three vertical rectangles labeled as First, Second, and Third section from top to bottom.</desc>

    <!-- First rectangle -->
    <g>
      <title>First section</title>
      <rect x="25" y="10" width="100" height="80" fill="#4A90E2" />
    </g>

    <!-- Second rectangle -->
    <g>
      <title>Second section</title>
      <rect x="25" y="110" width="100" height="80" fill="#50E3C2" />
    </g>

    <!-- Third rectangle -->
    <g>
      <title>Third section</title>
      <desc>This happens to be the last rectangle</desc>
      <rect x="25" y="210" width="100" height="80" fill="#B8E986" />
    </g>
</svg>

Another note about the <title> tag is that an element can only have a single <title>. Additional ones will be ignored. The entire SVG can have a title but for more than one title in one SVG each title needs to be nested within an element and one of the most common is the <g> tag, which groups elements together.

Compared to canvas-based drawings, SVG offers a significant advantage when it comes to structure. The graphics are inherently part of the DOM and can be described semantically. The <g> enhances this by allowing you to individual shapes like a <circle> or <path>, many graphics are composed of multiple elements representing a single concept. Grouping shapes with the <g> enables you manipulate or animate them as a single unit. By adding ARIA within the groups and structure of an SVG you can make complex visual structures more understandable and navigable for assistive technologies.

Adding Additional Functionality

As mentioned earlier in this lesson, SVGs embedded inline are part of the DOM. While SVGs are primarily for visual graphics it is important to understand the power of being part of the DOM. SVGs can be styled, scripted, and made interactive just like any other HTML element. And one of the most important ways you can enhance interactions is by making SVG elements focusable. Being focusable means a keyboard user can directly navigate to the element and easily find the added accessibility information.

By default, most SVG elements are not focusable. If you want an SVG element to be navigated to via the Tab key, you explicitly set the 'tabindex' attribute. Take this example SVG:

<svg viewbox="0 0 100 100">
    <g role="button" tabindex="0" aria-label="Zoom In">
      <circle cx="50" cy="50" r="40" fill="#4A90E2" />
      <text x="50" y="55" text-anchor="middle" fill="white" font-size="20">+</text>
    </g>
</svg>

This example SVG acts like a button and has the attribute tabindex set to 0. This means this element is now added to the tab order and if a keyboard user is navigating the page the Tab key will stop them here and announce that there is a button labeled 'Zoom In'. With the use of JavaScript and CSS you can also:

• Respond to keyboard events like 'Enter', 'Space', or the arrow keys.
• Be styled with on focus states to show visible indicators.
• Have ARIA roles, properties, and states, as if they were a standard control like buttons, checkboxes, and even links.

Note that when using tabindex there is a risk of clutter. Having too many focusable elements using tabindex='0' can overload the tab order and make navigating through a page linearly a pain. If you are using more interactive ARIA roles like 'button' you need to make sure you provide accessible names and interaction for full semantic support.

Charts

As one final note, consider that very complex SVGs, like charts or visualization, will require external JavaScript to control them. Take this bar chart that was generated using the Quorum Charts library:

This chart is embedded directly into this page and along with that there is additional scripting added to the SVG and the page that allows more controlled navigation within the chart.

This accessible SVG goes beyond adding simple text descriptions. There is a meaningful structure and navigation added to help all users interpret the chart. You can attempt to use the keyboard to navigate through the chart yourself and you can inspect the source code of the SVG to see the addition of aria-label for many objects found on the chart.

The navigation of the chart is also not exactly linear. While you can get into the chart and navigate it bar by bar, the navigation was designed to split the chart into several interactive regions such as the x-axis, y-axis, and the main chart region. You can then press the Enter key to dig down into each section and find the minute details. A focus indicator also appears to show the user what part of the chart is being focused. This layered approach ensures that the chart is not only visible but accessible to all users.

The other neat thing about the generated chart SVG is that all of the extra scripting and labels were not added to this specific chart after the fact. The Quorum library auto-generates the extra semantics for you. To learn more about these charts or how to make one of your own you can view that tutorial here.

Engage

In this activity, you are going to practice making SVG graphics accessible by applying a semantic structure. You will label parts of a graphic, group related shapes, and use ARIA attributes to improve screen reader understanding. The goal is not just to mark things up, but to think carefully about how a graphic communicates meaning and how you can make that meaning available to users who can not see it.

For this exercise, you may not rely on pre-written accessibility markup or tooling to do the work for you. You are going to write the structure and labels yourself, using what you have learned.

Directions

Do the following for this exercise:

Pick a Chart: Each group will receive a screenshot of a simple chart or graphic. You will not receive the SVG code, just the image. Remember that although images can be considered accessible with a simple alt tag, some graphics are complex enough that one tag simply is not enough.

• Bar Chart
• Histogram
• Line Chart
• Box Plot
• Violin Plot

Build the Structure: Using your understanding of SVG and accessibility, write the structure of an accessible inline SVG that would match the screenshot. Focus on:

• Grouping related elements using <g>
• Providing labels with <title> or aria-label
• Using role='img' or role='group' appropriately

You do not need to recreate the visual details, but you do need to represent the structure that makes the graphic understandable.

Swap with Another Group: Exchange your screenshot and your proposed markup with another group. They will review your markup and:

• Evaluate whether the labels are clear and meaningful
• Check whether the grouping matches what is visually apparent
• Identify any missing semantics or unnecessary verbosity

After reviewing each other's work, come back together and discuss:

• Was it easy or difficult to decide what counted as a 'group'?
• How much context did you feel needed to be included in a <desc>?
• What decisions did you make about focusability or interactivity?
• If you had to rely on a screen reader to understand this graphic, would your markup work?

End of Lesson

You have reached the end of the lesson for Technical Accessibility. To view more tutorials, press the button below or you can go back to the previous lesson pages.