Clarity: [component] stepper architecture

[coryrylan]

Feature Proposal UX

• See issue https://github.com/vmware/clarity/issues/2503

Static HTML/CSS

• static html/css example https://stackblitz.com/edit/clarity-light-theme-v1-0-ddavun

Test Cases

• [ ] It should prevent user from moving to next step if form is invalid or async failure
• [ ] It should allow user to go to previously completed step
• [ ] It should set step state to active on previously completed step when navigated back to previous step
• [ ] It should collapse all future steps if user opens previously completed step
• [ ] It should notify when all steps have completed
• [ ] It should notify when an individual step has completed (or maybe a state change, error/complete?)
• [ ] It should render error state when set programmatically
• [ ] It should render complete state when user goes to next step without error
• [ ] It should render the first step as active and open initially with all other steps closed
• [ ] It should allow programmer to force stepper to next step if next step is disabled for async processing
• [ ] It should show appropriate active/complete/error/inactive icons in respective states
• [ ] It should allow programmer to explicitly set a step as complete without user intervention (ex pre populated steps/edits)
• [ ] It should allow programmer to explicitly reset the stepper state
• [ ] It should set appropriate number for step and consider dynamic steps being added or removed
• [ ] It should be able to use full keyboard to navigate between steps
• [ ] It should set state properly for screen reader functionality

Architecture (WIP)

[sdurnov]

Ehh, I was hoping to see something visually lighter. Anyway, nice to see that @coryrylan has so much energy. Looks like Clarity development speed is increasing.

[Jinnie]

The prototype looks nice.
I have a general question though. Cory, it's not about the way you are implementing it, but more about the spec we have.
Are we sure that in the "Error state" handling we want to replace the step number with exclamation mark circle? It looks pretty cool, I admit, but I am not sure it is very accessible. We're losing information that may be helpful for the accessible navigation this way.
Any thoughts, team?

[mathisscott]

@Jinnie
Replacing the step number is intentional in the design for a couple of reasons.

1. We need to show error state in all components along two communicative paths. We cannot only use color because users who cannot discern color will not understand there is an error. So we have to either use color and iconography or color and text.

2. The product teams wanted to keep the design as compact and space-constrained as possible. So we could not reserve a place to display an error icon.

3. The visual impact of switching out the number for the icon was the preference because the designers found that, say, placing the icon on the far right made it too easy for users to overlook. They weren't seeing the icon on the far right.

4. In addition to that, we have no control over how wide these steppers are meant to be. They take all the horizontal space available to them. That was a further reason to not place the icon on the far right. So having it in a consistent place (where the numbers are) was a more resilient design choice.

5. Lastly, the numbers are not crucial information. They are a convenience if nothing else. The functionality of the stepper requires that one thing follows another. In programming terms, it is more of a linked list than an array. So having the index of every step available to end users is a nice-to-have. If a user has step 5, an error icon, and step 7 consecutively and cannot infer that the error icon was previously the number 6, there is not much we can do to help them. The product designers tested this and found that conclusion to be sound. Replacing the numbers drew attention to error states. Users did not have any problems understanding that the steps proceeded one after the other, even when the error icons were present.

Additionally, the default state shows the numbers. So the discovery on that is minimal. The stepper shows up with numbers. The error icons show up when something has gone wrong. They go away when the user fixes whatever was broken.

[Jinnie]

@mathisscott I agree numbers are not crucial. Thanks for the detailed answer.
I checked it with a screen reader and it just skipped the error icon. Primarily that's what caught my attention and made me start the conversation. But for testing against a prototype, this is quite okay. I'm sure we'll be handling it in the final version.

[youdz]

The icon should have a localized title that reads something like “Error” on a screen reader. Well have that in the Angular version, I guess this static example doesn’t have it.

EDIT: oops, it’s because of #2608.

[gnomeontherun]

Just a few comments.

1. What about error in inactive state? That could happen if you had an async validation process perhaps.
2. The UX plan shows an alert below the button, I think we need a demo of that and a recognition of how that might look with the API (do you project it to a specific place)?
3. The DOM for buttons looks fine, just want to point out that we'll want to have a similar implementation for buttons to the wizard.
4. Curious about the left alignment for the button and content inside of the stepper panel, it looks like its not quite aligned equally with the stepper numbers in the panel titles.
5. The padding between the content and the button in the step panel seems too small.

[github-actions[bot]]

Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.