md-stepper component

Question

md-stepper component

thielpa opened this issue 9 years ago · 25 comments

@jelbourn Here is the component request issue for the MdStepper component with all information needed (hopefully).
Material Specs
There is already an issue in material1 with many upvotes.
So I begin now with a basic design doc.
BTW I already made parts of the component in the 48h of horror-coding (ng-attack) 😄

Answer 1 · 2016-05-24T15:49:44.000Z

@Lordnoname thanks for opening the issue. Here are some initial requirements / thoughts I have for the implementation:

It's effectively the same behavior as Tabs, so the two components should share as much code as possible, in addition to having a similar API surface. @robertmesserle recently committed the initial version of tabs. You can see the design doc here.
The stepper must be accessible for people using only a keyboard and screen-reader. I'm not sure how a stepper is generally presented from an accessibility context; this will likely require some research and experimentation. (cc @marcysutton)
Any text and ARIA labels need to be internationalized. Our current approach for this is to create a class named something like StepperLocale that's injected by the component that contains any locale-specific information and can be provided by the user (while we have a default implementation in en-US).
The labels for the steps should support any arbitrary template, similar to how the tabs support arbitrary templates for tab labels (in addition to supporting a straight text label property).
We probably want to support having the stepper part of the UI separate from the content (similar how we're going to support having the tab-bar and the tab-content in separate places).
While not necessary in an initial version, users should be able to set a custom icon for a step.
Avoid bundling any icons in the initial version- we're not quite settled on how we want to bundle icons into components yet.
As far as I can tell, the different flavors of stepper are are exactly the same behavior, just with different templates. This should probably be implemented as a single class that contains all of the logic, with child component classes that add no behavior and just include a specific template.
I'm thinking that the actual buttons to move between steps should be inside the step content with the stepper providing APIs to move between steps. This will be the most flexible approach to letting users do whatever they want with the component.

cc @hansl @kara @robertmesserle in case anybody has any further input on the stepper.

Answer 2 · 2016-05-27T19:34:21.000Z

There is a lot going on with this spec in terms of user interaction. I don't think it's as simple as "reuse tabs" for accessibility, particularly when you get into editable steps and mobile. Here are a few things I noted from looking at the design spec:

First off, ARIA tabs may work but they are only worth considering if the interaction isn't confusing for actual screen reader users. There has been a lot written about this pattern recently, I recommend reading up on it before implementing. Particularly, be aware that the tabs pattern requires one tab stop and the arrow keys/space bar to navigate, and that the content must make sense in tabpanels. The various mobile designs deviate the most from this.

Other random thoughts:

The label for the stepper icon button (which I believe takes focus, but I couldn't tell from the spec) must include the text to the right of it.
There is no "aria-optional" property, so you'll have to indicate something is optional with a localized string as part of the icon button. Basically you can't semantically require all tabs or make one optional. aria-required is for custom form controls.
If you do go with ARIA tabs, editable steps will have to be indicated with a text input, such as a native input or contenteditable element (with an accessible name). This will take some experimentation.
Error states will have to be indicated somehow. aria-invalid only works for form controls. I'm starting to notice a theme here: form controls may play a larger role (no pun intended)
Interactive content in inactive steps should be disabled/hidden (just like inactive Tabs)

Maybe they should be driven by radio buttons instead of tabs? It may require everything be wrapped in a form element to ensure screen readers enter forms mode, but it's worth considering for what you'd get for free.

Answer 3 · 2016-05-27T21:16:06.000Z

The first thing I thought when I looked at it was "nice breadcrumbs". If, in fact, those "steps" link to navigation routes using a tags, I think many of @marcysutton's concerns may get handled. How to make a "step" required may still cause issues but my first crack at it would probably involve a message (aria-live for screen readers) followed by the navigation to the required "step" route when needing to complete a skipped step and a warning when the user attempts to navigate away without completing a required step.

Answer 4 · 2016-05-30T17:05:26.000Z

@jelbourn @marcysutton Here is an initial version of the design doc i have written:
https://docs.google.com/document/d/1QBzoua3HgPdlTZHqOgWK2C5eJUygFZxW18LpYjQfkWM/edit?usp=sharing
Feel free to improve and add the final accessibility thoughts!

Answer 5 · 2016-06-06T16:33:56.000Z

Looking forward to this!

Answer 6 · 2016-07-10T21:02:33.000Z

hello, is ther a complete version now?

Answer 7 · 2016-10-05T18:22:38.000Z

@jelbourn @marcysutton Ping on reviewing my initial version of the design doc (I can understand, that there are currently other issues/topics with higher priorities :) )

Answer 8 · 2016-10-05T18:42:48.000Z

Sorry for this falling to the back-burner; stepper isn't one of the components we consider to be critical, and we've been focusing on getting those done to get to beta.

My main concern with the design was the accessibility story. You mention keyboard shortcuts, but the more important question is how the stepper presents itself to a screen reader. Marcy made some good points about it being different enough from tabs that the approach isn't really the same. Somehow the component as a whole has to present itself as stepper to the screen-reader user in a sensible way, requiring more semantic presentation than just adding aria-labels to the step headers.

For now we don't really have the cycles to work on this ourselves, but I'd be happy to see more ideas on the a11y workflow.

Answer 9 · 2017-01-11T11:07:21.000Z

Hi, any news about this component?

Answer 10 · 2017-03-01T14:14:47.000Z

Check out https://teradata.github.io/covalent/#/components/steps

Answer 11 · 2017-04-21T20:14:46.000Z

looking forward to this!

Answer 12 · 2017-05-10T11:29:02.000Z

Hi all. Updates? :D

Answer 13 · 2017-06-05T09:39:25.000Z

Hi is there any way to change the numbered svg icons to png images ?

Answer 14 · 2017-06-23T12:53:29.000Z

Is there an ETA for this?

Answer 15 · 2017-07-04T17:54:38.000Z

@eddiejaoude The README lists this feature as a Q3 2017 feature, meaning Jul 1, 2017 – Sep 30, 2017.

Answer 16 · 2017-09-08T13:50:19.000Z

Anything I can do to pitch in on this effort, or is this already close to complete?

Answer 17 · 2017-09-08T14:15:56.000Z

It's already available in material2-builds.

Answer 18 · 2017-09-08T16:47:31.000Z

@jlkeiper #6594

Answer 19 · 2017-09-19T18:57:06.000Z

Closing this since the stepper is in master and will be in the next release

Answer 20 · 2017-09-22T15:07:20.000Z

I have 2 questions:

Maybe a bit late, but why doing distinct components for md-vertical-stepper and md-horizontal-stepper instead of setting the orientation via attribute?
This way making responsive steppers is hard, as one needs to duplicate all steps inside the stepper for both cases. An example of a responsive stepper can be found on https://teradata.github.io/covalent/#/components/steps (but I'm sticking with the 'official' material components);
I didn't find any EventEmitters called when a step changes. For example, if I need to fetch data dynamically based on the previous step, how can that be done?

Answer 21 · 2017-09-22T16:27:16.000Z

For why separate components: we wanted to leave the stepper open to adding more variants without ballooning the size/complexity of a single component.

For the event: can you open a feature-request issue?

Answer 22 · 2017-09-22T17:37:38.000Z

Regarding the separated components, I understand it from the library maintainers POV, but it complicates things for users of Angular Material, because the horizontal steppers are a no-go on portrait mobile screens, and being mobile-first, in order to support both cases, each step needs to be duplicated because of the 2 components. Has other effects, such as using the *ngIf effectively destroys the component state and instantiates new ones. So, for example, if the user rotates the phone with something filled in, and the stepper changes orientation, the state is lost.

Regarding the event, I've reported #7259.

Answer 23 · 2017-09-22T17:46:58.000Z

@luisfpg I would expect the horizontal stepper to transform in mobile screens to something like the material guide mentions, but it looks like it doesn't :(
(from: https://material.io/guidelines/components/steppers.html#steppers-types-of-steps)

Answer 24 · 2017-11-03T10:33:33.000Z

How do you change the icon on this thing ? What's specified in the doc does not work.

<mat-horizontal-stepper icon="done">
    <mat-step label="Introduction" icon="done">
      <info-request-intro-app></info-request-intro-app>
    </mat-step>

    <mat-step label="from" icon="done">
      <info-request-form-app></info-request-form-app>
    </mat-step>

    <mat-step label="Validation" icon="done">
      <info-request-validation-app></info-request-validation-app>
    </mat-step>
  </mat-horizontal-stepper>

Answer 25 · 2019-09-07T13:02:49.000Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}