How to create accessible charts

Introduction

I was recently tasked with the challenge of creating a series of accessible charts and graphs for an internal project. We were attempting to present some graphs showing site usage statistics pulled from one of our google analytics accounts. Charts and Graphs can be tricky to implement on web pages in such a way that the underlying data is available and accessible to every visitor to your site. Traditionally the majority of graphs and charts would have been presented as images. This is perfectly valid for data that is unlikely to change, provided that the content of the graph or chart is described in plain text near the image or by using the longdesc attribute of the image. However, if the corresponding data is regularly updated, presenting graphs as images would represent a significant maintenance issue (new images would need to be created and uploaded each time the data changed). In our case we were pulling data from Google Analytics every 24 hours resulting in a different data set every day. We needed to find a solution that satisfied each of the following criteria:

• Graphs and charts needed to be presented so that sighted people are able to identify visitor trends quickly and easily;
• The graphs and charts needed to be dynamically generated, therefore removing the need for continued maintenance;
• The information needed to be accessible to people who use text only browsers, assistive technologies such as screen readers and those who do not have JavaScript enabled web browsers.

With these criteria in mind I set out to find a solution.

Enter jQuery Visualize

It didn’t take me long to find “jQuery Visualize”, a jQuery plug-in (developed by the Filament Group) for creating graphs and charts. The plug-in uses relatively new technologies (such as the HTML5 canvas element) in conjunction with JavaScript to create dynamically generated accessible charts and graphs. For browsers that do not yet support the element, the plug-in makes use of a JavaScript library provided by Google that makes it possible to translate canvas elements into VML elements. Using this approach accessible charts and graphs can be supplied for all of the major web browsers in use today.

So what makes the charts accessible?

Strictly speaking, the actual graphs that are created by the script are no more accessible than an image would be. In many cases the opposite of this would be true since the charts do not have any textual description that would help non sighted people to identify the data contained within the graph. The true beauty of the “Visualize” plugin lies in its implementation requirements. For the plugin to work correctly, all data to be transformed into a graph or chart must be marked up as an HTML table with semantically appropriate relationships, headings and captions. The plug-in will then scrape all relevant data from the table and use it to generate the graph or chart. Since the plug-in requires semantically appropriate HTML, it promotes good practise amongst the developers that use it and ensures that a semantically appropriate representation of the data is available to site visitors by default. Since this default representation of the data is available and (should be) semantically correct people who have blindness or do not have JavaScript enabled browsers will always be able to access a textual alternative of the graphical data generated by the script. This in itself ensures that everyone is able to access and interpret the data in one form or another.

But I don’t want my visitors to see HTML tables as well as graphs

No problem. With a little sleight of hand, we can ensure that the data table is only available to the people that require it. Let’s think about people who use assistive technologies such as screen readers first. For these people the generated graphs themselves are not particularly useful. As such, we need to ensure that they will always be able to access the data contained within the HTML table. Many screen readers will not be able to interact with elements that have been hidden using the CSS display:none; or visibility:hidden; declarations. As such, these declarations should not be used to hide the table. Instead we are able to position the table off screen using absolute positioning (See code example below).

Code example

HTML

            ... Table headings go here ...
        
            ... Table rows go here ...

CSS

table.visualize{
    position:absolute;
    left:-9999em;
}

This is a great start. The table will disappear from the visual flow of the document, but will still be accessible to people who use assistive technologies such as screen readers. However, we have a problem. Sighted people who do not have a JavaScript enabled browser will not be able to see any data either (the plug-in will not work without JavaScript, yet the table itself has been removed from the visual flow of the document). Luckily this issue can be resolved by writing one line of JavaScript and modifying our CSS slightly. The javascript that we will write will simply add a class of ‘js’ to the body element of the document. As this class will only be applied to the element if the user has a javascript enabled browser we can hide the table only if this class is present on the body tag (see the revised code example below).

Code example

HTML

            ... Table headings go here ...
        
            ... Table rows go here ...

JavaScript

$(document).ready(function(){
    $('body').addClass('js');
});

CSS

body.js table.visualize{
    position:absolute;
    left:-9999em;
}

By utilising this method for selectively removing the HTML table we can ensure that sighted people will only see the HTML table if they do not have a JavaScript enabled browser. If they do have a JavaScript enabled browser, they will be shown a chart in its place. In addition to this, by using absolute positioning to hide the table (as opposed to display:none; or visibility:hidden; declarations) we have ensured that people who use assistive technologies such as screen readers will always be able to access an alternative representation of the data presented using the “Visualize” plugin.

Conclusion

Many of you may argue that this article has been about progressive enhancement, coding best practice and to a certain extent I would be inclined to agree with you. However, what I hope to have shown is that it is possible to provide dynamically generated charts and graphs without negatively impacting on your websites accessibility. Although the “Visualize” plugin itself does not inherently create accessible charts, it certainly helps us to achieve our goal as it requires data to be presented in an accessible manner in the first instance. Many other plugins used to create charts on web pages require that data is passed into the plugin constructor when it is first instantiated. Although this often achieves the same visual effect, you are required to do significantly more work to provide an accessible alternative. The really great thing about the “Visualize” plugin is that it extracts the relevant data from an accessible representation of the data in the first instance.

Start building accessibility into your projects at the beginning to save time and money, don’t just leave it hanging on the backlog letting it gather up dust. Drill it in.

If you would like Nomensa to help you with your accessibility challenges or to provide you with an accessibility evaluation of your website/mobile app, please don’t hesitate to get in touch.

Take a full look at the web accessibility services that we offer.