Expandable UI sections accessibility

[afercia]

This is about any UI section that expands to show something, for example, the Post Settings:

For accessibility, ideally the expandable sections should be placed in the markup immediately after the control that expands them, or they should be implemented in a way that the sections become the only "reachable" content after the control that expands them.

There are different techniques to implement this, depending on the placement of the expandable section in the markup. Worth exploring a bit the best option. For now, I'd suggest just a couple things:

• programmatically moving focus from the button to the panel is a no go, as the information provided by the aria-expanded attribute on the button would be missed (yes, the buttons should use aria-expanded)
• using aria-controls to reference a panel which is far from the button in the markup wouldn't solve the issue, because aria-controls is poop (sorry, it's a quote!)
• once the panel is open, consider to treat it as sort of "modal" as Adrian Roselli suggested for the content blocks (ping @aardrian !); this way, the panel would be the only available content for keyboard and screen reader users, until they complete the task within the panel. This can be implemented with different techniques, to evaluate with care (constraining tabbing, hiding anything else with aria-hidden, etc.)

[jasmussen]

Thank you again. Very actionable — the best kind of -'able!

Do defaults make a difference for accessibility here? For example if we show the sidebar open by default, and show all boxes inside expanded by default, would that be better or worse?

[aardrian]

Is the panel really analogous to a modal? As in, is it necessary for the user to complete a task (or abort that task) before being allowed to leave the panel? Is there ever a case where information necessary to complete that task is available elsewhere on the screen?

[afercia]

The sidebar is visible by default, by the way.

Ah ok, I was assuming it was closed by default, as in the screenshot posted on Slack. Then yes, defaults make a difference: if it's open by default we can't treat it as a modal.
By the way, the sidebar/panels placement still matters. When tabbing, users will find a button that says Post Settings button expanded. Then, the sidebar should immediately follow.
That's a bit more complicated 😬
Wondering if moving the Publish button after the sidebar would make things easier.
What about two toolbars?

• on the top: controls related to content editing: switch mode, undo/redo, insert
• then the Post Settings button with the sidebar immediately following the button
• on the bottom toolbar: controls related to the post state: Saved, Preview, Publish

This way, users could choose to navigate trough all the sidebar controls/options or collapse it and go straight to Saved, Preview, Publish.

[aardrian]

Wondering if moving the Publish button after the sidebar would make things easier.

Any reason not to have two Publish buttons? One before your sidebar (full of disclosure widgets) and one at the end of the sidebar.

This presumes that the goal of the UI is to reduce friction to hitting that Publish button, of course.

[afercia]

Hm... the Publish button on the top would be between the sidebar and the controls that open the sidebar... not sure that would be so ideal 😞

[afercia]

In the case of the "Post Settings" button, the first step for better a11y would be adding an aria-expanded attribute. If set when using the component, it would be as simple as changing
<Button onClick={ toggleSidebar } isToggled={ isSidebarOpened }>
to
<Button onClick={ toggleSidebar } isToggled={ isSidebarOpened } aria-expanded={ isSidebarOpened }>
unless controlling this from the component is considered preferable (but not all the <Button> will need aria-expanded). /cc @aduth

[afercia]

See #473

[mtias]

@afercia did your recent work on the tabs and panels address this?

[afercia]

@mtias Even if the issue title uses the term "panel" this doesn't apply only to the sidebar "panels" but to:

any UI section that expands to show something

I'd consider it as a "tracking issue" because any developer working on such UI patterns should be aware of what to do. See for example #2204

[mtias]

Can we edit the title to make it more clear? We should find a different way to keep these considerations, maybe an accessibility doc could group them.