GrSteps

The root is a <nav> with an <ol> list, and there are no roles on the items at all. role="tab" is not applicable here: a tablist without a tabpanel is a broken pattern, and the panel of a step carries no role — it is ordinary markup of the application.

Hence the keyboard as well: every available step is a Tab stop of its own, and the arrows are not involved. The “a composite widget is one stop” rule concerns widgets that select a value (GrTabs, GrSegmented); steps are closer to GrBreadcrumbs and GrBottomNav, where every item is tabbed separately. The practical consideration is the same: the future steps are unavailable, and a ring of arrows would walk mostly over what is switched off.

Three states give three different pieces of markup:

The wizard has no panel and will not have one. In tabs it is justified by role="tabpanel" and the aria-labelledby pairing, while here the content of a step is an ordinary v-if in the consumer’s markup, and a separate component would add a second entity with a synchronised idBase for the sake of zero semantics.

<GrSteps v-model="step" :steps="steps" />

<GrForm v-if="step === 'delivery'" :model="form" :rules="rules">
…
</GrForm>

<GrForm v-else-if="step === 'payment'" :model="form" :rules="rules">
…
</GrForm>

GrSteps knows nothing about GrForm: it does not read its context and does not climb into its fields. The check is set by the application — into the gate that blocks the transition:

async function validateStep(from: string, to: string): Promise<boolean> {
  // Going back is always allowed: editing what is filled in must not run into validation.
  if (stepIndex(to) < stepIndex(from))
    return true
  return formRef.value!.validate()
}

A click on a step, next(), back() and goTo() go through the gate — everything the component initiates itself. A direct change of v-model from the outside does not go through it: that is already a decision of the application, and intercepting it would be a lie.

Three statuses are inferred from the position: before the current one it is complete, the current one is current, after it upcoming. The fourth, error, has nowhere to be inferred from: an error lives in the form rather than in the order of the steps. Set it yourself when a step has been passed but does not add up — otherwise the wizard cannot say “there are still errors on the second step”.

A step with an error does not count as the edge of what has been passed: with linear it will not let you go past it.

Going back is always allowed — returning to fix what was filled in is an edit rather than a circumvention of the rule. Forward — no further than the first unpassed one, but steps already passed that lie ahead remain reachable: mark them status: 'complete', and the user will be able to jump back to the step they came back from without going through everything again.

Seven steps do not fit into a side panel and do not fit onto a phone. variant="compact" shows the label of the current step, a counter and a bar instead of the strip. The bar is decorative (aria-hidden): the same thing has already been said by the text beside it and by a hidden live region, and a second progressbar in the tree would make a screen reader read the progress twice.

#label fills only the text block of a step: the label, the description and your own content beside them — a time estimate, a badge. The marker (the number, the tick, the icon) and the visually hidden state in words (”— has errors”, ”— complete”) stay with the component.

<template>
  <GrSteps v-model="step" :steps="steps" orientation="vertical">
    <template #label="{ step: item }">
      <span>{{ item.label }}</span>
      <small class="text-[var(--gr-muted-fg)]">{{ item.estimate }}</small>
    </template>
  </GrSteps>
</template>

#step replaces the item entirely — both the marker and the state. Then the slot renders them: the marker class for the status arrives as the markerClass prop, the state in words as stateText, and it must be printed visually hidden. Without it a passed step and a step with an error sound the same: the colour of the marker is not available to a screen reader.

• the component has no “Back” and “Next” buttons of its own. They are placed by the application from GrButton and call next()/back() through a ref: in a wizard they live in the footer, together with “Cancel” and “Save draft”, and drawing them inside the indicator would mean dictating the layout of the page;
• the component does not store the data of the steps — the model of the form is entirely yours;
• the horizontal strip does not scroll. Many steps in a narrow place is variant="compact" rather than a scroller half of whose stages are invisible.