Wizard - keyboard and screen reader interaction

[jgiardino]

1. The navigation links currently are not accessible for either keyboard-only users or screen reader users. They can be made accessible by including a url in an href attribute. (Update: given current recommendations, it might make the most sense to make the items buttons so that they are keyboard accessible- see discussion below)
2. In the mobile layout, the navigation is accessed as a menu. The dropdown behavior pattern that I think makes sense here currently isn't implemented anywhere yet. I included comments about similar behavior in the PRs for context selector and select components, but maybe it would make sense to have a quick chat with everyone to understand if there's a simpler way to handle this interaction so that it can be easily reused across the different components?

• Update: Ideally, the interaction pattern would be the following: https://docs.google.com/document/d/1m9nICFRgCXnXeHYN487BMX9MHw4DjvOln2B5p8yJa70/edit#heading=h.1lr7m0rc8a6s however making the menu accessible is the most important aspect.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[matthewcarleton]

Following up on this @jgiardino @jessiehuff now that we're using the wizard in a product.
What are your thoughts on this from MDN?

Anchor tags are often abused as fake buttons by setting their href to "#" or "javascript:void(0)" 
to prevent the page from refreshing, then listening for their click events .

These bogus href values cause unexpected behavior when copying/dragging links, opening 
links in a new tab/window, bookmarking, or when JavaScript is loading, errors, or is disabled. 
They also convey incorrect semantics to assistive technologies, like screen readers.

Use a <button> instead. In general, you should only use a hyperlink for navigation to a real URL.

I've also noticed that the actions in the footer that are disabled do not have the disabled attribute, not sure if that's intentional.

[jgiardino]

Hey @matthewcarleton, thanks for sharing that link. I agree with the recommendations made by MDN on when to use anchor elements. I guess I assumed that anchor elements were chosen because the expectation was that real URLs would be provided for them. But maybe that wasn't the intention, and it might be worth discussing whether the navigation in a wizard should be handled as links or buttons. For example, do we want to support the user hitting the browser Back button in the context of a wizard? Or should the user be forced to click one of the buttons instead?

[matthewcarleton]

@jgiardino ya I agree. I think it would at least be useful to be able to set if they are urls or not. It would definitely be a good conversation to be had.

[seanforyou23]

Is the expectation that the wizard steps should be bookmarkable? I'm happy to help look into this, there might be something we can do with history pushState or a routing pkg.

[jgiardino]

👍
Maybe another way of asking that question is: Should a user be able to click the Back button in their browser to go back to the previous step?