md-stepper component

[thielpa]

@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) 😄

[jelbourn]

@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.

[marcysutton]

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.

[AutoSponge]

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.

[thielpa]

@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!

[paralin]

Looking forward to this!

[odyright]

hello, is ther a complete version now?

[thielpa]

@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 :) )

[jelbourn]

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.

[tomasgarzon]

Hi, any news about this component?

[ccpony]

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

[kunshao-msft]

looking forward to this!