Accessible charts for real users

Someone pastes a screenshot into Slack: three lines on a trend chart, red for “bad,” green for “good,” no legend that survives a dark mode client, and the message “we need to move.” Half the channel cannot tell which line is which without squinting. One person is color-blind. Another is on a phone. A third is listening to the deck later through a screen reader description that says only “image.” The decision still happens. The chart just failed as a shared fact.

This is Part 1 of Inclusive data products, a short series about building analytics that real people can use: different vision, devices, languages, and levels of chart literacy. Inclusive design is not a nice-to-have skin on a pretty dashboard. It is how you stop lying by accident to part of your audience.

What you’ll learn

What “accessible chart” means for analysts shipping BI, slides, and notebooks
The non-negotiables: not color-only encoding, labels, contrast, and alt text
How to redesign a red/green-only chart without losing the business story
A short A11y checklist you can run in under ten minutes
Where accessibility meets metric honesty and the rest of this series

Accessible charts are about shared facts, not perfection

Accessibility (often shortened to A11y, “a” + 11 letters + “y”) is the craft of making products usable by people with a wide range of abilities and situations. For charts that means: someone with color vision deficiency can still decode series, someone with low vision can read labels, someone using a keyboard or assistive tech can get the same takeaway as a mouse user, and someone skimming a PDF export is not stuck with a blur of tiny type.

You do not need a legal review on every sparkline. You do need a habit: if the only way to understand the chart is perfect vision, a large monitor, and the legend colors you memorized last week, the chart is not ready for a decision room.

Inclusive charting also helps everyone. Direct labels reduce legend hunting. Strong contrast helps projectors. Pattern or shape encoding helps grayscale printouts. Clear titles turn “pretty” into “usable.” The same discipline that makes a chart accessible makes it faster for busy executives.

Rule of thumb: If you print the chart in grayscale and the story disappears, you never had a story. You had decoration.

The four basics: not color-only, labels, contrast, alt text

Start with a simple do / avoid frame. You can hang this next to your laptop.

Accessible chart basics: Do not color-only, labels, contrast, alt text. Avoid red/green only, 3D pie, tiny type

1. Not color-only encoding

Color is powerful. Color alone is fragile. Roughly 1 in 12 men and 1 in 200 women have some form of red-green color vision deficiency. Many more people view charts on washed-out projectors, night mode screens, or photocopied packs. If series A is only “the blue line” and series B is only “the orange line,” you are gambling that every viewer can separate those hues under real lighting.

Fix it with a second channel:

Shape: circles vs squares vs triangles on points
Line style: solid, dashed, dotted
Pattern: hatches on bars or areas (use sparingly; clutter is real)
Direct labels: name the series on the chart, not only in a legend
Position or order: sort bars so ranking is visible without color

Status colors are the classic failure mode. “Red = missed target, green = hit target” feels intuitive until two rows both look muddy brown to someone with deuteranopia. Prefer icons, words (“miss” / “hit”), or a single hue scale with clear labels. If you keep red/green for brand reasons, add a non-color cue every time.

2. Labels that survive the real world

Axis titles, unit labels, and series names are not optional footnotes. They are the chart’s sentence structure. A bar chart of “42, 38, 51” without a y-axis unit is a Rorschach test. “Revenue ($ thousands)” or “Active accounts” turns ink into a claim someone can challenge.

Practical label habits:

Put the unit in the axis title or subtitle, not only in a hover tooltip
Prefer direct labels on the last point of a line or on short bar series when density allows
Write a takeaway title when the chart is for a decision (“North region missed plan by 8 pts”) instead of a generic noun phrase (“Revenue by region”)
Keep tick labels large enough that a back-row viewer can read them; if they cannot, simplify the chart

Tooltips are a gift for exploration and a trap for accessibility. Keyboard and many assistive tech paths do not get the same hover experience. Anything essential must appear in the static view: title, labels, footnote, or companion table.

3. Contrast that works on real screens

Low-contrast gray-on-cream looks “modern” in a design tool and vanishes on a conference room wall. WCAG contrast guidance for text is a useful north star even when your BI tool is imperfect. Aim for dark text on light backgrounds (or the reverse) with enough separation that thin gridlines do not compete with the data marks.

Contrast tips that analysts control without a design system:

Avoid light gray text for axis labels; use near-black or a dark slate
Do not place white text on pastel fills
Prefer fewer, stronger series colors over a rainbow of pastels
Test the export as a PNG at presentation size, not only the interactive dashboard zoom
Watch dual-axis charts: two pale lines against a busy grid is a contrast tax on everyone

4. Alt text and non-visual access

When a chart is an image (slide export, blog post, email, Notion paste), alt text is the accessible equivalent of the visual. Good alt text is not “chart of sales.” Good alt text is a short statement of the takeaway plus the key comparison: “Bar chart: Q3 revenue by region. West $4.2M leads; East $2.1M lowest; West is about 2x East.”

For interactive dashboards, pair the visual with a data table view or downloadable CSV when the tool allows it. Screen reader users and many power users both benefit. If your stack cannot expose a table, write a one-sentence caption under the chart in the dashboard text box. Captions travel better than tribal knowledge.

Keyboard access matters too. If critical filters only work via drag gestures, document a fallback path (URL parameters, filter pane, default views). You will not fix every vendor gap in one sprint. You can stop shipping “mouse-only insights” as if that were neutral.

Chart types that fight accessibility

Some chart choices make inclusion harder by design. You can still use them carefully, but they need extra scaffolding.

3D pies and decorative depth

3D pie charts distort area and make comparison hard even for people with excellent vision. Skip them. If you need parts of a whole, use a simple 2D pie or donut with large labels, or better, a horizontal bar sorted by size. Accessibility and accuracy usually want the same redesign.

Tiny type and dense dashboards

“Twelve charts on one screen” is a density flex that fails on laptops and fails harder on phones. Prefer fewer views with readable type. Use drill-through or linked pages instead of microscopic multiples. If leadership insists on the wall of charts, at least make the KPI tiles high contrast and give each chart a plain-language title.

Rainbow sequential scales and diverging misuse

Rainbow scales look scientific and often encode poorly for color-deficient viewers. Prefer sequential single-hue ramps or carefully tested multi-hue scales designed for data (for example perceptually ordered palettes from established viz research). Diverging scales need a meaningful midpoint, not a decorative center white that hides the interesting values.

Dual axes without dual honesty

Dual axes can mislead even when colors are perfect. If you use them, label both axes loudly, keep series styles distinct (not only hue), and consider two small multiples instead. Accessibility problems and chart-crime problems often travel together. Fixing one often improves the other.

Worked example: redesign a “traffic light” KPI chart

Imagine a weekly ops review. Product managers track feature adoption for three cohorts: free trial, paid self-serve, and enterprise. The first chart is a line chart with three series in red, yellow, and green only. Title: “Adoption.” No units. Legend is a color key. Hover shows exact percentages. Leadership wants to know whether enterprise is recovering after a pricing change.

Problems stacked:

Color-only series encoding
Red/green “status” vibes even though lines are just cohorts, not good/bad
No unit or definition of “adoption”
Essential values only in hover
No alt path for exports to slides

Redesign steps you can do in Tableau, Power BI, Looker, or matplotlib:

Define the metric in the subtitle: “Weekly active accounts that used Feature X at least once / accounts eligible that week.”
Rename series with full words: Free trial, Paid self-serve, Enterprise.
Use solid / dashed / dotted lines plus three high-contrast hues that are not red-vs-green status coding.
Direct-label the end of each line with the latest week’s percentage.
Write a takeaway title: “Enterprise adoption still 6 pts below paid self-serve after pricing change.”
Add a small table under the chart with the last four weeks for each cohort (or enable the tool’s data table view).
When exporting to slides, paste a one-sentence caption that could stand alone as alt text.

Here is a lightweight checklist you can fill in the PR or review notes when a dashboard changes.

A11y checklist table with rows for pattern or label, keyboard or table alt, and color blind safe

Filled example for the adoption chart:

Item	Pass?	Note
Pattern or label	Yes	Line styles + end labels
Keyboard / table alt	Yes	Data table tab enabled
Color blind safe	Yes	No red/green status encoding
Contrast	Yes	Dark labels, tested on projector
Alt / caption on export	Yes	Takeaway sentence in slide notes

You can also sketch the same idea in code when you own the rendering. The point is not the library. The point is a second encoding channel and explicit numbers.

# Conceptual: plot three cohorts with linestyle + marker, not color alone
import matplotlib.pyplot as plt

weeks = list(range(1, 9))
free =  [12, 14, 15, 16, 17, 18, 18, 19]
paid =  [28, 29, 30, 31, 32, 33, 34, 34]
ent =   [22, 21, 20, 21, 22, 24, 25, 26]

fig, ax = plt.subplots()
ax.plot(weeks, free, linestyle="-",  marker="o", label="Free trial")
ax.plot(weeks, paid, linestyle="--", marker="s", label="Paid self-serve")
ax.plot(weeks, ent,  linestyle=":",  marker="^", label="Enterprise")
ax.set_xlabel("Week")
ax.set_ylabel("Adoption rate (%)")
ax.set_title("Enterprise adoption still below paid self-serve")
ax.legend()
for y, name in [(free[-1], "Free"), (paid[-1], "Paid"), (ent[-1], "Ent")]:
    ax.annotate(f"{y}%", (weeks[-1], y))
plt.show()

What that pattern buys you: a grayscale printout still shows three distinct series. A color-blind viewer can use marker shape. A screen-reader-friendly export can quote the title and the annotated values. None of that required a special “accessibility product.” It required refusing color-only storytelling.

Process: when accessibility enters the analytics workflow

If you only audit charts the night before an all-hands, you will always ship something fragile. Build a lighter habit into normal delivery.

Definition time: When you name a metric, also name how it will be shown (unit, comparison, grain). Accessible charts start with clear metrics. See the metrics series if your team still argues about titles after the viz is built.
Draft time: Grayscale test + phone screenshot + one colleague who was not in the build meeting.
Review time: Checklist rows for pattern/label, table alternative, color-blind safety. Same seriousness as a SQL peer review.
Publish time: Caption or alt on anything that leaves the BI tool (slides, Notion, blog, email).
Incident time: If someone misreads a chart in a decision, treat it like a data quality bug: fix the encoding, not only “align offline.”

Quality culture already cares about freshness and correctness. Inclusive viz is quality of communication. It belongs next to the data quality habits you already teach: if people cannot parse the chart, the number did not land.

Tool constraints without fatalism

Not every BI platform makes patterns easy. Some default palettes are hostile. Some “auto” charts love dual axes and tiny legends. Work inside constraints:

Create a team palette that is tested for common color deficiencies and ban one-off rainbows
Standardize templates with larger fonts and required subtitle fields for units
Prefer chart types your tool labels well (bars and lines with markers) over flashy customs
When the tool cannot hatch bars, use position + label harder (sorted bars, direct values)
Document known gaps in a short “dashboard accessibility” note so reviewers know what to compensate for

If you are choosing a new stack, ask vendors about data tables, keyboard navigation, high-contrast themes, and export options. Buying decisions are inclusion decisions, not only license math.

Common mistakes

Red/green only for status. Add text, icons, or shape. Status is a claim, not a hue.
Legend as the only decoder. Legends fail under crop, print, and color issues. Direct labels help.
Essential facts only in hover. Static viewers and many assistive paths never see them.
3D pies and chart junk. They harm accuracy and accessibility together.
Tiny type to fit more charts. Fewer readable charts beat a wall of illegible ones.
Alt text as filename. “image.png” is not a takeaway. Write the comparison.
Assuming “everyone on our team can see fine.” Teams change. Stakeholders change. Exports leave the room.
Treating accessibility as a design-only task. Analysts choose encodings every day. Own that choice.

How to practice this week

Pick one chart you own that uses color as the primary series decoder.
Export it, convert to grayscale (or print black and white), and write what is still clear vs lost.
Add one non-color channel (line style, markers, direct labels, or sorted bars with value labels).
Write a one-sentence takeaway title and a one-sentence alt/caption.
Enable or attach a data table for the same numbers.
Run the three-row A11y checklist (pattern/label, keyboard/table alt, color-blind safe) and store the note next to the dashboard.

Next in this series: inclusive metrics and whose story is missing from the number itself. Charts can be perfectly labeled and still leave people out of the metric definition. For broader skills paths, start at Learn.

Quick recap

Accessible charts make the same fact available across vision, device, and assistive tech constraints.
Never rely on color alone; pair hue with shape, pattern, line style, order, or labels.
Labels, units, and takeaway titles are accessibility features, not decoration.
Contrast and font size must survive projectors, phones, and exports.
Alt text and data tables carry the takeaway when the picture cannot.
A short checklist in review is enough to stop most avoidable chart exclusion.

Sources

W3C Web Accessibility Initiative. WCAG 2 overview (contrast, non-text content, and operable interfaces). https://www.w3.org/WAI/standards-guidelines/wcag/
W3C WAI. “Complex images” and text alternatives guidance (how to describe charts and graphs). https://www.w3.org/WAI/tutorials/images/complex/
WebAIM. Contrast Checker and articles on color and contrast. https://webaim.org/resources/contrastchecker/
ColorBrewer. Color advice for cartography and sequential/diverging schemes useful beyond maps. https://colorbrewer2.org/
National Eye Institute. Color blindness overview (prevalence and types in plain language). https://www.nei.nih.gov/learn-about-eye-health/eye-conditions-and-diseases/color-blindness
Tableau Help. “Author views for accessibility” (vendor-specific patterns; principles transfer). https://help.tableau.com/current/pro/desktop/en-us/accessibility_authoring.htm