---
title: "Results screen"
description: "One result, what it means and what happens next. Read in that order, by eye and by screen reader."
url: "https://opsinjs.pensievelabs.org/screens/results-screen"
source: "https://opsinjs.pensievelabs.org/screens/results-screen.md"
section: "Screens"
kind: "screen"
evidence: "opinion"
reviewed: "2026-09-20"
reviewer: "clinical"
implements: ["result-card", "range-bar", "value", "status-pill", "term", "care-card", "disclaimer-note", "relative-time", "card", "surface", "skeleton", "empty-state", "source-citation", "alert-banner", "metric-tile", "score-dial"]
implemented: true
---

> Elements written as `<PascalCase … />` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> `<StubNotice>` IS THE EXCEPTION, AND IT IS THE ONE TO READ. It is a
> paired element rather than a self-closing one, and the text between
> its opening and closing tags is prose an author wrote, reproduced
> below word for word. That prose is where this page says whether the
> component has been reviewed. Read the children, not only the
> attributes.

<PageTemplate kind="screen" />

## What this screen does [#what-this-screen-does]

Somebody has opened a result. They may have arrived from a notification, from a
list of results, or from a tile they tapped on the home screen. In the
notification case they may have been thinking about it since it arrived.

They want three things, in this order: **what is my number**, **where does it sit
relative to the range this test is compared against**, and **what, if anything,
do I do now**. The screen answers those three and then stops. The provenance,
the history and the boundary note are below the fold by design, because they are
context rather than answer.

**What this screen deliberately does not do.** It does not diagnose. It does not
rank the person against other people. It does not recommend a treatment. It does
not decide the clinical status: if a status is shown, a rule owned by the product
assigned it, and the screen is rendering that rule's output. And it does not put
an interstitial in front of a result the person has already chosen to open.
Softening the approach to a result is the job of the flow before this screen
([Result disclosure](../patterns/result-disclosure.mdx)), not of a barrier here.

## Composition [#composition]

<CompositionTree name="results-screen" />

The proposed part hierarchy, with the material rung each surface sits on. Rungs
are given by position rather than by name so that this page cannot drift from
[The ladder](../foundations/materials/the-ladder.mdx), which names them.

```text
ResultsScreen                          page ground
├── Header                             page ground
│   ├── BackControl                    returns to where the reader came from
│   └── Title                          the test, in the reader's words
├── ResultCard                         one rung above the page
│   ├── Value                          the largest element on the screen
│   ├── RelativeTime                   when it was measured, not synced
│   ├── RangeBar
│   │   ├── Band                       one continuous shape, no coloured zones
│   │   ├── Marker                     distinct by shape, not only by colour
│   │   └── Endpoints                  numbers and the sentence that says them
│   ├── StatusPill                     only when a rule assigned a status
│   └── Summary                        the sentence carrying the whole meaning
├── MeaningSection                     page ground
│   ├── Term                           plain-English expansion, inline
│   └── Prose                          what this does and does not mean
├── CareCard                           one rung above the page
│   ├── Action                         one action, specific
│   └── Timing                         by when, and what if not
├── ProvenanceSection                  page ground
│   ├── Source                         who measured it, on what
│   └── DateTime                       absolute, not relative
└── DisclaimerNote                     page ground, lowest emphasis
```

<Todo>
  This composition names 

  `source-citation`

  , which has no component on the
  roster yet. Until it lands, a team building the provenance section writes the
  source and the instrument as plain prose the product supplies, rather than
  composing a component that does not exist.
</Todo>

Three composition rules this screen exists to demonstrate:

**The card is the only surface off the page ground.** Elevation is meaning here:
exactly the result and the action are lifted, so that lifting reads as "this is
the answer" rather than as decoration. A screen where every section is a card has
no hierarchy left to spend.

**CareCard is conditional, not decorative.** It appears when there is a real
action with real timing, and is absent otherwise. A permanently present card with
"no action needed" in it teaches the reader to skip the position where the real
action will one day be.

**One status pill, or none.** The status never colours the card, the band or the
marker. See [The two colour axes](../health/two-colour-axes.mdx). If no clinical
rule assigned a status, the screen shows no status and no colour stands in for one.

## Preview [#preview]

<IframePreview kind="screen" name="results-screen" />

The specimen above is assembled entirely from parts that already ship: ResultCard
as the answer, Term for the one word that needs expanding, CareCard for the single
next step, RelativeTime carrying the absolute measurement instant in the provenance
line, DisclaimerNote to close the surface, and Surface as the ground beneath them.
Card is not a ground the specimen places: it arrives as a registry dependency of
CareCard, which is built on it. The frame renders at phone, tablet and desktop
widths (390, 744 and 1180 pixels) so the reading order and the one-status-pill rule
can be checked against something rendered rather than argued from prose. One part of
the composition is not a component: `source-citation` has no code on the roster, so
provenance appears here as a plain paragraph the product writes, exactly as the
ResultCard demo already renders it.

## Safety notes [#safety-notes]

* **A result with no range is not a result with an empty bar.** When no reference
  range applies, the screen says so in words and omits the bar entirely. An empty
  bar reads as a missing result.
* **Out of range is a position, never a verdict.** The summary sentence describes
  where the value sits. It does not say *abnormal*, *high risk* or *bad*, and
  system-wide it does not say *normal*. See
  [Reference ranges](../health/reference-ranges.mdx).
* **One measurement is not a trend.** Nothing on this screen may imply direction
  from a single point. Where history exists it belongs on the
  [trends screen](./trends-screen.mdx), reached from here rather than inlined as
  an arrow.
* **Provenance is not optional for a device reading.** Who measured it and with
  what changes how much weight it can bear, and the screen must be able to say so
  rather than presenting every number as equally authoritative.
* **The value and the range are in the same unit, from one conversion at the edge
  of the system**. [Unit systems](../health/unit-systems.mdx) covers this. A
  view-layer conversion is how a screen shows a value and a band that disagree.
* **Stale is stated.** If the result is old enough that the reader might otherwise
  take it as current, the screen says when it was measured in absolute terms and
  de-emphasises it, rather than continuing to present it as news.
  [Uncertainty and staleness](../health/uncertainty-and-staleness.mdx) sets the
  rule.
* **The screen never animates the value into place.** A number counting up is
  unreadable while it moves, and the movement suggests significance the number may
  not have. See [Motion in health UI](../health/motion-in-health-ui.mdx).
* **The disclaimer is placed by rule**, in the same position on every result
  screen, so that it is findable rather than merely present.

## Accessibility [#accessibility]

**Landmarks and headings.** One `main` landmark, and one H1 that names the test.
The result, the meaning, any action and the provenance are H2s in that order. The
heading outline read on its own is a usable summary of the screen.

**Focus on entry.** Focus lands at the start of the main content, on the heading
that names the test. It does not land on the back control, and it does not land
on the first interactive element inside the card. A reader arriving from a
notification should hear what they opened before they hear how to leave it.

**Reading order matches visual order.** The order is title, value with unit,
measurement time, range and position, summary sentence, meaning, action,
provenance, boundary. This is the check the screen is most likely to fail: a card
that visually leads with the number but places the status pill first in the DOM
announces a verdict before the fact.

**The bar is an enhancement over a sentence.** Everything the RangeBar conveys is
in the summary sentence: the value, the unit, both endpoints, and where the value
sits between them. A reader who never perceives the graphic loses speed and
nothing else.
[Alt text and descriptions](../content/alt-text-and-descriptions.mdx) covers it.

**Colour independence.** The marker is distinguishable from the band by shape and
contrast; the status is a word and an icon before it is a colour. Verified in
greyscale and under all three simulated colour-vision deficiencies.
[Colour independence](../accessibility/colour-independence.mdx) is the rule.

**Contrast.** Every pair on the card is measured against the published floor in
both themes, including the marker against the band, which is the pair most likely
to fail.
[Contrast conformance](../accessibility/contrast-conformance.mdx) sets the floor.

**Text at 200%.** The card reflows; the value never truncates and its unit never
wraps away from it; the bar may give way to the sentence.
[Text resizing and zoom](../accessibility/text-resizing-and-zoom.mdx) governs
that.

**Terms are reachable by keyboard.** A [Term](../components/term.mdx) expansion
that depends on hover is unavailable on touch and to keyboard users, and this
screen is where unfamiliar words concentrate.

**Reduced transparency and reduced motion** both hold: the card falls back to its
opaque rung with the contrast floor intact, and the screen presents complete with
no entrance animation carrying meaning.

## Status [#status]

<StubNotice
  name="results-screen"
  status="shipped"
  issue="prashantonomy/opsinjs#0"
  questions="[
  &#x22;What does the screen render when a reference range exists for the test but not for this person's age or sex?&#x22;,
  &#x22;Where does provenance go when the reading came from a consumer device rather than a laboratory, and what may the screen assert about its accuracy?&#x22;,
  &#x22;If the product's clinical rules assign no status, does the screen show an explicit 'no assessment' state or nothing at all?&#x22;,
  &#x22;What is shown when the result arrives before the summary sentence that explains it has been written?&#x22;,
]"
>
  Everything on this page renders. Nothing here is a new component: the preview above
  arranges parts that already ship into the composition this page specifies, so the
  three screen-level checks have something real to run against. What is unproven is
  the composition rather than the components. The arrangement, its refusals and its
  accessibility bar are a proposal, and the questions below are still open. Every
  opsinjs component has now been audited against WCAG 2.2 AA by its authors, in a
  static source pass and a rendered pass, but that audit is not an independent
  review, and no component has had a clinical review yet
  ([ADR 0025](../project/decisions/0025-the-audit-is-author-run.mdx) records the
  reach and the limits of it). Do not put this screen in front of a patient. Do copy its refusals, because those are the part
  worth carrying into product code. The specimen lives under `registry/screens/` and
  is not served from `/r`, so there is no `shadcn add` for it.
</StubNotice>
