Modal implementation and documentation needs addressing #12726
mbgower
started this conversation in
Accessibility
Replies: 1 comment 1 reply
-
|
I don't discuss tearsheets anywhere here (since they did not exist in Carbon core). |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
If I get the chance, I'll try to review the tearsheet information and add some more comments... |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This discussion focuses on considerations for the React storybook implementation of the modal. They are listed in order of priority, first highest.
It is complementary to modal issues (#12727, #12814) I have opened.
Recommendation 1: Make the State Manager variant the default (and get rid of the cumbersome name)
Almost all the examples are non-interactive. This doesn't really work for a modal since it is by definition all about interaction (or the restrictions to interaction). The State Manager version, on the other hand, starts with a button to trigger the modal, allowing proper experience both of how the item appears and how it can be resolved.
For accessibility considerations, it is impossible to test all the other versions. In my opinion, they should all be dynamic in nature (triggered and operable). And if there is a need to put in a launchable one, is "State Manager" the best name for it?
Recommendation 2: Differentiate between a 'typical' dialog and a richer interaction.
Only the Danger example is a classic dialog, consisting of a title, text and 2 buttons. All the others, including the default, are actually modals that contain inputs and not just buttons.
IMO, at least the first modal example should be this simple (although obviously not be a Danger modal). In fact, I would be more inclined to make the 'dialog with form' a distinct variant and leave the others as the more common dialogs. You could have a 3-button variant as well.
Recommendation 3: Improve implementation
Title: Currently, I'm seeing an aria-label on the modal. Why not just pick up the H2 and use aria-labelledby? This will more gracefully accommodate localization.
Content: I also wonder if the use of aria-describedby could be used on the H3 and paragraph content? May have to think about a form input situation, but as it stands, although screen reader users have an ability to read the dialog, one that exposes the info on its own seems better. As it stands, I don't see the point of aria-labelledby pointing back to the h2 heading for the paragraph. It may make fractionally more sense pointing to the H3 for the paragraph, but why point back to the H2, which is already given as the name of the dialog?
I realize these two paragraphs are a bit confusing, so to summarize: use the H2 to give a title to the dialog (via aria-labelledby); consider using the content of the H3 and paragaph as an aria-describedy for the modal.
Recommendation 4: Call the "passive" modal something else.
A dialog is an interaction. It infers the system prompting the user for something and the user responding. If the user doesn't need to provide any information, it's not a dialog anymore. It's just a notice.
Most of the time, such a notice doesn't need to be acted on, so why would it be made modal? It can take focus without being modal. IMO, the better interaction here is that the notice gets focus, and then disappears when focus is moved from it. Since there is no action for the user to perform, it's difficult to argue that this isn't a logical interaction. What would be the reason for making it persist? And note that that IS the effective interaction for pointer users. But keyboard users are forced to explicitly dismiss.
Recommendation 5: Make it clear what the difference is between the Default and full width view
We could not find anything obvious different in the two views. This may partially be a result of the modals containing different content. In the Carbon usage, it says:
Recommendation 6: Make it clear if lighbox effects are optional, and when to do and not do
IMO, if there is a true modal, a lightbox effect makes this very clear (and seems to be used consistently by Carbon). However, there is no documentation of this that I see in Usage. Suggest adding it.
Recommendation 7: Put the Composed Modal examples underneath Modal
I did not notice that there is a different set of storybook examples in a different part of the component tree. I suggest at the least they both be linked to from the Code page, but it makes more sense to nest them all under the same component.
Beta Was this translation helpful? Give feedback.
All reactions