Skip to content

Infographics

Infographics should be informative, engaging, and accessible

Version:
0.1.0
Status:
Draft

Introduction

Visual and figurative representations of information can help readers to quickly grasp the salient points. However, without careful and deliberate design they can be confusing, or even misleading.

The visual design and labeling of infographics (or 'visualisations') is covered comprehensively in GEL. As a complement to the GEL documentation, here we shall explore two topics:

  1. The technical accessibility requirements of different types of infographic
  2. Alternative and complementary means of consuming the same data/information, provided to uphold the Offer choice[1] inclusive design principle

How you encode infographics, and what kind of textual alternatives you provide for them, depends heavily on the nature of the infographic in question. However, it is highly recommended the SVG image format encodes the graphic itself. SVG:

  • Is scalable without degradation, facilitating zoom/magnification.
  • Can be highly optimized, especially when using the simple shapes and paths recommended
  • Can be maintained and updated easily, like any other markup.
  • Unlike runtime-dependent <canvas> graphics, can contain accessibility information, and be downloaded as a self-contained asset.

Inline SVG (SVG embedded directly into the HTML) is the most malleable, since you can target individual SVG elements/artefacts with CSS and JavaScript. Embedding SVG also reduces http requests and, most importantly, content reflows[2], by loading and rendering along with the surrounding content.

Labels and descriptions

Every infographic should be provided with alternative text[3] to describe it to the visually impaired. In addition, some infographics should be accompanied by a caption. The role of the alternative text and the role of the caption are distinct. The alternative text describes, and the caption explains:

  • Alternative text: Describes what is in the infographic; a literal interpretation of its form
  • Caption: Explains what the infographic says; an editorial summary of its salient points

While the alternative text, describing the image non-visually, should be invisible, the caption should be visible and available to all consumers of the information. Contrary to some misconceptions, a caption (provided as a <figcaption> in the code example to come) is not a replacement for alternative text.

Consider the following, very simple visualization.

Here is how one would mark it up, and might provide alternative text and a caption (with notes to follow):

<figure>
  <svg focusable="false" role="img" aria-label="Two white circles with black borders. The left circle, labelled 'three weeks', contains a number of smaller black circles, clustered around the bottom left corner. The right circle, labelled 'six weeks', contains additional, smaller black circles, spreading out from the bottom left corner" aria-describedby="figure-1">
    ...
  </svg>
  <figcaption id="figure-1">
    After three weeks, some cultures had emerged, localized towards one side. By the six week mark, these had begun to multiply and spread towards other areas of the cell-culture dish.
  </figure>
</figure>
  • role="img": This ARIA attribute tells browsers to communicate to assistive technologies that the <svg> is a simple image element, and announce it as such.
  • aria-label: SVG does not support alt, so the alternative text is provided with the aria-label property.
  • aria-describedby: The <figure> should be identified by role, and its <figcaption> used to label it. However, this is not consistent or dependable across different screen reader software[4]. Accordingly, aria-describedy (pointing to the <figcaption>'s id) is used to associate the caption with the image directly. In most screen readers, the ARIA description is read after the label, with a pause to separate each of these announcements.
  • focusable="false": As in all cases where inline SVG is employed, focusable="false" prevents older versions of Internet Explorer and Edge from placing the (non-interactive) SVG erroneously in keyboard focus order.

Charts, graphs, and tabular data

Multi-dimensional data that can be represented as a chart or graph should also be provided as a data table. By offering different means to consume the information[1:1], you meet different needs and cater for different abilities. Not only will different people have format and presentation preferences, but any one person may simultaneously find interest in the graphical presentation and utility in the raw data.

Consider the following infographic, which charts cellular growth, but categorized by the morphology of the individual cultures.

The source data can be presented in tabular form, using a table component:

Cell culture morphology over time
Weeks Circular Irregular Rhizoid Total
Week 1 7 5 0 12
Week 2 10 10 0 20
Week 3 14 14 0 28
Week 4 14 16 12 42
Week 5 14 18 16 48
Week 6 14 22 17 53

With a data table providing an interface for the granular inspection of the data, it's no longer necessary to clumsily cram all those numbers into the alternative text of the infographic. Instead, we can just describe how the data is presented: "Bar chart. Each bar represents a successive week in the cell growth period. The y axis is labelled 'total cell cultures'. Individual bars are divided proportionally into the different culture morphologies present: circular, irregular, and rhizoid". However, a caption should be provided to editorialize the data, and identify any key trends.

What remains is to piece all of these pieces together, and provide an interface for switching between the infographic and table views. A tab interface is well suited for this. Here's a demo, with the caption included:

Circular and irregular cultures begin to emerge immediately, with rhizoid cultures joining them in the fourth week. No additional circular cultures appear after the third week.
Cell culture morphology over time
Weeks Circular Irregular Rhizoid Total
Week 1 7 5 0 12
Week 2 10 10 0 20
Week 3 14 14 0 28
Week 4 14 16 12 42
Week 5 14 18 16 48
Week 6 14 22 17 53

Colour concerns

It's recommended that colour is only added to your infographics as a progressive enhancement. Design it monochrome to begin with, and only add colour where desirable. This way, you'll end up with a chart that is decipherable even on non-colour displays and among people with colour perception impairments.

The previous example is not dependent on colour since each cell culture morphology can be identified with a distinct shape. Where illustrative symbols are not appropriate, or there is no room to display them at a reasonable size, it is recommended colour differentiation is supplemented by pattern differentiation.

Using CSS linear-gradient and a translucent RGBA colour value, four colours can become four coloured patterns:

.red {
  background-color: red;
  background-image: 
  repeating-linear-gradient(
    /* stripes from left to right */
    0deg,
    rgba(0,0,0,0.2),
    rgba(0,0,0,0.2) 0.25rem,
    transparent 0.25rem,
    transparent 0.5rem
  );
}

.green {
  background-color: green;
  background-image: 
  repeating-linear-gradient(
    /* stripes from top to bottom */
    90deg,
    rgba(0,0,0,0.2),
    rgba(0,0,0,0.2) 0.25rem,
    transparent 0.25rem,
    transparent 0.5rem
  );
}

.blue {
  background-color: blue;
  background-image: 
  repeating-linear-gradient(
    /* diagonal stripes from top-left to bottom-right */
    45deg,
    rgba(0,0,0,0.2),
    rgba(0,0,0,0.2) 0.25rem,
    transparent 0.25rem,
    transparent 0.5rem
  );
}

.yellow {
  background-color: yellow;
  background-image: 
  repeating-linear-gradient(
    /* diagonal stripes from top-right to bottom-left */
    -45deg,
    rgba(0,0,0,0.2),
    rgba(0,0,0,0.2) 0.25rem,
    transparent 0.25rem,
    transparent 0.5rem
  );
}

Bad example

An infographic key that depends on flat colours would fail WCAG 2.1 1.4.1: Use of color[5]

Four coloured boxes: red, green, blue, yellow

Good example

Four coloured boxes: red, green, blue, yellow. All with stripes of different orientations to distinguish them better

It is possible to use focus management and ARIA attribution[6] to make (SVG-based) interactive visualisations technically accessible. However, this is an ambitious undertaking. In addition, sighted screen reader users are liable to be confused by what appears to be a graph being announced (and behaving) as a table or other semantic structure.

In most cases, you should avoid creating interactive visualisations, and instead use the recommended combination of alternative text, caption, and supplementary data table/source.

Reference implementation

The implementation included in the Recommended layout section is available to explore (and test) in it's own window.

Open in new window

This topic does not yet have any related research available.

Further reading, elsewhere on the Web


  1. Offer choice — Inclusive Design Principles, https://inclusivedesignprinciples.org/#offer-choice ↩︎ ↩︎

  2. Preventing Content Rflows from Lazy-Loaded Images — CSS-Tricks, https://css-tricks.com/preventing-content-reflow-from-lazy-loaded-images/ ↩︎

  3. HTML5: Techniques for providing useful text alternatives — W3C, https://w3c.github.io/alt-techniques/with-pictures.html ↩︎

  4. How do you figure? — Scott O'Hara, https://www.scottohara.me/blog/2019/01/21/how-do-you-figure.html ↩︎

  5. WCAG2.1 1.4.1: Use Of Color, https://www.w3.org/TR/WCAG21/#x1-4-1-use-of-color ↩︎

  6. Accessible SVG Line Graphs, https://tink.uk/accessible-svg-line-graphs/ ↩︎

Copyright © 2019 BBC. This content is published under the Open Government Licence, unless otherwise noted.

Got a minute?

We'd love to know what you think of our website.

Go to survey