jnm2377
commented
2 years ago @carmacleod thanks for opening this. You're right, we should include the a11y information. We'll have a dev work on adding this to the docs. :)
Open carmacleod opened 2 years ago
jnm2377
commented
2 years ago @carmacleod thanks for opening this. You're right, we should include the a11y information. We'll have a dev work on adding this to the docs. :)
sstrubberg
commented
1 year ago Notes from our Backlog Cleaning meeting today:
mbgower
commented
1 year ago The challenge I see is that the disclosure pattern is fitting into a lot of different user interactions (basically anything where content is revealed).
It's also very unclear whether the disclosure covers things that persist until closed by the user (i.e., a user can go to other parts of the part and the disclosed content continues to appear). Things that fit in here would be accordions; collapsible left navs or other sections, which once opened stay open until specifically closed by the user.
This is a VERY different interaction model than menus, selects, date pickers, etc., which disclose information, but the information is component-specific; once the user navigates to another component (that is not a child) the disclosure vanishes.
Perhaps there are 2 clear variants for the disclosure pattern?
There might be a very basic naming convention that applies in all situations, and which can be covered by what Carolyn was advocating for. But to ascertain that, we really need a Venn diagram showing every possible thing that might be covered by this pattern, to make sure we have something consistent.
sstrubberg
commented
1 year ago We need to figure out where this lives on the website.
laurenmrice
commented
1 year ago The challenge I see is that the disclosure pattern is fitting into a lot of different user interactions (basically anything where content is revealed)
A disclosure uses a popover and a trigger to open it and only opens on click or by using your keyboard. Disclosures should be user initiated.
It's also very unclear whether the disclosure covers things that persist until closed by the user
Disclosures open on a layer above the current page, which can cover up information on the page behind the open disclosure temporarily until the disclosure has been closed by the user.
I think this information can live on the Disclosure pattern page in the Accessibility section but we need to make some changes to it.
I would remove the current guidance in the Accessibility section and provide Accessibility information about how a disclosure opens and closes via mouse and keyboard. This could be around the actual ui trigger (which could potentially require a tooltip depending on what the trigger is) and around how to dismiss or close out the disclosure. With that said, this is just a pattern of a couple different ways people could show disclosures but it doesn't show every example that exists, it is just showing a few common visual recommendations to get people started. The accessibility section could show some common recommendations but we could also say it may not pertain to all situations.
mbgower
commented
1 year ago Disclosures open on a layer above the current page, which can cover up information on the page behind the open disclosure temporarily until the disclosure has been closed by the user.
That isn't specific enough. The two key sticking points are "temporarily" (persistent or non-persistent) and "closed by the user".
My point is that a slide-in side panel is only 'temporarily' open from the perspective that its trigger can be reactivated to make it go away if desired. So I would call that persistent.
Whereas a menu is temporarily open until it loses focus. It doesn't need to be closed by the user -- at least not intentionally. If the user puts focus somewhere else (by mouse or, much more critically from an accessibility perspective, by keyboard) it closes. I call that non-persistent.
The crux of the matter is that the keyboard implementation unintentionally often makes something persistent by keyboard where it was meant to be non-persistent.
Examples of Carbon components that I would say use a disclosure pattern which are persistent:
Examples of Carbon components that use a disclosure pattern which is not persistent:
If I assess the ibm.com stuff, I'm sure there would be many things that would correctly or incorrectly fit in the first category. That's why I think there needs to be much more clarity around what is meant by a disclosure, and why I'm keen to get that captured.
I also think that maybe we could come up with a pattern of "displacement". I think the qualities of such a pattern would be: 1) it reveals content that displaces other content (that content reflow to make room for it, either moving down the page or reflowing to a narrower width) 2) it persists until manually closed by the user, typically by re-activating the trigger. It normally would also return to its starting state when the page is reloaded
laurenmrice
commented
11 months ago We need to resolve #3428 before tackling this issue. So marking as blocked for now.
In the Accessibility section for Disclosure, it only talks about how to activate the trigger button. https://v11.carbondesignsystem.com/patterns/disclosures-pattern/#accessibility
Where does Carbon usually put guidance for developers when ARIA is needed to make something understandable for screen readers? For example, a Disclosure needs to have aria-expanded="true"/"false" on the button, and optionally aria-controls pointing to the popover.
Also, I would expect to see advice around using Carbon icon button tooltips to give a label to the icon button and add aria-labelledby so that the icon button has a text label for screen readers to read.