Skip to content

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: dafa89e

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
Contributor

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
Contributor

Tachometer results

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

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

@Rajdeepc Rajdeepc left a comment

Choose a reason for hiding this comment

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

Love the way this is coming together! I completely agree with Casey — we’ve heard from a few of our customers that they’ve run into some friction when using sp-popover and sp-dialog. I think this is a great opportunity for us to meet them where they are and simplify the documentation.

Would it make sense to create a few clear blocks or usage patterns, and accompany them with real-world examples to make things more approachable?

Use sp-dialog-base when:

  • You need to present important information that requires user acknowledgment
  • You're building a modal interface that blocks interaction with the page
  • You need a structured container with features like backdrop/underlay
  • Your content is complex and requires formal layout with headings, content sections, and actions

Use sp-popover when:

  • You need a lightweight, contextual container that's positioned relative to a trigger element
  • You want to display simple content like menus, tooltips, or additional options
  • You're building a non-modal interface where users can still interact with the page
  • You need an element with an arrow/tip pointing to the trigger

Note: You can actually combine these approaches by using sp-dialog inside sp-popover for a styled popover with dialog-like formatting, as shown below:

<overlay-trigger>
    <sp-popover slot="click-content" placement="bottom" tip>
        <sp-dialog>
            <h3 slot="heading">Styled Popover</h3>
            <p>This uses sp-dialog inside sp-popover for a styled contextual interface.</p>
        </sp-dialog>
    </sp-popover>
    <sp-button slot="trigger">Open Popover with Dialog</sp-button>
</overlay-trigger>

@nikkimk
Copy link
Contributor Author

nikkimk commented May 5, 2025

@caseyisonit @Rajdeepc thanks for the feedback. Please take a look at my changes.

@nikkimk nikkimk requested review from caseyisonit and Rajdeepc May 5, 2025 20:23
Copy link
Contributor

@castastrophe castastrophe left a comment

Choose a reason for hiding this comment

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

I think this looks really great. Nice enhancements here!

@castastrophe castastrophe force-pushed the nikkimk/dialog-docs branch from 583ada1 to f248c07 Compare May 6, 2025 14:28
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.

@nikkimk this is a massively huge beautiful improvement and will be sooooo beneficial for our consumers! thanks for working through this. 🚀

@caseyisonit caseyisonit merged commit cd1ab2f into main May 6, 2025
24 checks passed
@caseyisonit caseyisonit deleted the nikkimk/dialog-docs branch May 6, 2025 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants