mirror of
https://github.com/snachodog/just-the-docs.git
synced 2025-04-23 19:42:23 -06:00
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>
53 lines
1.9 KiB
Markdown
53 lines
1.9 KiB
Markdown
---
|
|
title: Ancestry
|
|
parent: Main Navigation
|
|
nav_order: 4
|
|
---
|
|
|
|
# Ancestry
|
|
|
|
If no two pages on your website have the same `title`, you only need to set the `parent` titles to fix the hierarchy. You can also have the same `title` on pages that have no children, provided that they have different parent pages.
|
|
|
|
If two parents have the same `title`, but different grandparents, you can set their `grand_parent` titles to distinguish between their parents. The `grand_parent` title needs to be the same as the `parent` of the `parent`.
|
|
|
|
## Example: distinguishing parents with `grand_parent`
|
|
{: .text-delta }
|
|
|
|
```yaml
|
|
---
|
|
title: T
|
|
parent: S
|
|
grand_parent: X
|
|
---
|
|
```
|
|
|
|
```yaml
|
|
---
|
|
title: T
|
|
parent: S
|
|
grand_parent: Y
|
|
---
|
|
```
|
|
|
|
The `ancestor` field of a page generalizes `grand_parent` to higher levels.
|
|
|
|
The following pages illustrate `parent` disambiguation using `grand_parent` and `ancestor` titles. Some descendants of both [Page X][X] and [Page Y][Y] have the same title, so references to those descendants as `parent` always require disambiguation.
|
|
|
|
- [X][X] is a parent page
|
|
- [S][XS] is the only child of [X][X]. The `parent` reference to [X][X] is unambiguous.
|
|
- [T][XT] is the only child of [S][XS]. Its `parent` is disambiguated by its `grand_parent`.
|
|
- [U][XU] is the only child of [T][XT]. Its `parent` is disambiguated by its `ancestor`.
|
|
- [Y][Y] is a sibling of [X][X].
|
|
- [S][YS] is the only child of [Y][Y]. The `parent` reference to [Y][Y] is unambiguous.
|
|
- [T][YT] is the only child of [S][YS]. Its `parent` is disambiguated by its `ancestor`
|
|
- [U][YU] is the only child of [T][YT]. Its `parent` is disambiguated by its `ancestor`.
|
|
|
|
[X]: {% link docs/navigation/main/x.md %}
|
|
[XS]: {% link docs/navigation/main/xs.md %}
|
|
[XT]: {% link docs/navigation/main/xt.md %}
|
|
[XU]: {% link docs/navigation/main/xu.md %}
|
|
[Y]: {% link docs/navigation/main/y.md %}
|
|
[YS]: {% link docs/navigation/main/ys.md %}
|
|
[YT]: {% link docs/navigation/main/yt.md %}
|
|
[YU]: {% link docs/navigation/main/yu.md %}
|