Accessible Chart Summary
Say in words what each chart shows, and let people read the numbers behind it.
What it adds
A short generated description and an equivalent data table attached to every chart the app renders.
What your agent is told to do
5
What your agent is told to do
5-
1
For each chart type in the app, define a summary template stating what is measured, over what range, and the one or two facts that matter — the overall direction, the extremes, and anything conspicuous — filled from the same data the chart draws from.
-
2
Attach the summary as the chart's accessible description and render it visibly beneath or beside the chart, since a plain sentence saying what the picture shows helps every reader, not only screen reader users.
-
3
Offer the underlying data as a real table reachable from the chart, sorted and formatted as the chart presents it, with units and the same rounding.
-
4
Regenerate the summary and the table whenever the chart's inputs change — a filter, a date range, a comparison toggle — and make sure the visible chart and its description can never disagree.
-
5
Do not describe the encoding instead of the data. A summary that says a bar chart with five bars in blue is useless; visual encoding, colour, and pattern are owned by Chart Color Tokens, and this brief owns the meaning.
Edge cases it handles
7
Edge cases it handles
7- The summary must describe the trend without asserting more than the data supports — no causation, no forecast, and no calling a two-point difference a trend. Where the movement is within noise, say the values are broadly flat.
- The data table is the real alternative and must be genuinely equivalent: proper header cells, the same units and precision as the chart, and a caption naming what it contains, not a visually hidden dump of numbers.
- Summaries computed once at render go stale the moment a filter is applied, leaving a description of data no longer on screen; tie regeneration to the same input the chart consumes.
- Reading every data point aloud by default is worse than saying nothing useful — a hundred-point series produces an unlistenable wall of numbers. Summarise by default and put the full detail in the table the user opts into.
- Empty, single-point, and all-zero series need their own phrasing rather than a summary that reads as though something were plotted.
- Missing or partial periods must be named in the summary, because an apparent decline that is really an incomplete final month is a misleading statement of fact.
- The summary is generated text and must be localised and formatted for the user's locale, including number, date, and currency conventions.
Definition of done
8
Definition of done
8- Every chart in the app has a text summary exposed as its accessible description and visible on the page.
- Every chart has an equivalent data table with proper headers, units, and a caption.
- Summaries state direction and extremes without claiming causation or forecasting.
- Changing a filter or range updates the summary and the table in the same pass as the chart.
- Empty, single-point, and incomplete series produce accurate, distinct wording.
- Full point-by-point detail is available on request and is not read by default.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Data Table Cell Primitives
Data Table Cell Primitives
Render every kind of table cell the same way, wherever the table happens to be.
What it does
A shared set of cell renderers for numbers, dates, people, statuses, links, and row actions, used by every table in the app.
How it works
- 1 Catalogue the cell types the app's tables already render and reduce them to a small set: number and currency, date and relative time, person or avatar, status or badge, link or identifier, and an actions cell.
- 2 Separate each cell's underlying value from its presentation, so sorting, filtering, grouping, and export operate on the raw value while the user sees the formatted one.
- 3 Align and format numerically consistent cells the same way everywhere — figures right-aligned with tabular figures and a fixed precision per column, dates in the user's locale and time zone, currency with its code where more than one is possible.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/data-table-cell-primitives
Segment Event Forwarding
Segment Event Forwarding
Send one clean stream of product events to Segment and let it fan out downstream.
What it does
A documented event schema and a single forwarding path emitting track, identify, group, and page calls with consistent identity.
How it works
- 1 Write the event schema before writing any code: the exact set of event names, the properties each carries with their types, and the traits attached to a user and to an account. Every downstream tool inherits this schema, so a name chosen carelessly is expensive to change later.
- 2 Establish one identity model and apply it everywhere. Use a stable internal user identifier that never changes, associate the anonymous identifier from the first visit with it at signup, and attach the account or workspace so downstream tools can roll events up by customer.
- 3 Route every event through one internal emitter rather than calling the provider from feature code. That emitter validates the event against the schema, drops or flags anything unrecognised, and is the single place where identity and default properties are attached.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/segment-event-forwarding
Google Analytics Server Events
Google Analytics Server Events
Report confirmed outcomes to Google Analytics when browser tracking cannot be trusted.
What it does
Server-side delivery of completed conversions to Google Analytics, joined to the browser session and deduplicated against it.
How it works
- 1 Identify the outcomes the browser cannot see or reports unreliably — a payment confirmed by a webhook, a subscription that renewed, a signup completed after a redirect, anything blocked by an ad blocker — and send those from the server.
- 2 Capture the analytics client identifier from the browser when the visit begins, store it against the session or the record, and send it with the server event so the conversion joins the same session and campaign rather than appearing as a new anonymous visit.
- 3 Generate a stable event identifier at the moment the outcome happens and use it for both the browser and the server send, so the provider can collapse the pair into one event. Assign each event type a primary origin and treat the other as the fallback.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/google-analytics-server-events
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.