Skip to content

docs(dialog): updated dialog docs for accessbility #5411

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 5 commits into
base: main
Choose a base branch
from

Conversation

nikkimk
Copy link
Contributor

@nikkimk nikkimk commented Apr 29, 2025

Description

  • Improving the accessibility documentation of dialog components.

Related issue(s)

  • SWC-374
  • SWC-375
  • SWC-376

Motivation and context

Documentation should provide more information and examples that demonstrate how to use the components accessibly.

How has this been tested?

Review dialog 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? You can use the WAVE browser extension's Structure tab to review heading structure.

Review dialog base 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?

Review dialog wrapper 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?

Screenshots (if appropriate)

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.
  • 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.

Copy link

changeset-bot bot commented Apr 29, 2025

⚠️ No Changeset found

Latest commit: 83bf62c

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

Copy link

Branch preview

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:

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.

Copy link

Tachometer results

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

@@ -164,7 +164,7 @@ async function main() {
// Configure the index fields
this.ref('metadata');
// Boost title field for higher relevance when matching titles
this.field('title', { boost: 10 });
this.field('title', { boost: 100 });
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding more to the dialog docs made dialog, dialog base, and dialog wrapper have higher result than base docs, so we boosted the value of a matching title.

@nikkimk nikkimk marked this pull request as ready for review April 30, 2025 20:34
@nikkimk nikkimk requested a review from a team as a code owner April 30, 2025 20:34
Copy link
Contributor

@caseyisonit caseyisonit left a comment

Choose a reason for hiding this comment

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

Left a few comments and happy to assist just let me know

Copy link
Contributor

Choose a reason for hiding this comment

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

We use sp-popover instead of sp-dialog-base as the wrapper. Should we stay consistent with using the dialog component architecture that's available? Maybe we add an example with context about how and when to use sp-popover over sp-dialog-base? I think this is where a lot of confusion can happen. I'm always confused with our dialog lol.

Maybe we also can highlight the components required to use with sp-dialog for the desired functionality since it is a compositional component?

For all of the receives focus examples across all docs, the guidance is actually specific to sp-overlay. Should we make sure there is an example in that component and link to it from the dialog docs so we don't have to maintain it in multiple places?


The dialog base supports different display modes:

##### Fullscreen Mode
Copy link
Contributor

Choose a reason for hiding this comment

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

h5 font size is almost impossible to notice. Can we fix this in CSS orrrr remove the ## Overview heading, and then all subsequent headings go up a level? This markdown file is rendered under an Overview Tab when built so we repeat it twice. This would improve all experiences.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is exactly the same content as dialog-base. Are they two different components that we ship?

Copy link
Contributor

Choose a reason for hiding this comment

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

https://opensource.adobe.com/spectrum-web-components/components/dialog-wrapper/

It looks like a complex component with a lot of functionality not shown in the example based on the API. Happy to help on this one if we need a list of examples

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.

2 participants