This component will be used to navigate within Onboarding Dialog stepps, but it could be also used to navigate within a table pagination or within different images in an image gallery. So we have 2 different use cases:

1. Stepper: horizontal steppers are often used to guide users through a multi-step process, like the one in the Onboarding Dialog.
2. Navibale bullets: navigation controls that allow the user to move forwards and backwards through the sequence (e.g. image gallery or pagination in a table). It typically includes navigable arrows or bullets.

Is this Stepper component navigable or is it just a visual representation of the steps in a process?

What are the arguments for building this component? Growth has created an initial implementation in OnboardingPaginator.vue. My perception is that this component is quite complicated to abstract and make valid for several use cases. The main reasons I see are:

• Its positioning is always relative to another element
• Its color and background color may vary based on the surface it is placed.
• Tightly coupled with translated text

In T333584#8742673, @bmartinezcalvo wrote:

Is this Stepper component navigable or is it just a visual representation of the steps in a process?

Not sure if I understood the question, but if it refers to the bullets being clickable, I find them too small. Do we have an specification for the minimal size of clickable icon-only elements? 32pxx32px?

@Sgs Thanks for raising these points! I think we can narrow down the potential features of this component to a minimum viable product that will work for the onboarding dialog and be extendable in the future if we need to add more features to support more use cases.

The stepper component could take in these props:

• modelValue (number) - the current step
• totalSteps (number) - the total number of steps
• label (string) - textual representation of the steps, e.g. "1 of 3"

The label, as you mentioned, is tricky - in MW we'll have to use a message with params for the current step number and total number of steps. We could set something like this up in Codex as well, so that you can just pass in the structure of the text (in English, "%1 of %2"), but that seems unnecessary for MVP and wouldn't be useful inside MW since we have the Messages API. At least at first, we could just require the user to pass in the full string ("1 of 3") since the parent component will already be aware of both numbers.

In terms of positioning, I think it's acceptable that this component will need to be positioned by the parent—this is true of other components as well (e.g. inline progress bar), and we can develop the component in isolation and then show examples of it in context.

For MVP, we could implement one color palette, then expand on that in the future if needed.

If we do want the bullets to be clickable, they could just emit the update:modelValue event with the step number associated with that bullet to change the modelValue. But I agree that they are too small to be relied upon for navigation. Maybe we can suggest that people create a primary way to navigate through steps other than the bullets (e.g. the navigation buttons at the bottom of the onboarding dialog)? Then we can enable navigation by clicking the bullets for anyone who expects that and wants to use them.

All above sounds like a good plan for a MVP.

As per the label I was not suggesting is a bad thing to have it as a prop, just "annoying" in case one would want to customize the positioning of the label relative to the dots. Personally, I would leave the text out of the component and let consumers place it where they want. But an optional label seems also reasonable.

In T333584#8836742, @AnneT wrote:

Then we can enable navigation by clicking the bullets for anyone who expects that and wants to use them.

This makes me wonder about a11y requirements. Should we backup the dots with some specific aria attributes or a title? Also, if click navigation is supported, should we support keyboard arrow navigation?

In T333584#8837094, @Sgs wrote:

This makes me wonder about a11y requirements. Should we backup the dots with some specific aria attributes or a title? Also, if click navigation is supported, should we support keyboard arrow navigation?

Good point - ARIA + keyboard nav both seem necessary, although I'm not 100% sure about the details yet (maybe the WAI carousel pattern would be a good place to start). Tagging @Volker_E as well.

I find this specification counter intuitive in the sense that the dots size is fixed while the font-size is relative. This lead to a different relation of elements sizes in desktop vs mobile:

Is the different ration between platforms intended? Maybe the dot specification should be expressed with a "font-size" token so the font and dot size ratio remains equal in different platforms and zooming levels?

In T333584#9000653, @Sgs wrote:

I find this specification counter intuitive in the sense that the dots size is fixed while the font-size is relative. This lead to a different relation of elements sizes in desktop vs mobile:

Element	MW root font	Dot @size-50, 8px	Font size @font-size-small, 0.875em	ratio dot—font
desktop	14px	8px x 8px	12.25px x 12.25px	0.653
mobile	16px	8px x 8px	14px x 14px	0.571

@Sgs as specified in the Figma spec, the Stepper will use 14px font size on both desktop and mobile platforms. So the dots will also be the same size on both platforms.