Making a health chart readable without the chart

Every health app draws a trend eventually. HRV over thirty days, sleep across the week, weight since January, training load against last month. The information in those views is not in the numbers; it is in the shape of the line. And the shape of a line is the one thing a screen reader cannot reach, because on most implementations the chart is a single drawn surface with no text in it at all.

The result is a view that is either silent or announces something like "image". A user who came to answer one question — is this going up or down — gets nothing, on a screen your product probably considers a headline feature.

There are two answers. Apple has an API for it, and there is a fallback that needs no API and works on any platform, which most apps should build first. This page is engineering guidance and makes no legal claims; law and store policy live in compliance.

What Apple documents#

Apple's audio graphs documentation opens with the instruction: "Define an accessible representation of your chart for VoiceOver to generate an audio graph." The overview explains why: "Charts and graphs help users quickly identify important features and trends in data. Use the audio graphs API to provide all the information that VoiceOver needs to construct an audible representation of the data in your charts and graphs, making the data accessible to people who are blind or have low vision."

Apple then begins a third sentence: "An audio graph turns the data in your chart into an audible representation by encoding". Our extraction ends mid-clause. We did not capture how Apple finishes that sentence and we are not going to guess at it, which means this page cannot tell you what the audio representation actually encodes or how it sounds.

That leaves a clear but bounded claim. On Apple's platforms there is a documented, first-party path for making a chart's data available to VoiceOver, and the work it asks of you is to define an accessible representation of your chart. We did not capture the type names or the method signatures for it in this pass, so there is no code sample on this page. Read Apple's page for the API surface rather than trusting a snippet we reconstructed from memory.

The Android gap, stated plainly#

We found no verified Android equivalent in this pass. Not "there is none" — we did not find and read a primary Google page describing an audio or sonified representation of chart data, so we have nothing to describe.

That is a real gap in the guidance, and it is worth being blunt about what it means for a cross-platform product. If you build only to Apple's audio graphs, your Android users get a silent picture. Any accessible-chart strategy that is going to hold across both platforms has to be built out of things you can write yourself. Which, conveniently, is where most of the value is anyway.

The fallback that works everywhere#

A chart's accessible description should be a sentence that answers the question the chart exists to answer. Four ingredients, and this is our editorial judgement rather than anything either platform prescribes:

Direction. What the series did over the window, in words. Rising, falling, flat, or too variable to call. This is the first thing a sighted user extracts and it should be the first thing the description says.

Range. The low and the high, with their dates. This is what gives the direction a scale — a resting heart rate that moved two beats is not the same story as one that moved fifteen.

Latest value. The most recent point, dated. Most people looking at a health trend are really asking about today.

Notable gaps. Days with no data, and how many. A flat line across a week the user did not wear the device is a lie, and it is a lie the visual chart tells too. Missing data is a first-class part of the story here — see missing data and gaps for what causes it.

Written out, one series produces something like this:

Heart rate variability, last 30 days. Trending down.
Range 38 to 71 milliseconds. Lowest on 14 August, highest on 2 August.
Latest 41 milliseconds, yesterday. No data on 4 days.

Three rules about that string, all ours. Generate it from the same data the chart renders, never write it by hand, or it goes stale the first time somebody changes the window. Keep the sentence order fixed across every chart in the app so a returning user knows where the number they want will be. And do not round it into meaninglessness: if the visual chart resolves one decimal place, so should the summary.

The table view#

The summary answers the shape question. It does not let anybody read the data. For that, give the chart a table alternative: rows of date and value, as real text, reachable by anybody, not just by a screen reader.

A table view is the most portable accessible chart there is. It needs no platform API, it works for a keyboard user and a magnification user as well as a screen reader user, and it is often the fastest way for anybody to answer a precise question. Our judgement is to expose it as an ordinary feature rather than an accessibility mode — a "view as table" control that is visible to everybody. Accessibility affordances hidden behind a detected assistive technology tend to be tested less and break more.

Say what the metric is, not just what it did#

A summary that says a number went down is only useful if the listener knows what the number is. Charts of derived metrics carry a second burden: the name is often an abbreviation, and the unit is often unfamiliar.

Our judgement: spell the metric out on first use in the description, name the unit, and link the explanation from the surrounding screen rather than cramming a definition into the chart's description. What each metric actually is, and which API it comes from, is the data cluster's job — what HRV is and what sleep stages are are the two most commonly mislabelled on a trend screen, and the sleep tracking API covers where the numbers originate.

What this page does not claim#

Three limits, stated so nobody has to infer them. We have not measured how an audio graph sounds or how any assistive technology handles a chart; everything above about Apple's API is what Apple's documentation says. We did not verify an Android counterpart, as above. And the summary format is our editorial judgement — no platform documentation we read prescribes direction, range, latest and gaps as the four ingredients. It is a format we think holds up, not a standard.

Monday morning#

Find every chart in your app and, for each one, write the sentence it should say out loud. That exercise alone will tell you which charts have a point and which are decoration. Then generate the sentence from the series instead of typing it, expose it as the chart's accessible description, and add a table view that everybody can open. Only after that is working is it worth reading Apple's audio graphs documentation for the platform-specific layer on iOS, because a good summary helps every user on every platform and the audio graph helps some users on one.