Data visualisation: testing dashboards for design and accessibility

The importance of accessibility

Impact on users

It is important to make your dashboard as accessible as possible for your users. If content is not available in an accessible form (such as through a screen reader) many users will not get the information they need from your service.

The Department for Education has a useful tool to help you find out how many of people might have a disability or impairment who could use your service.

Consequences for inaccessible content

In the UK, all content on public sector external websites and intranets must legally meet the level A and AA success criteria in the Web Content Accessibility Guidelines 2.2. All dashboards must meet these criteria.

Dashboards must be perceivable, operable, understandable, and robust, with all users being  able to:

• change colours, contrast levels and fonts using browser or device settings
• zoom in up to 400% without the text spilling off the screen
• navigate most of the website using a keyboard or speech recognition software
• listen to most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)

More information:

• our guidance on the accessibility legislation
• understanding accessibility requirements for public sector bodies – guidance from the Central Digital and Data Office

Inaccessible content can get complaints related to the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 or the Equality Act 2010. This could cause reputational damage and loss of public trust. Ensure whoever is responsible for the content you publish is aware of this and the possible risks involved.

Content checklist

Accessibility statement

Use an accessibility statement to outline any accessibility issues identified in testing, ideally alongside planned fixes. This can be a dashboard specific accessibility statement or part of a departmental one.

You can use GOV.UK template accessibility statement to use to write your statement.

Examples of good accessibility statements for a dashboard:

• UKHSA data dashboard
• DfE pupil attendance and absence in schools in England: data dashboard

Contact information

Your dashboard should contain contact information that:

• makes it clear who owns the dashboard
• includes an email for a shared inbox where possible for continuity purposes

Cookies

Include a unique cookies page in your dashboard to tell users about cookies used by your dashboard. This page should:

• give users the option to accept or reject non-essential cookies
• explain any essential cookies to users (although you do not need user’s consent to set these)

Do not take the information on this page as legal advice. Your organisation is responsible and accountable for complying with data protection legislation, such as:

• Privacy and Electronic Communications Regulations (PECR)
• General Data Protection Regulation (GDPR)

Check with your organisation’s privacy expert to see how data protection legislation affects your dashboard.

For more detailed information on creating a cookies page, please see the gov.uk design system guidance.

Metadata – information about the data

Include metadata (information about the data) in your dashboard, covering:

• links to the source data, including a description
• information about the last update, including relevant dates
• the date of the next update
• the period the data refers to
• links to data definitions, guidance, methodology, quality information, and any related commentary

Information about quality (such as an annotation to explain a discontinuity in the data) can be difficult to automate and display, therefore consider simple visualisations if users are creating their own charts.

Work closely with interaction designers to create information architecture that allows:

• data to be central
• metadata (information about the data) to be clear
• statements about quality to be obvious

Source data

Make the source data available to users in a way that follows open data standards. You can link source data either:

• wherever you reference the data (for example below the chart on display)
• on a separate relevant tab

For dashboards powered by a database, use an API and:

• ensure this data is suitably anonymised
• ensure the schema is designed to optimise data retrieval
• ensure the data is securely hosted
• consider involving a data architect for this

For simpler dashboards, you can supply the data through an accessible spreadsheet document, or link to the relevant statistics publication.

Dashboard code

Add links to any code used to create the dashboard, ideally through GitHub if permitted by your department.

Design

Data structure

Comprehensively quality assure the data in your dashboard so that:

• the data cannot be combined to tell misleading stories
• data combinations are accurate
• there are no disclosive data

For dashboards that allow users to get custom cuts of data, user research can be helpful to create a data structure that is easy for users to navigate.

Page content

Design your dashboard using an inverted pyramid structure, with your most important headline content up front and detailed information in other tabs.

Users should be able to get the dashboard data in as few steps as possible. Structure your dashboards to:

• minimise the need to scroll on a dashboard page
• limit the number of clicks a user needs to get to the data they want
• avoid horizontal scrolling
• paginate large tables rather than allowing them to spill off the screen
• use filters and interactive options to remove the content you need to display on one page

Consistent designs

Risks of inconsistent designs across government include:

• users needing to learn how to navigate different interfaces, which can be unclear and frustrating
• users being confused if the design looks too different from other government content

Keep the design of your dashboard consistent with other dashboards across government by researching existing dashboards and talking to their owners.

Visual clutter

Simple designs are the most effective ways to present data, for example:

• prioritising important metrics and visuals
• using white space effectively
• limiting colour schemes and fonts to a few consistent choices
• ensuring that any data visualisations are simple and clear – avoid complex charts that overwhelm the user

Test your dashboard with users and speak to other specialists such as service designers.

Data visualisation

All charts and tables in your dashboard should follow the data visualisation guidance published by The Analysis Function Central Team.

Responsive web design (designing for all devices)

Two-thirds of users of the ONS website will view content on a mobile device. Test how your dashboard will look and function not only on a desktop monitor, but also on a mobile device or tablet. There is guidance on designing for different browsers and devices from the Government Digital Service (GDS).

Accessibility checklist

Design with accessibility in mind from the start. This will save time and result in a dashboard that is easy to use, accessible and effective for a wide range of users. Cover accessibility thoroughly before moving onto user testing.

Content

Make the dashboard simple and easy for users by using:

• short, simple sentences (plain language)
• visuals with explanations and alternative text
• clear instructions on how to navigate
• information organised logically so users can quickly find what they need

If you plan to make your dashboard publicly available, follow the guidance for writing well for the web. This includes information on:

• meeting user needs
• how users should find information on the web
• creating easy to read and accessible content

Fonts and Sizes

Use accessible fonts and ensure text sizes are large enough for readability (at least 12pt or equivalent). For guidance on readable fonts and text sizes, see WebAIM: Typefaces and Fonts.

The WCAG success criterion 1.4.4 states that “Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)”.

Many users with visual impairments will adjust their zoom settings to read text. Check that you can zoom up to 200% on your dashboard without impacting functionality (for example, text overlapping or spilling off the page).

If using CSS, create fonts with Rem units to allow automatic scaling when users adjust zoom, as hard-coded pixels will not automatically adjust.

Static charts

For all charts:

• place legends, labels and other descriptive elements in a consistent, simple layout
• avoid overlapping elements
• make text legible and clearly associated with data points

No chart is fully accessible. This means that we must make the underlying data and message available in a different format to allow all users to access the data in a way that works best for them. This could be:

• alternative text
• supporting data tables
• providing options to download the data

Consider static SVG charts with underlying HTML code. You can use the code behind SVG images of charts to allow users to access the data as if it were a table by using tab and arrow keys to navigate through the values.

Interactive charts

Interactive charts can be difficult to use with assistive technology. If you are using these, you should ensure that:

• there is an option to download a machine-readable flat file of the chart data (this benefits all users)
• when users hover or select on the chart, it is clear what is being focused on
• the chart can be easily navigated with the keyboard
• screen readers can read interactive elements when they are focused on, or point to a table alternative
• there is visual feedback when users interact with elements (for example, hover or focus states) to ensure accessibility for users with motor disabilities

For example, charts made using Plotly are often inaccessible, as:

• they cannot be navigated with a keyboard
• screen readers struggle to interpret the chart without the appropriate aria labelling (an element of the underlying HTML code)

Effective alternative text for interactive dashboards needs to adapt to the interactions of users. This means you must carefully consider the level of interactivity in your charts.

SVG (Scalable Vector Graphics) download option

If possible, allow users to download charts as SVG files. This is ideal for accessibility, as SVGs maintain high quality at any zoom level and are often more screen reader-friendly than other formats.

Scrolling

Avoid internal and horizontal scrolling. For vertical scrolling, consider having the information in the visible window.

Test scrolling manually by navigating and resizing the window.

Keyboard Navigation

The entire dashboard must be accessible using keyboard navigation for users who rely on keyboards. This includes focusing on chart elements, data points, and legends.

Navigation

Structure your dashboard for easy user navigation (both vertically and horizontally), including for users who rely on keyboard navigation.

Design for smooth navigation by:

• using semantic HTML tags to create a clear content hierarchy, so screen readers can properly interpret and describe important components
• giving elements appropriate header levels, as skipping header levels can confuse anyone who uses header hierarchies for page navigation
• setting a logical tab order for interactive elements (such as buttons)
• providing all elements and visuals with descriptive alternative text for screen readers
• make all interactive elements focusable and navigable using the keyboard, with visible focus indicators when users tab through them

Testing

Test on both accessibility and cross-browser compatibility, with advice from accessibility experts in your organisation.

You may find helpful:

• the government accessibility community
• the Basecamp for the government content community

Cross-browser compatibility

Webpage-based accessibility checks are straightforward, so can be used by non-developers. Test the dashboard in various browsers to ensure it functions consistently across all platforms.

Accessibility testing

Manual (user) testing

Manual testing identifies accessibility issues overlooked by automated tools and helps ensure that your dashboard meets the needs of real users, particularly those with diverse accessibility requirements.

Accompanying content

No dashboard is ever 100% accessible. In addition to the dashboard being as accessible as possible, make the data available elsewhere in an accessible format (such as data tables or commentary).

Helpful links

For more information on dashboard design, read:

• 4 design principles for creating better dashboards
• 10 rules for better dashboard design

For any further questions or to discuss updates to this page, you can:

• join the accessibility community for government
• email Function@ons.gov.uk
• join our Basecamp project for accessibility for statistics and analysis or presentation and dissemination of statistics and analysis – if you are not on the Cross Government Basecamp, email Function@ons.gov.uk for an invite link
• contact your departmental presentation or web dissemination champion
• join the #design Channel on UK Government Digital Slack
• join the #content Channel on UK Government Digital Slack
• join the #chat-data-vis channel on Gov Data Science Slack