-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
fix(overflow-menu): improve overall a11y #1115
Conversation
2351d55
to
bdd070e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
duplicate comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good update! i've done a bit of keyboard shortcut work before and would def like to take a look about implementing it here for another PR
Wow, great @tw15egan ! I'm swamped today, but I can run it through the screen readers tomorrow afternoon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
i put an Issue for keyboard implementation at #1119 (or let me know if you want me to just make further commits to this PR!) |
Great! Let's tackle that in another PR. @carmacleod no rush! I will ping you when the updates are pushed out live to the website |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tw15egan for jumping in! Just a question.
const shouldBeOpen = isOfSelf && !element.classList.contains(options.classShown); | ||
const state = shouldBeOpen ? 'shown' : 'hidden'; | ||
|
||
if (isOfSelf) { | ||
if (element.tagName === 'A') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code here is for preventing link from being followed. Did you find a new condition where event's default behavior should be prevented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was running into issues when trying to open the menu with the enter key. Perhaps I should I only prevent that if the key === enter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know if this is a better solution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tw15egan for the background and the suggestion! What I saw is that the change from keypress
to keydown
caused the overflow menu to be open (and thus focus moving to the overflow menu item) in the middle of the keystroke (of enter key). When user finishes the keystroke, the keypress
event fires on the overflow menu item given it's a <button>
and now has focus.
One way to get around with this is what you suggested. Great to have above finding as comments so that future maintainers/consumers can figure out why, if we go with this approach.
Another approach to address this is below, which directly removes the weird behavior described above, and thus reduces possibility of future issues (esp. wrt browser compatibility).
diff --git a/src/components/overflow-menu/overflow-menu.js b/src/components/overflow-menu/overflow-menu.js
index bdc031f..4a7ffc2 100644
--- a/src/components/overflow-menu/overflow-menu.js
+++ b/src/components/overflow-menu/overflow-menu.js
@@ -82,7 +82,16 @@ class OverflowMenu extends mixin(createComponent, initComponentBySearch, evented
);
this.manage(
on(this.element.ownerDocument, 'keydown', event => {
- this._handleKeyPress(event);
+ if (event.which === 27) {
+ this._handleKeyPress(event);
+ }
+ })
+ );
+ this.manage(
+ on(this.element.ownerDocument, 'keypress', event => {
+ if (event.which !== 27) {
+ this._handleKeyPress(event);
+ }
})
);
this.manage(
@@ -179,7 +188,7 @@ class OverflowMenu extends mixin(createComponent, initComponentBySearch, evented
const state = shouldBeOpen ? 'shown' : 'hidden';
if (isOfSelf) {
- if (element.tagName === 'A' || key === 13) {
+ if (element.tagName === 'A') {
event.preventDefault();
}
event.delegateTarget = element; // eslint-disable-line no-param-reassign
Don't hesitate to ping me if you have any questions/concerns. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@asudoh made the changes, but still found the need to prevent default when the space key is pressed (https://github.com/IBM/carbon-components/pull/1115/files#diff-cdb22c353cb80d123893d9f188477d1bR191) to prevent the screen from jumping down
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks alot @tw15egan! Could you add a comment to describing 32
key default prevention is for preventing screen from jumping down? I think this PR is good to go once it happens - Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the comment in, going to merge it! 😄 Thanks for helping out
77e0526
to
30a0949
Compare
9b3bbe8
to
c7b5770
Compare
bc61572
to
917081c
Compare
🎉 This PR is included in version 9.20.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
* fix(Modal): add keyboard trap Adds a keyboard trap to fix issue carbon-design-system#874 * fix(Modal): focus on modal itself when focus leaves Fixes the modal keyboard trap to be consistent with vanilla behavior. * fix(Modal): provide workaround for keyboard trap and floating menus Makes it possible to escape keyboard trap in modals when using floating menus * fix(OverflowMenu): focus on menu after closed This sends focus back to the overflow menu item after the menu gets closed. This is important for floating overflow menus in modals. * fix(OverflowMenu): get rid of redundant code * fix(Modal): improve support for floating menus in keyboard trap Made algorithm to check for floating menus check parents as well and made the list of floating menu selectors consistent with vanilla.
Closes #666
Adds in recommended a11y additions to Overflow Menu component
Changelog
New
aria-expanded
toggle when it is open / closeChanged
esc
can be used to close the overflow menu and return focus. The overflow menu can now also be opened with the space bar. Was not able to add in navigation via keyboard arrows, might want to open a separate issue for that.Testing / Reviewing
enter
andspace
to open / close the menu. Useesc
to close the menuaria-expanded
toggles correctly