Why a single alt text isn't enough for complex charts, and what works instead
A price history chart or a stock level visualization in the Magento admin conveys a trend, an outlier group, or a critical threshold to sighted users at a glance, while practically none of that survives for screen reader users without deliberate additional work. This article covers why a brief alt text structurally hits its limits with complex charts, and how hidden data tables, ARIA descriptions, and a clean figure pattern create real accessibility.
Table of Contents
- 1. Why charts pose an accessibility challenge of their own
- 2. Why a simple alt text isn't enough for complex charts
- 3. Hidden data table as a fallback pattern
- 4. ARIA trend descriptions: using aria-describedby correctly
- 5. figure, figcaption, and details: the building blocks for structured charts
- 6. Practical example: an accessible price history chart in the product frontend
- 7. Practical example: stock level visualization in the Magento admin
- 8. Color coding in charts: contrast and redundancy
- 9. Testing: how to check chart accessibility with screen readers
- 10. Summary
- 11. FAQ
1. Why charts pose an accessibility challenge of their own
A chart conveys information through several simultaneously perceivable visual channels: the position of points on two axes, the slope of a line, the relative height of bars compared to each other, and often color as a third dimension on top. Sighted users grasp that combination in a fraction of a second without consciously reading every single data point, a process that doesn't translate easily into linear, serially read-out text.
Unlike a single informative image, where a precise alt text can usually convey the core message in full, a chart frequently packs a whole range of distinct, potentially relevant pieces of information at once: the rough trend, individual outliers, a comparison between several data series, and the underlying concrete numeric values. A single alt text inevitably has to settle for a rough summary and leaves out exactly the details that represent the actually relevant information for some users.
2. Why a simple alt text isn't enough for complex charts
An alt text like chart shows price trend over twelve months formally satisfies the requirement to set alt text, but delivers no real informational value at all, since it completely omits the chart's actual message, namely the direction, magnitude, and timing of the price change. For WCAG 1.1.1 such text technically exists, but it misses the requirement's actual purpose, namely providing equivalent information to users who can't see the image.
Even a considerably more detailed alt text hits a practical limit: an alt attribute gets read out by most screen readers as a single, unbroken block of text, with no way to jump to individual data points or look up a specific number, which quickly becomes impractical for a chart with twenty or more data points.
3. Hidden data table as a fallback pattern
The most robust pattern for complex charts is a complete, semantically correct HTML table containing the same raw data the chart is built on, visually hidden for sighted users but fully accessible to screen readers and navigable by keyboard. Such a table delivers exactly what an alt text structurally can't: individually addressable rows and columns, correctly marked-up header cells, and arbitrarily precise numeric values instead of a rough summary.
It's important not to hide the table with display none, since that CSS property also removes the element from the accessibility tree, making it unreachable for screen readers as well. Instead, a visually hiding but semantically preserving class is used, one that removes the element from the visible layout without removing it from the perception of assistive technology.
<figure aria-labelledby="price-chart-title">
<figcaption id="price-chart-title">Price history for the last 12 months</figcaption>
<!-- Visual chart, hidden from screen readers via aria-hidden -->
<div id="price-chart" aria-hidden="true"></div>
<!-- Hidden but fully accessible data table -->
<table class="sr-only">
<caption>Raw data for the price history chart</caption>
<thead>
<tr><th scope="col">Month</th><th scope="col">Price in EUR</th></tr>
</thead>
<tbody>
<tr><td>January</td><td>89.90</td></tr>
<tr><td>February</td><td>84.50</td></tr>
<tr><td>March</td><td>84.50</td></tr>
</tbody>
</table>
</figure>
4. ARIA trend descriptions: using aria-describedby correctly
Besides the full data table, a short textual trend summary tied to the chart container via aria-describedby helps a lot, so a screen reader reads out the most important takeaway immediately when the chart receives focus, before optionally moving on to the detailed table. That summary should contain concrete values instead of vague phrasing, say the price fell from 89.90 EUR in January to 79.90 EUR in December, a drop of roughly eleven percent, rather than just the price dropped.
The combination of aria-describedby for the short summary and a linked, full table for the detail values thus forms a tiered information architecture that allows both a fast overview and precise detail lookup, instead of forcing a choice between the two needs.
5. figure, figcaption, and details: the building blocks for structured charts
The figure element with a figcaption child delivers the semantically correct wrapper for a chart and its caption, and gets announced by screen readers as a single unit with a title, which already establishes a solid semantic foundation before any ARIA addition. Within that figure, the hidden data table can either stay permanently in the accessibility tree or be made optionally expandable via a details element, so sighted keyboard users can also access the raw data on demand.
A details element with a summary like show data as table brings the added benefit of being natively keyboard-operable without needing custom JavaScript for expanding and collapsing, and it benefits sighted and blind users alike instead of building a solution for just one user group.
6. Practical example: an accessible price history chart in the product frontend
For a price history chart in the product frontend, say rendered with Chart.js in a Hyva theme, the accessible implementation combines an aria-hidden canvas element with the previously described hidden data table right below it in the DOM. It's also important that any color coding in the chart, say red for a price increase and green for a price decrease, gets repeated textually in the alt text or trend summary, so the information isn't conveyed exclusively through color.
Such a setup can be fully implemented using the existing chart library plus supplementary HTML, without needing a separate accessibility library on top, which matters especially for Hyva projects that deliberately aim for as lean a JavaScript footprint as possible.
7. Practical example: stock level visualization in the Magento admin
In the Magento backend, charts are usually part of a dashboard, say a bar chart of critical item stock levels by warehouse location. Unlike in the frontend, such charts address an internal specialist audience that needs to check the data regularly and under time pressure, which means the hidden data table isn't just an accessibility fallback here but also a valuable, compact alternative for sighted users relying on a screen magnifier or heavy zoom.
For admin dashboards it's also worth marking critical thresholds, say a stock level below the reorder point, not only with color as a red bar, but additionally with text or an icon, so administrators with color vision deficiency get the same critical information without relying on color perception.
8. Color coding in charts: contrast and redundancy
When several data series are distinguished exclusively through different colors, say several lines in a line chart, the distinction becomes impossible for users with color vision deficiency and for screen reader users alike, unless further coding is added. A robust solution always pairs color with a second, redundant visual feature, say different line patterns, markers at the data points, or direct labels at the end of each line instead of a separate legend.
Every color used in a chart should also carry sufficient contrast against the background, at least in the range of 3 to 1 for graphical elements per WCAG 1.4.11, since a chart with pale pastel colors on a white background can become hard to read even for users with no diagnosed vision impairment.
9. Testing: how to check chart accessibility with screen readers
The most practical test method is navigating through the chart area with the monitor turned off, or eyes closed, using only NVDA or VoiceOver, and checking whether the chart's core message can be followed without visual perception at all: is the title announced correctly, can the hidden table be reached, and does the screen reader read out a meaningful trend summary when entering the figure element.
An automated check with axe-core or a comparable tool is worth adding on top, since it reliably catches at least basic technical errors like a missing figcaption or an aria-hidden set on a focusable element, even though the content quality of a trend summary ultimately remains a matter of manual judgment. The table below compares the patterns covered here.
| Pattern | Solves which problem | Effort | Use case |
|---|---|---|---|
| Hidden data table | No access to individual data points | Medium | Every complex chart with multiple data points |
| aria-describedby trend text | No core message on initial focus | Low | Supplement to the data table |
| figure and figcaption | No semantic wrapper and title | Low | Baseline for every chart |
| details and summary | Optional expansion of raw data | Low | Admin dashboards with many charts |
Mironsoft
WCAG audits, accessible Magento shops, and training
Not sure whether the shop is actually accessible?
We audit existing Magento shops against WCAG 2.2, fix concrete barriers in the Hyvä frontend, and train teams so accessibility stays anchored in the development process for good.
WCAG Audit
Systematically review the shop against WCAG 2.2 AA, with a prioritized issue list.
Fixing Barriers
Concrete implementation: keyboard operability, screen reader support, contrast, forms.
Team Training
Raise developer and editor awareness for accessible implementation day to day.
10. Summary
Accessible Charts: The Essentials at a Glance
Core problem
A single alt text can't convey a chart's trend, outliers, and raw data all at once.
Most robust solution
A hidden, semantically complete data table containing the same raw data as the chart.
Fast addition
A short summary linked via aria-describedby, containing concrete numeric values.
Color rule
Never use color as the only coding, always pair it with a pattern, marker, or label.