Publishing formats

This module covers things to consider when publishing charts within analytical publications.

Charts may be published as:

• HTML charts
• images on webpages
• images within document formats

HTML charts

You may be able to build your chart into the HTML code of the webpage you publish on.

For example, GOV.UK allows you to create some charts in the HTML code. These charts have a function that allows users to switch to a table view of the data.

Examples of tables and bar charts you can create on GOV.UK (link opens in a new tab).

This is very useful functionality in terms of accessibility. But the tables are only a suitable text alternative for relatively small amounts of data. They would not be suitable for a long time series of data.

Images of charts

You may need to publish images of your charts.

If so, it is best practice for the chart image to be in the Scalable Vector Graphics (SVG) format.

This allows users to zoom in very closely without losing any clarity. This is important for users with visual impairments.

How to create an SVG

Newer versions of Microsoft Office programs will allow you to right click on a chart, select “Save as Picture” and then select SVG from the drop-down list.

Newer versions of PowerPoint will also allow you to save a whole slide as an SVG. Select a slide from your deck, click “Save As” from the “File” menu, choose “SVG” from the drop-down list. Then, click “Just This One” from the pop up.

You can also save and export SVG images from R and Python and other coding software.

Further information on creating SVG images is in our ‘Making analytical publications accessible’ guidance (link opens in new tab).

Chart titles

Charts should (ideally) have two titles:

• a headline title that gives the main message of the chart
• a statistical subtitle that describes the data the chart is showing

The headline title should be descriptive and communicate the data trends or highlight the main story. Aim to use 10 words or fewer whenever possible – shorter titles are easier to read and avoid text flowing over several lines.

The statistical subtitle should state:

[what the data is], [the geography the data relates to], [the time period the data relates to]

One of the titles should have “Figure n” at the start. This helps navigation and assists screen reader users in understanding there is a table or chart on the page. We recommend “Figure n” should be at the start of the statistical subtitle.

Example

Increase in number of people living alone – headline title

Figure 1: Number of people living in one person households, England, 1991 to 2021 – statistical title

Service-manual.ons (the style guide for the Office for National Statistics website) has more information and examples of chart titles (link opens in new tab).

Title placement

Chart titles should be in the body text of the webpage or document, not in the image of the chart.

Images of text can be difficult to read and should only be used when essential. For example, it is OK for chart labels and annotations to be in the image of the chart.

Tagging titles

Both chart titles need to be tagged correctly in the code of the document or webpage you are publishing on to meet the accessibility legislation. Tagging headings helps users navigate webpages. More information on tagging headings (link opens in new tab).

In a document or webpage the main heading is tagged as ‘headings 1’, first level subheadings as ‘headings 2’ and so on.

Appropriate tagging for chart titles will depend on where the chart sits in the document.

How to tag headings depends on where you are publishing. If you have a publishing team they should be able to advise.

The text alternative

Accessibility success criterion 1.1.1 states that all non-text content (such as charts) should have text alternative that serves the equivalent purpose.

For data visualisations, this can be:

• a table of data
• a text description of the message the chart is showing

Which you choose should depend on what you expect users to get from the visualisation:

• if you expect them to read off data points, give a table
• if you expect them to take away a message, give them the message
• if you expect them to do both, give both

Note: when a chart shows lots of data points, a table is not normally a suitable text alternative. When making a decision on the type of text alternative to provide, consider whether you would be able to understand the data if the table was read out to you.

Text alternatives are a part of a publication

For simple charts the headline title may be a suitable text alternative as it gives the main message of the chart. For more complex charts this will not be true. You should think – does this title really “serve the equivalent purpose” to the visualisation – or could you provide something better? How would you describe the chart to someone over the phone?

Make sure to think about your text alternatives at the start of the report writing process, not as something to add in at the end. This will make your publication flow better and avoid repetition.

Text alternative placement

The text alternative should be in the body text of the webpage or document.

Ideally it should be directly beneath the visualisation, before source information, data downloads and any footnotes.

Depending on the length of your publication and how your commentary is written it can be a good idea to place the text description under a subheading. This subheading should be marked up correctly (given the structure of the page you are publishing on). It should also be specific to the figure, for example “Description of figure 1”.

If you find the subheadings break up the text too much you can start the text under the chart with “Description of figure 1: . . . ” instead. See this publication from Welsh Government for an example of this.

Empty alt attribute

Once your text description is in the body text, the ‘alt-attribute’ – which is the alt-text field in the code behind the data visualisation, should be left empty.

The chart should be marked as decorative. This will often happen automatically if the alt-attribute is empty, but sometimes you will also need to tick a box.

Why leave the alt-attribute empty?

Reason 1: If the alt-attribute is empty, screen reader software will skip over the visualisation to the text alternative below. This will improve the flow through a webpage or document.

Reason 2: Not everyone who needs the text alternative can easily access the alt-attribute.

For example, someone with a visual impairment who needs to use a high level of zoom may not be able to clearly see the visualisation. They might want to access the text alternative. But if they do not use screen reader software, they may not know how to access the alt-attribute text.

The only exception to this is if your chart image acts as a link to a larger version of the image. Then you should put “Larger version of figure X” in the alt attribute so screen reader users will know where the linked image will take them.

Source information

It is best practice to name and link to the data source or sources under each visualisation.

This improves transparency and can help users better understand the data.

This text should be in the body text of the webpage or document, not in the image.

Sources should be stated as: [publication, survey or other source of data] from the [organisation]

For example:

Source:  Childcare and early years survey of parents from the Department for Education

Data download

It is best practice to provide the data used in the visualisation in an accessible data file.

Providing data files specifically linked to visualisations has three main benefits:

• it improves transparency
• it allows others to accurately recreate the visualisation in their own branding (news websites for example – increasing your audience reach)
• it can act as the text alternative (although the best way to provide a table as the text alternative is to have it within the body text)

You should link to the data download under the chart.  Links to files should use unique text (not just ‘Download the data’) and include the file type and size

For example:

Download the data for figure 1 (ODS, 5MB) (not a real link) or:

Download the data for number of people living in single person households (ODS, 5MB) (not a real link).

Having several links on a page with identical text causes issues for screen reader users as it makes it hard to work out what each link is pointing to.

Providing the file type and size allows users to judge whether they will be able to download and open the file.

Chart footnotes

Footnotes are sometimes necessary.

For example when you need to explain:

• changes in definitions
• anomalies or inconsistencies
• changes to methodology which may affect how values can be compared

Remember!

When there are lots of footnotes it:

• increases publication length
• makes navigation around the webpage more difficult
• requires lots of scrolling – this is harder on mobile devices and frustrating for users

When they are needed, make sure they are:

• in the body text of a webpage or document, under the information on sources and data download (they should not be in the image of the chart)
• as short as possible – consider linking to detailed information in a different section, a separate glossary or a user guide

Quick practice on publishing structure

Test your knowledge of the module so far. Drag the different elements in the order they should appear when publishing a chart.

Exercise on creating a chart to publish

Exercise on creating a chart to publish (PPTX, 55KB).

Try this longer exercise to test your skills on creating a chart to publish within a report.

If you have problems accessing or using this file please email Analysis.Function@ons.gov.uk.

Quiz

Try these questions to test your knowledge from this module

Download a plain text version of module 10 quiz (ODT, 8KB)

End of module 10

Next, module 11: Tables

Back to landing page.