The WebAim Millon is a project that evaluates the accessibility of home pages from the top 1 million websites. Due to the unique nature of each website, and the fact that the analysis uses automated tools to collect data, there is certainly some room for slight inaccuracies. However, the overview it provides is definitely worth noting if you want to gain some insight into the current state of accessibility on the web.
The 2024 report found that 95.9% of home pages had detected failures of Web Content Accessibility Guidelines (WCAG). Whatever adjective you use to describe this number, it doesn’t make for encouraging reading.
The “Complexity” of home pages is determined by the amount of HTML elements present, and this has increased by 50% over the last 5 years. A relatively safe assumption to make is that a substantial percentage of the home pages contain, at the very least, straightforward markup and common user interface (UI) components despite the ever-growing number of elements.
This raises a number of questions, how is it possible that such a large amount of popular home pages still have detectable failures, and if home pages contain more standard UI structures, what does it mean for the accessibility of complex visualizations?
While no data is available to evaluate the accessibility of data visualization on the web, given the information provided in the WebAim Million project, you can imagine that it doesn’t fare much better, and in all likelihood, is probably much worse.
Upon being asked, “Based on your experience, on your work, what percentage of charts, graphs and data visualizations that you encounter are an accessible experience?”, Microsoft accessibility expert and screen reader user Ryan Schugart answered, “I really am sorry to say that the vast majority are not accessible.”.
One point you should probably understand before making visualizations more accessible is that you are stepping into a world that is often overlooked. Historically, accessibility has not been treated as a first class citizen. As a result, both guidance, and the standards and technology we use to improve accessibility remain somewhat fragmented, and fittingly enough, often seem like more of an afterthought.
Given the landscape in which we find ourselves, the one thing this article won’t do is provide you with a step-by-step guide on how to make your particular diagram more accessible, but we will explore some accessibility problems of data visualizations, and hopefully provide enough insight so that you can begin thinking about solving them.
Having a good foundation is important, and in order to prime your visualizations for accessibility, the technology you choose will provide the building blocks for how accessible your diagrams are.
Canvas and SVG are probably the most popular methods to create and render custom visualizations on the web, but the role in which they will affect how accessibility is or isn’t implemented in your diagram couldn’t be more different. Canvas is a single element within the DOM, and the impact this has on accessibility cannot be understated.
Canvas doesn’t provide any information about the drawn content, nor does it expose any information to accessibility tools. MDN puts it rather bluntly:
“In general, you should avoid using canvas in an accessible website or app.”
In contrast, as SVG and all its content is in the DOM, it naturally conveys semantic meaning, and assistive technology can access sub-elements, text and links. As SVG was designed with web standards in mind, it can be further enhanced by accessibility standards such as ARIA (Accessible Rich Internet Applications). That means what is visually represented in a graphic, can also be conveyed in the markup itself, allowing assistive software to get access to this information.
Canvas is often sold as “not having to deal with the overhead of the DOM”. In terms of accessibility, that “overhead” is your users.
The accessibility of your graphic depends on semantic information about its structure in order to allow assistive technologies to communicate the data to people with disabilities. The benefit of using SVG is that all elements within your visualization can have their semantic meaning further augmented by the ARIA standard.
The disjointed nature of resources to learn about accessibility has the effect that W3C standards like the ARIA Graphics Module can go unnoticed, and currently won’t be found on sources of truth that developers often utilize such as MDN. This module defines 3 useful ARIA roles that you can use in your visualizations today: graphics-document, graphics-object, and graphics-symbol.
Consider a simple bar chart, the graphics-document role could be applied to the root element. This may or may not be the SVG element itself depending on the UI being described. The graphics-object role might be suitable for describing container elements for the x and y axes. Each axis container has distinctive sub-elements that when taken as a whole, have semantic meaning. Lastly, the graphics-symbol role could be applied to each individual bar as it’s an atomic element of a larger chart.
If you feel existing ARIA roles don’t apply to your particular diagram, it’s always good to remember “No ARIA is better than bad ARIA” when authoring your markup. You may unintentionally override accessibility semantics causing problems for assistive technology users. The WebAim million report found that home pages with ARIA present averaged 34.2% more detected errors than those without ARIA. Food for thought.
One of the primary reasons data visualization is so useful is that it condenses a lot of information in a way that’s more approachable, rather than presenting users with a wall of text. JavaScript enables us to make this information dynamic, but also raises some accessibility questions in doing so.
It’s possible to update data points in a visualization without requiring an entire page reload, and for sighted users, visual changes are naturally evident. Unfortunately, users of assistive technologies may be completely unaware of non-user initiated dynamic content. If you are attentively waiting for live updates from your favorite team, what use is it if you aren’t notified of the latest score?
Harping back to some ARIA talk, ARIA provides the concept of live regions. ARIA live regions are the only established mechanism today for conveying dynamic content changes to the accessibility layer. Content changes that are not interactive should be marked as live regions, and thus expose the content in a way that can be announced by assistive technologies.
As live regions are the only manner in which to communicate these dynamic changes, careful consideration needs to be given to understanding if your diagram needs live regions or not. Like a lot of things in the ARIA world, live regions can also be misused. In fact, some good folks over at Microsoft have created a proposal that would provide an alternative to live regions in scenarios where they are not suitable.
Accessibility should not be reduced to some bullet points, it should be a priority in your workflow. If accessibility concerns are included in your planning and design process, your visualization will be accessible for all your users, and probably look better too.
There are a number of considerations in terms of accessibility that should be included in your projects from the outset. WebAIM consistently lists low contrast text as the primary accessibility failure in its reports. The contrast is a measure of the brightness between 2 colors i.e. text on a particular background.
Diagrams and charts are likely to contain scales, legends, labels, and general text content. Ensuring this content is accessible for all users should be a high priority, and is often addressed by minor changes to CSS.
There are many online tools available to be certain that your visualization meets the W3C WCAG 2.1 guidelines on contrast. If working in a team, both developers and designers should be aware of these tools, so that some of your users aren’t left wondering what your data is all about.
Subtle design choices can also contribute to the contrast of your diagram. Space can create balance and differentiation, highlighting that sometimes what doesn’t exist is just as important for clarity. Borders, gentle patterns, and dashed styles can also lend themselves to creating contrast, but could prove overly distracting if used indulgently.
Patterns and dashed styles work well for the principle that your visualization shouldn’t rely on colors alone to convey the data. It’s possible that some of your users with partial vision won’t be able to determine which colors you have used in general, and certain color palettes may be more suitable for people with some form of color blindness.
Common UI elements such as labels and tooltips can go a long way to making graphical elements more accessible while lessinging an over-reliance on color.
Text is not only something that needs attention when it comes to contrast, concise descriptions are crucial to providing users utilizing assistive devices with the same information that is visually conveyed to sighted users. A text summary of a visualization that also describes its trends, if applicable, makes it possible for all users to consume data.
Although often forgotten, providing alternative text for images is one of the more known accessibility requirements for a lot of developers, but do we have something like that for graphics?
In SVG, the title element provides an alternative text description of SVG content. The title element should be the first child of its parent element in order to give its parent an accessible name. It won’t be rendered visually, but browsers usually display the title content in the form of a tooltip.
Continuing in a similar fashion, SVG also has a desc element. Once again, it’s not rendered visually by default, but it is intended for human consumption allowing for a more detailed description than the title. Together these elements can provide vital information for visually impaired users, and depending on screen reader support, it might be a good idea to further compliment them with an aria-labelledby attribute on the SVG element itself.
Alternative text should simply indicate what the data visualization is, and what it’s about. You must resist the urge to explain the entire diagram or chart with text, and the fine details should be communicated via other techniques.
Alternative content is not something that is limited to text descriptions. One of the primary aims of accessibility is to provide an equivalent experience to all users. That means alternative or fallback content for the entire graphic is desirable, as it allows all users who are otherwise unable to navigate the presented data to do so.
In terms of communicating the fine details that we mentioned earlier, alternative content is one of the more suitable places to accomplish this. Additional markup is usually the vehicle in which this content will be delivered, but ARIA roles can once again play a part in helping us with accessibility.
An SVG line chart could be presented to screen readers as tabular data using ARIA to add table semantics right into the SVG markup as demonstrated by accessibility expert and screen reader user Léonie Watson. Using a similar approach, an SVG flowchart could be represented as a series of nested lists using ARIA to apply list semantics. This is a great technique as it reduces duplication, and the accessibility of the main SVG content has been improved.
As Léonie explains in a wonderful presentation, the extent to which this technique can be scalable is certainly open for debate. Line and flow charts are all well and good, but as soon as you run into other complex visualizations, the ARIA semantics you need are lacking, so alternative routes to accessibility would have to be considered. It’s at this point you may decide to provide a secondary view with DOM elements alongside the graphical view.
Making visualizations keyboard-accessible is an important aspect of accessibility. Navigating data points, and interactive controls is essential in order to ensure all users can find content and orient themselves.
Keyboards are not the only technology that can take advantage of keyboard behaviour. Assistive technology can emulate keyboard behaviour, so the ability to navigate via keyboard may be utilized by a wider range of people than one might expect.
Complex diagrams contain many interactive elements. As a result, you may need to manage keyboard focus, which is restricted to tabbing between focusable elements. The default tab order provided by the DOM position of elements is convenient, but you might encounter situations where you think a modification to tab order is necessary
Typically, the recommended modifications will be to use the tabindex attribute with a negative or 0 value. A negative value doesn’t place the element in sequential keyboard navigation, but still allows focus set to it, while 0 places the element in sequential keyboard navigation.
A positive value for tabindex is not recommended, because you can disrupt the normal focus order and may confuse users. There’s even an issue in the W3C HTML Working Group requesting that positive values be deprecated completely. The general consensus seems to be that if you need to use a positive tabindex, then your HTML isn’t structured well and should be refactored.
Does this thought process also apply to complex applications in SVG that contain HTML? SVG visualizations are usually made up of many different sub-elements that have an implicit drawing order. The first element in the SVG is “painted” first, and subsequent elements are “painted” on top of previously painted elements. As of yet, SVG doesn’t have a z-index property that would allow us to control the stacking context, but it was mentioned in a previous working draft of the SVG 2 specification.
Consider the following UI in SVG. A background element with an input is added to the SVG. Afterwards, two elements are placed on the background, each with their own input respectively. These three elements are all siblings in the DOM.
Focus order should preserve meaning, but what if the intended meaning of the UI is that users should tab the foreground inputs first sequentially, and then the background input afterwards? As the background was “painted” first, the default tab order results in the background input receiving focus before the foreground inputs.
One of the main criticisms of positive values for tabindex is its misuse. This implies the existence of correct usage, and unsurprisingly, examples of correct usage are difficult to find. If refactoring a complex UI in SVG isn’t possible, maybe this could be a use case for correct usage.
This is just an example of a question you may find yourself asking when making diagrams and charts more accessible. As with a lot of things in the accessibility sphere, finding an answer often proves difficult, so opening the discussion is a good place to start.
There are many things wrong with the current state of accessibility on the web. This has even led to some declaring that accessibility has failed, and that generative AI will automatically generate accessible user interface designs.
One of the main roadblocks on this path is that the popular tools available have already been tested in this regard, and the findings were that they don’t understand accessibility requirements. That’s certainly not to say that this won’t improve in future, but while it is a tantalizing idea, it seems like it wouldn’t be viable currently.
This idea also somewhat discounts the fact that countless people with disabilities can navigate the web, albeit with some difficulties, due to established accessibility practices, not to mention the historic work that has already taken place in the accessibility space. It would take a huge amount of work to even reach the same point with generative AI
A more alarming subtext of the generative AI and accessibility discussion could be that accessibility is given a lower priority as companies decide that AI will somehow solve accessibility at some undetermined point in the future.
Accessibility is a broad church, and the topics mentioned in the article just scratch the surface of points you might want to consider when making your visualizations accessible. Voice input and sonification are just a few of the many other beneficial methods in which users could navigate and understand your diagrams and charts. Web standard features, such as prefers-reduced-motion, also need to be taken into account.
For those of us who pay attention to the release notes of modern browsers, SVG can often feel like the forgotten child of the web world, and developers are waiting patiently for SVG 2.0.
In our opinion, the practical and ethical benefits of SVG far outweigh what Canvas has to offer, and the accessibility potential is enormous.
If the world of accessibility can sometimes seem a little incoherent, external factors which may influence it are often no different. The European Accessibility Act (EEA) aims to create a unified accessibility policy across the EU, but provides exemptions to certain industries and enterprises of a certain size. It also lists the products and services that the act covers, but doesn’t provide any technical framework as to how those things should be made accessible.
16% of the global population have disabilities according to the World Health Organization. While all of those people obviously don’t use assistive software to navigate the web, the number is difficult to ignore. It’s not yet clear how much longer people with disabilities will have to wait for a truly accessible web, but one thing is certain, they need to be included in the conversation more.
.jpg)
