Skip to content
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

feat(floating-menu): add focus wrap element to components #3652

Conversation

elizabethsjudd
Copy link
Contributor

Closes #3603

Move the focusable element used for the focus wrap feature to be within the component so developers don't have to add a hidden element to get this feature. This impacts modal, tooltip, and overflow menu. Waiting on #3476 to be merged so I can test with the new functionality of tooltip.

Changelog

Changed

  • floating menu now supports a wrapper node around the floating menu that contains a focusable span used to detect menu blur
  • modal demo updated
  • overflow menu and tooltip demos updated and vanilla JS updated to support the new wrapper element

Testing / Reviewing

Test overflow menu, modal, and tooltip keyboard interactions

@netlify
Copy link

netlify bot commented Aug 5, 2019

Deploy preview for the-carbon-components ready!

Built with commit abf3402

https://deploy-preview-3652--the-carbon-components.netlify.com

@netlify
Copy link

netlify bot commented Aug 5, 2019

Deploy preview for carbon-elements ready!

Built with commit abf3402

https://deploy-preview-3652--carbon-elements.netlify.com

@netlify
Copy link

netlify bot commented Aug 5, 2019

Deploy preview for carbon-components-react ready!

Built with commit abf3402

https://deploy-preview-3652--carbon-components-react.netlify.com

Copy link
Contributor

@asudoh asudoh left a comment

Choose a reason for hiding this comment

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

Thank you for coming up with a PR @elizabethsjudd!

{{ carbon-icon 'Close16' class=(add @root.prefix '--modal-close__icon') }}
</button>
</div>
<div>
Copy link
Contributor

Choose a reason for hiding this comment

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

Why did you put additional <div> rather than simply adding focus trap element to the last? Note that no user-visible focusable element should be put outside <div class="bx--modal-container">.

<a href="#" class="{{@root.prefix}}--link">Learn More</a>
<button class="{{@root.prefix}}--btn {{@root.prefix}}--btn--primary {{@root.prefix}}--btn--sm"
type="button">Create</button>
<div class="{{@root.prefix}}--tooltip-wrapper">
Copy link
Contributor

Choose a reason for hiding this comment

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

Same question to overflow menu - Would you put the trap element next to <div class="bx--tooltip__footer">?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@asudoh the trap element needs to be outside of the content area of the tooltip not a sibling within it. Currently with the way that the trap element works, it can not be a direct sibling of the content area which in the case of tooltips content is any direct child of .bx--tooltip

Current structure of tooltip

<bx--tooltip>
  <bx--tooltip__caret/>
  <p>Tooltip content</p>
  <bx--tooltip__footer/>
  <!-- trap element is a sibling of content if placed here and doesn't work -->
  <trap-element>
</bx--tooltip>

There are a couple different options:

1. Scope the content area

We could add a div within the tooltip around any of the content including the footer and update the event listener to watch the new div instead of the tooltip element

<bx--tooltip>
  <bx--tooltip__caret/>
  <div>
    <p>Tooltip content</p>
    <bx--tooltip__footer/>
  </div>
  <trap-element>
</bx--tooltip>

2. Add a unique selector to the trap element

We could give a unique selector to the trap element and watch for it to get focus and when it gets focus, immediate move it. If that's the case we can keep the original HTML structure.

<bx--tooltip>
  <bx--tooltip__caret/>
  <p>Tooltip content</p>
  <bx--tooltip__footer/>
  <span tabindex="0" class="bx--focus-trap"></span>
</bx--tooltip>

Copy link
Contributor

Choose a reason for hiding this comment

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

My apologies, I seems to have missed this comment. I think 1. makes sense. BTW instead of wrapper node ref, let's move the root node up to the wrapper as above structure tells. If we need to refer to where the root node used to be, we can introduce options.selectorContent. Thanks!

<a href="#" class="{{@root.prefix}}--link">Learn More</a>
<button class="{{@root.prefix}}--btn {{@root.prefix}}--btn--primary {{@root.prefix}}--btn--sm"
type="button">Create</button>
<div class="{{@root.prefix}}--tooltip-wrapper">
Copy link
Contributor

Choose a reason for hiding this comment

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

Some question as another instance of tooltip body.

<a href="#" class="{{@root.prefix}}--link">Learn More</a>
<button class="{{@root.prefix}}--btn {{@root.prefix}}--btn--primary {{@root.prefix}}--btn--sm"
type="button">Create</button>
<div class="{{@root.prefix}}--tooltip-wrapper">
Copy link
Contributor

Choose a reason for hiding this comment

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

Some question as another instance of tooltip body.

@elizabethsjudd
Copy link
Contributor Author

@asudoh here's the thought process behind my work

  1. the focusable span needs to move with the floating menu so it's less DOM manipulation to grab a container that contains both the menu and the focusable tab vs having to grab both elements separately to move them
  2. most frameworks require a root element so by not having a containing div for some components that created sibling elements at the root and we should keep consistent HTML between vanilla and the other JS frameworks (React, Angular, Vue, etc)
  3. I thought the span has to be completely outside of the component (affected modal and tooltip)

@asudoh
Copy link
Contributor

asudoh commented Aug 7, 2019

Thank you for explaining @elizabethsjudd. 1. makes sense to me and I'll withdraw my comments to overflow menu due to <ul>/<li> semantics.

Wrt. 2., you are right that Angular, etc. requires root element. Modal already has two-level containers, though - One (<div class="bx--modal">) works as the root and the backdrop, another (<div class="bx--modal-container">) works as the container of the content. Given we don't have content in backdrop area, putting hidden content in the backdrop area makes more sense. An example can be seen here.

Wrt 3., I guess you meant where the content is put in with your "in component" wording. If so, my response to 2. would address it.

@elizabethsjudd
Copy link
Contributor Author

@asudoh I made changes to each of the components so the span is contained within the component and added the selectorContent feature to floating menus.

@elizabethsjudd
Copy link
Contributor Author

@asudoh While I'm working on some of the more JS extensive issues for a11y, I feel like it might be easier for me to work in the evening/night so that we are on an overlapping schedule so that I can I can get feedback quicker. Right now the issue that I'm having is that I'm spending an hour or so a day working on tasks and then waiting for you to be able to respond. I recognize that with a 13 hour time difference this is expected but as I have more issues open I'm building more merge conflicts (which are never fun). I've already ran the idea of working one day a week with this different schedule with my team and they agree with this shift to help with communication and hopefully speed up the contribution process. Can we coordinate a day/times for me to do this schedule shift?

@asudoh
Copy link
Contributor

asudoh commented Aug 8, 2019

The updated code looks basically good to me. Could you update tests? BTW thanks for ideas on collaboration, I pinged you offline for my ideas.

@elizabethsjudd elizabethsjudd marked this pull request as ready for review August 12, 2019 17:48
@elizabethsjudd
Copy link
Contributor Author

@asudoh tests have been updated and ready for re-review

@asudoh
Copy link
Contributor

asudoh commented Aug 12, 2019

Cool thanks @elizabethsjudd! Would you want to cover your enhancements in the test as well?

@elizabethsjudd
Copy link
Contributor Author

@asudoh the tests for the focus wrap feature seem to already be in there because the HTML has the old hidden input. Are you wanting me to test for the presence of the element or what?

Copy link
Contributor

@asudoh asudoh left a comment

Choose a reason for hiding this comment

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

Oh I didn't realize that, sorry @elizabethsjudd!

@elizabethsjudd
Copy link
Contributor Author

@carbon-design-system/developers This is still waiting on review.

@elizabethsjudd
Copy link
Contributor Author

@tw15egan or @emyarod can one of you review this so it can get merged? TIA

@joshblack joshblack requested a review from a team September 4, 2019 20:39
@ghost ghost requested review from aledavila and dakahn and removed request for a team September 4, 2019 20:39
@jnm2377 jnm2377 requested review from a team and removed request for aledavila and dakahn September 4, 2019 20:42
@ghost ghost requested review from jnm2377 and vpicone and removed request for a team September 4, 2019 20:42
@jnm2377
Copy link
Contributor

jnm2377 commented Sep 4, 2019

Will take a look at this!

@elizabethsjudd can you update the PR title? It should follow our commit message conventions for our changelog. You can read more about this in our developer handbook.

@elizabethsjudd elizabethsjudd changed the title floating menu focus wrap feat(floating-menu): add focus wrap element to components Sep 4, 2019
Copy link
Collaborator

@tw15egan tw15egan left a comment

Choose a reason for hiding this comment

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

LGTM -- sorry for delays!

Copy link
Contributor

@dakahn dakahn left a comment

Choose a reason for hiding this comment

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

Thanks so much for being patient our new(ish) system for assigning PRs to reviewers still has a few kinks to work out.

@elizabethsjudd
Copy link
Contributor Author

Thanks for taking a look @tw15egan and @dakahn!

@joshblack joshblack merged commit 34d1fdd into carbon-design-system:master Sep 4, 2019
@elizabethsjudd elizabethsjudd deleted the feature/floating-menu-focus-wrap branch September 6, 2019 16:28
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.

[Floating Menu] Focus wrap should work without having to put in extra elements
6 participants