Component reference

OELTKit’s interaction components are plain custom elements (<oelt-*>) — no framework, no build step. Drop one into a page’s HTML and it auto-wires to the tracking runtime; you write no tracking code in the markup.

Every component page documents the same five things:

Markup — the exact element an LLM writes.
Attributes — the configuration surface.
Keyboard map — how it’s driven without a mouse.
Screen-reader behavior — what’s announced, and when.
Tracking events — what it reports through the runtime.

The shared contract

Every component emits a single oelt-interaction event that the runtime forwards to oelt.track.interaction(...); you never call the LMS API yourself. The payload is:

{ id, type, result, score?, response? }

id equals the element id (and the manifest interaction id); result ∈ passed | failed | completed; score is 0–1 where applicable. Components emit their own result and never aggregate — except <oelt-quiz>, which rolls its children into one weighted score.

All components are themed through --oelt-* design tokens and named ::part()s, persist state through oelt.state (within the shared 3 KB suspend budget), prefer native elements over ARIA, are fully keyboard-operable, and respect prefers-reduced-motion.

The launch set

Component	Type	What it does
`<oelt-mcq>`	`choice`	Single- or multiple-answer question
`<oelt-branching>`	`sequencing`	Decision scenario from a JSON node graph
`<oelt-media>`	`media`	Accessible video/audio with enforced captions or transcript
`<oelt-text-entry>`	`fill-in` / `numeric`	Short text or numeric free response
`<oelt-quiz>`	`performance`	Container that aggregates child questions into one weighted score
`<oelt-likert>`	`likert`	Rating scale for surveys (never scored)
`<oelt-ordering>`	`sequencing`	Reorder items into the correct sequence
`<oelt-matching>`	`matching`	Match values to prompts (one per target)
`<oelt-categorize>`	`matching`	Sort items into category buckets (many per bucket)