[Feature Request]: Collapsable sections in Side Navigation

[inkblotty]

Context

The Accessibility Team at GitHub is looking to extend Primer.style's Accessibility documentation under the Interface Guidelines pages. However, the side navigation would become very long with all the documents we have planned.

Feature Request

• [ ] Enable nested / collapsible navigation in primer.style

cc @github/accessibility :)

[yaili]

Hi 👋🏼 Can you provide more detail about why this would be needed? For example, what is the current proposed structure of the documentation? If it is that long, is primer.style the best place for it to live?

[mperrotti]

I think we're going to be changing the primer.style sidebar navigation to use ActionList. If that's happening soon, we should wait until that work is done so we don't have to implement the collapsible behavior twice.

@yaili - let's link that issue here once it's created.

@vdepizzol - how do you feel about allowing ActionList to have collapsible groups?

[inkblotty]

Hi @yaili -- we have these: [Epic]: Self-Serve Platform and [Tracking]: Self-Serve Platform. You can see there are some placeholder issues inside the Tracking issue, but some are also fleshed out. For Primer work, we'll just be extending the Accessibility section under the existing Interface Guidelines.

[vdepizzol]

@mperrotti The use of NavigationList should support sub-groups. @siddharthkp has been experimenting with the use of ActionList -- and I have just summarized some of the ideas in this issue:

• https://github.com/github/primer/issues/635

However, the side navigation would become very long with all the documents we have planned.

@inkblotty do you think each of those bullet points would become their own page? Or could they be content sections of a page?

Maybe we should consider that overlapping content could belong in different sections. Per instance, "How to work with color" could be in the Foundation / Color page. Or, focus states could be under Foundation / Style.

The mock from the issue above has some ideas of some pages we're considering for Interface Guidelines -- I'm hoping to open an issue to keep track the navigation contents soon!

🙇

[gaknoll]

Thanks for writing this up @inkblotty! Shipping an alpha React component was originally slated for Q4, but we've created an issue and added it as a Q3 stretch goal for our high-impact Primer React components epic.

[yaili]

Thanks, @inkblotty!

I agree with @vdepizzol that in some instances this content is better suited to live in the same place as the pattern or component it relates to, as that's where folks will be to find out how to apply that component.

It would be great if we could have some reviews and edits before we publish this in primer.style/design as it's a departure from the way that the content is currently modelled. For example, some titles sound more like articles than more plain documentation that we have right now, so we'd need to make sure we understand the implication that has to the current content structure and if we need to make any changes.

[inkblotty]

@yaili @vdepizzol -- We will absolutely get your reviews on these documents. I was hoping for them! Let me give a quick explanation of our driving philosophy for where things live right now.

You'll see references to Accessibility documentation in all areas of GitHub UI products. This issue lists just some of the places we've found documentation, and it also lists the different reasons we're using The Hub, our github/accessibility repo, and Primer. Our goal is to create a platform of Accessibility guidelines, easy to find, that anyone can use if they encounter these common patterns or need the resources we prepare.

From @vdepizzol:

Maybe we should consider that overlapping content could belong in different sections.

I fully anticipate we'd want to cross-link these docs from other areas, but we'd like one centralized place for the main content to live. We need it to be easier to prevent duplication or to prevent people not finding what's relevant to them.

From @vdepizzol:

@inkblotty do you think each of those bullet points would become their own page? Or could they be content sections of a page?

I think we're shooting for their own page right now so it's easier for us to point audit tickets to that page as a reference. That's the loose plan though. We can definitely combine sections that make sense. Could we talk about that case-by-case as we write and review?

[yaili]

Of course! Sounds good. I'm always more than happy to help review documentation, so please ping me with anything you need!

[mperrotti]

Closing because NavList supports this