Research Trail Footer

When to use Research Trail Footer

Use Research Trail Footer at the foot of a documentation-wiki article to disclose its research trail — the three fixed subsections Research done, Suggested research, and Open questions. It is the article-scale rendering of the same discipline every DESIGN-DRAFT and wiki draft already carries in frontmatter: it takes the three research-trail fields a draft must declare and turns them into a reader-facing, machine-readable block at the point where a reader has finished the prose and is deciding how much to trust it.

Place it at the bottom of the article, after See also and before References. It is a single element per article — not a general callout or a repeatable inline aside. If an article has no research trail to disclose, it should not render the footer at all (see Suppressed below), rather than render an empty one.

This component is part of the Knowledge Platform surface — it renders the epistemic-honesty convention that platform expects of every article, at article scale.

Variants

The three variants are states of one article's footer, selected at render time — not styling options an author picks per instance.

Anatomy

The footer is a native <details> / <summary> pair — no JavaScript. The browser owns the collapse behaviour, the keyboard interaction, and the expanded/collapsed state announced to assistive technology.

1. Summary — the always-visible line. It reads Research trail — N done · N suggested · N open question(s), and is the click and focus target that toggles the body.
2. Body — an aria-labeled section holding three fixed subsections in fixed order. Each subsection is an <h3> followed by a list:
   • Research done — sources already consulted (academic, primary, secondary).
   • Suggested research — work that should be done next to strengthen or verify a claim.
   • Open questions — questions the article does not yet answer.

Each subsection heading carries a coloured leading rule so the three categories are distinguishable at a glance: success for done, brand blue for suggested, warn for open (see Tokens).

Counts are render-time, not author-maintained

The three counts in the summary line are derived from the article's frontmatter fields — research_done_count, research_suggested_count, and open_questions_count — and substituted at render time. Authors do not hand-maintain the summary string, and it cannot drift out of step with the frontmatter it summarises. These are the same three research-trail fields the DESIGN-DRAFT and wiki-draft conventions require on every real draft; the footer is where that convention becomes visible to a reader on a live article.

Machine-readable output

Alongside the visible block, the footer emits JSON-LD potentialAction nodes: a SearchAction for each suggested-research item and a Question for each open-question item. This lets an LLM or other automated consumer identify an article's epistemic frontier — what is settled, what is suggested, what is open — without parsing the prose. The disclosure a human reads and the signal a machine reads come from the same source.

Tokens

Every colour, space, and type value is a token reference — the component holds no hard-coded values.

Accessibility

Target: WCAG 2.2 AA.

• Native semantics. The <details> / <summary> pair means the browser handles keyboard interaction (Enter and Space on the summary), the screen-reader announcement, and the aria-expanded state natively. There is no custom ARIA to keep correct and no JavaScript that can fail.
• Heading level. The three subsections use <h3> because the article's own ## Research trail renders as an <h2> — the footer slots correctly beneath it in the document outline rather than breaking heading order.
• Focus. The summary shows a visible focus ring on :focus-visible, drawn from semantic.interactive.focus-ring with a 2px offset, so keyboard users can see the toggle target.
• Colour is not the only signal. The three subsections are distinguished by their headings and order, not by the coloured rule alone — the rule is a reinforcement, so the categories remain unambiguous without colour perception.

When not to use

• Do not use it as a general-purpose callout or collapsible aside. It is a single, fixed, three-subsection article footer — for other disclosure patterns, use the substrate's generic disclosure primitives.
• Do not render it more than once per article, and do not reorder or omit the three subsections — the done / suggested / open order is fixed.
• Do not render an empty footer. An article with no research trail uses the Suppressed variant and renders nothing.