Skip to content

Collapsible source headings #17226

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 25 commits into
base: 5.8
Choose a base branch
from

Conversation

brianjhanson
Copy link
Contributor

Description

Adds a "collapsible" option to source headings when customizing.

CleanShot 2025-05-06 at 13 34 21@2x

When checked, headings will get an icon before the label and items beneath the heading can be collapsed.

If the current page is an ancestor of a collapsed section, the icon will flip colors to denote a collapsed item is active.

CleanShot 2025-05-06 at 13 36 53@2x

The state of each toggle will be stored in cookies so it will persist across page loads. The only downside is a minor flash of the expanded state.

Related issues

Fixes CMS-1339

Copy link

linear bot commented May 6, 2025

@brianjhanson brianjhanson requested a review from gcamacho079 May 6, 2025 18:50
@brianjhanson
Copy link
Contributor Author

Related issues:
#13307 (comment)
#11340
#16065

Copy link
Member

@brandonkelly brandonkelly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!! Couple thoughts:

  • The setting seems unnecessary? From an AX perspective it would be weird if some headings are collapsible and some aren’t.
  • I don’t love the collapsed toggle styling’s inverted colors. Let’s just have it look the same, but upside-down, as when the heading is expanded.

@brianjhanson
Copy link
Contributor Author

The setting seems unnecessary? From an AX perspective it would be weird if some headings are collapsible and some aren’t.

Updated, all headings are just collapsible now.

I don’t love the collapsed toggle styling’s inverted colors. Let’s just have it look the same, but upside-down, as when the heading is expanded.

The toggle will only appear this way when one of the items nested beneath it (and therefore invisible when collapsed) is selected. The goal was to provide some kind of "hey a thing under here is selected" indicator. We could also highlight the actual item that's collapsed, but that felt a little too strong to me.

I also remove these lines because a heading will always get a key now but let me know if you'd rather minimize the changes and totally remove the key for headings. I think they could be useful if we want to add settings to a heading in the future, but that might be a big if. Now that all headings are collapsible they don't necessarily need a key.

Copy link
Contributor

@gcamacho079 gcamacho079 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome feature! From a11y testing:

  • The disclosure controls should be updated to either be at least 24px in size, or have sufficient space with adjacent links
  • The disclosure control should also include the heading name for extra context, either as visually-hidden text, or referenced via aria-labelledby or aria-describedby. The benefit of using visually-hidden text or aria-labelledby would be that the control is more accessible to voice control users, and screen reader users who may be navigating controls out of context.
  • This issue already exists, but I’m wondering if we should require headings not be blank, as it’s a bit disconcerting when there’s a disclosure toggle next to a blank heading.
  • The inverted button communicates to sighted users that one of the child items is active, but that information isn’t communicated to screen reader users. It may be helpful to add something like aria-current="true" to communicate that we’re currently inside that nested source menu. 🤔

@brianjhanson
Copy link
Contributor Author

Thanks @gcamacho079! 🙌

The disclosure controls should be updated to either be at least 24px in size, or have sufficient space with adjacent links

I think we have enough space here (but please correct me if I'm wrong).

I found this guidance:

it must be possible to draw a virtual circle centered on the target with a diameter of 24 pixels that does not intersect any other targets, nor any of the circles on other undersized targets.

So I whipped up some CSS to see and I think things look good?

CleanShot 2025-05-14 at 08 37 17@2x

The disclosure control should also include the heading name for extra context, either as visually-hidden text, or referenced via aria-labelledby or aria-describedby. The benefit of using visually-hidden text or aria-labelledby would be that the control is more accessible to voice control users, and screen reader users who may be navigating controls out of context.

Fixed in 702eda4 happy to tweak that language though. I'd love a recommendation.

This issue already exists, but I’m wondering if we should require headings not be blank, as it’s a bit disconcerting when there’s a disclosure toggle next to a blank heading.

As of d5316e7 blank headings won't be collapsible. I feel like that's probably the best compromise for the moment.

The inverted button communicates to sighted users that one of the child items is active, but that information isn’t communicated to screen reader users. It may be helpful to add something like aria-current="true" to communicate that we’re currently inside that nested source menu. 🤔

Would aria-current=true be expected on the parent any time the parent has an active child? Or only when the parent is collapsed (as with the indicator). I'm assuming only when it is collapsed, but just wanted to clarify.

@gcamacho079
Copy link
Contributor

gcamacho079 commented May 14, 2025

I think we have enough space here (but please correct me if I'm wrong).

@brianjhanson I think this only applies when the disclosure is open; the safe clickable area of the disclosure toggle is 21.2px according to the testing extension, due to the first link in the nested source menu:

Outlines drawn around the disclosure toggle and the source menu underneath

Would aria-current=true be expected on the parent any time the parent has an active child? Or only when the parent is collapsed (as with the indicator). I'm assuming only when it is collapsed, but just wanted to clarify.

The reason I flagged it is because there’s a visual indicator that there’s an active child without there being an equivalent for AT users. When the disclosure is expanded, there isn’t an indicator on the parent, in which case, there’s no hard requirement to include that information for AT users.

We can include it, though, for clarity, and I realized after my initial comment that we can actually put the aria-current attribute on the li itself, rather than it needing to just be on an interactive element (i.e., the disclosure button).

@brianjhanson
Copy link
Contributor Author

Thanks @gcamacho079!

I just added a bit more margin to headings which gets the hit target test to pass in AXE for me.

We can include it, though, for clarity, and I realized after my initial comment that we can actually put the aria-current attribute on the li itself, rather than it needing to just be on an interactive element (i.e., the disclosure button).

Just updated so the parent li will get aria-current=true when a descendent is selected and the ancestor is collapsed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants