Accessibility improvements to docs

[nikkimk]

Description

Improving the accessibility documentation of components.

Motivation and context

Documentation should provide more information and examples that demonstrate how to use the components accessibly. These changes started with #4652

How has this been tested?

<sp-action-button>

Review action button docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-action-bar>

Review action bar docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-action-group>

Review action group docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-action-menu>

Review action menu docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-asset>

Review asset docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-button>

Review button docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-button-group>

Review button group docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-card>

Review card docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-combobox>

Review combobox docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-help-text>

Review help text docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-icon>

Review icon docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-icons>

Review icons docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-iconset>

Review iconset docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-icons-ui>

Review icons-ui docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-icons-workflow>

Review icons-workflow docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-menu>

Review menu docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-menu-group>

Review menu-group docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-menu-item>

Review menu-item docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-picker>

Review picker docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-picker-button>

Review picker button docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-popover>

Review popover docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-slider>

Review slider docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-slider-handle>

Review slider handle docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-switch>

Review switch docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-tray>

Review tray docs

• Do the docs examples give enough context to test for accessibility?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

1. You can use the WAVE browser extension's Structure tab to review heading structure.

Developing a Component Guide

• Does the guide for developing a component provide enough information to create accessible, consistent component docs? (1)

Overview tabs navigation fix

• Go to card docs. Does Overview tab panel content appear?
• Click on API tab. Does API tab panel content appear and is the URL https://nikkimk-a11y-docs-ready--spectrum-web-components.netlify.app/components/card/api?
• Click on Overview tab. Does Overview tab panel content appear and is the URL https://nikkimk-a11y-docs-ready--spectrum-web-components.netlify.app/components/card/?
• Click on Changelog tab. Does Changelog tab panel content appear and is the URL https://nikkimk-a11y-docs-ready--spectrum-web-components.netlify.app/components/card/changelog?
• Click on Overview tab again. Does Overview tab panel content appear and is the URL https://nikkimk-a11y-docs-ready--spectrum-web-components.netlify.app/components/card/?

Font sizes

• Are the above component document font sizes consistent with the following design recommendations?
  • h1: heading XXL, serif, heavy
  • h2: heading L, sans-serif
  • h3: heading M, sans-serif
  • h4: heading S, sans-serif
  • h5: detail L
  • body: body M, sans-serif

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• If my change required a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes. N/A
• All new and existing tests passed.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7797bdb

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Branch preview

• Documentation Site
• Storybook

Review the following VRT differences

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

• Spectrum | Light | Medium | LTR
• Spectrum | Dark | Large | RTL
• Express | Light | Medium | LTR
• Express | Dark | Large | RTL
• Spectrum-two | Light | Medium | LTR
• Spectrum-two | Dark | Large | RTL
• High Contrast Mode | Medium | LTR

If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.

[github-actions]

Tachometer results

Currently, no packages are changed by this PR...

[coveralls]

Pull Request Test Coverage Report for Build 13639262968

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.966%

---

Totals
Change from base Build 13583172491:	0.0%
Covered Lines:	33662
Relevant Lines:	34164

---

💛 - Coveralls