Infographics
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:
- The technical accessibility requirements of different types of infographic
- Alternative and complementary means of consuming the same data/information, provided to uphold the Offer choice[1] inclusive design principle
Recommended markup
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 visualisation.
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 supportalt, so the alternative text is provided with thearia-labelproperty.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>'sid) 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, 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:
| 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.
Recommended layout
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.
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]
Good example
Recommended behaviour
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.