8292f46be9
This PR fixes some accessibility issues in our theme docs (i.e. not generated code) flagged by #1513. Here, I target changes that I say are not "systemic", i.e. issues that are easily resolvable by changing our copy and page structure (rather than issues that are created by how kramdown/rouge generates HTML, or reworking our color themes). Here's a quick summary of the manual changes I made: - ~~writing some JS to set `tabindex="0"` on all code blocks; I'd prefer a ruby-native solution, but that involves writing Ruby code, which is incompatible with the pages gem~~ I've moved this to #1533 - rewriting many headings named "Example" which were almost always h4s into more descriptive headings + the appropriate heading level, adding .text-delta to maintain the previous style when necessary - removing some old heading ID hacks in `index-test` that are no longer necessary, since Jekyll does this automatically now - fixing the table headings in `docs/utilities/layout.md` - adding accessible titles + descriptions to the mermaid examples - occasionally, slightly moving around copy to make it align with new headings If you test with #1513 with the following rules disabled: ```rb skipped_rules = [ 'color-contrast', # requires theme auditing # issues w/ autogenerated footnotes 'aria-allowed-role', 'landmark-no-duplicate-contentinfo', 'landmark-unique', 'aria-deprecated-role', # issues w/ markdown checkboxes 'label' ] ``` You should get passing tests :) which is awesome! ## next steps 1. we need to do a pass over our docs copy - very inconsistent. This has been a pain point for me for a while now, just need to find time to sit down and do it. In particular, I'd love to standardize how we display example code (perhaps even hiding it with `<details>` and `<summary>`?), our headings language, what goes into the ToC, our overall writing style, etc. 2. ~~I don't love the JS hack for adding `tabindex="0"` to code blocks (so that they are keyboard-focusable). Ideally, we'd add a custom formatter to rouge to do this, but we can't execute arbitrary Ruby code when users use `github-pages`. I'll look into this some more - maybe rouge would be open to adding this as a feature.~~ see: #1533 4. There are some systemic issues that need a deeper look: 1. The most common issue is still color-contrast. Fixing this involves: - looking at our whites/blacks/grays for core text and highlighting - reevaluating our syntax highlighting themes - fixing dark mode, once and for all :) - also, picking accessible callout colours! 2. kramdown's autogenerated footnotes feature creates a bunch of errors that aXe flags: it seems like a deprecated aria role is being used, and perhaps some misuse of markup. Need to look into this more before I can make a solid attempt at resolving this issue. 3. We demonstrate the use of `- [ ]`, but this generates `<input type="checkbox">` values with no label. I'm not entirely sure what the best way to fix this problem is (without writing custom Ruby code). I'll have to think about this some more. --------- Co-authored-by: Michael Ball <michael@mball.co>
2.7 KiB
| title | parent | nav_order |
|---|---|---|
| Page Levels | Main Navigation | 3 |
Page Levels
Sometimes you will want to create a page with many children. First, it is recommended that you store related pages together in a directory. For example, in these docs, we keep all of the written documentation pages in the ./docs directory, and each of the sections in subdirectories like ./docs/ui-components and ./docs/utilities. This gives us an organization like this:
{: .lh-0 }
┌─ ...
├─ (Jekyll files)
├─ docs
├─ configuration.md
├─ ui-components
├─ index.md (parent page)
├─ buttons.md
├─ callouts.md
├─ code
├─ index.md (parent page)
└─ line-numbers.md
├─ labels.md
├─ tables.md
└─ typography.md
├─ ...
└─ MIGRATION.md
├─ index.md (home page)
├─ (Jekyll files)
└─ ...
Example: page with no parents
{: .text-delta }
---
title: UI Components
nav_order: 3
---
Here we're setting up the UI Components landing page that is available at URL /docs/ui-components, which is ordered second in the main navigation.
The navigation links for all pages with children come with an expander. When you click the expander, the display of the children is toggled, so you can expand or collapse all the children displays, regardless of which page is currently active.
Child Pages
On child pages, simply set the parent front matter to the parent page's title, and set a navigation order (relative to pages having the same parent).
Example: creating a child page
{: .text-delta }
---
title: Buttons
parent: UI Components
nav_order: 2
---
The Buttons page appears as a child of UI Components and appears second in the UI Components pages.
{: .new-title }
New (Multi-level)
The
has_childrenfield is now redundant (and ignored, except when significant for backwards compatibility).
Multi-level Child Pages
Child pages can themselves have children, to any number of levels.
Example: pages with (recursive) children
{: .text-delta }
---
title: Main Navigation
parent: Navigation
nav_order: 1
---
---
title: Ancestry
parent: Main Navigation
nav_order: 4
---
---
title: X
parent: Ancestry
---
---
title: Y
parent: Ancestry
---
This creates the following navigation structure:
{: .lh-0 }
┌─ ...
├─ ...
├─ Navigation
├─ ...
├─ Main Navigation
├─ ...
├─ Ancestry
├─ X
└─ Y
├─ ...
└─ ...
├─ ...
└─ ...
├─ ...
└─ ...