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

Fix: Keyboard navigation should only focus meaningful elements #970

Merged
merged 3 commits into from
Apr 1, 2019

Conversation

jstoffan
Copy link
Collaborator

No description provided.

@boxcla
Copy link

boxcla commented Mar 30, 2019

Verified that @jstoffan has signed the CLA. Thanks for the pull request!

@@ -33,8 +33,8 @@
</div>
</div>
</div>
<div class="bp" tabindex="0" data-testid="bp">
<div class="bp-content" tabindex="0" data-testid="bp-content">
<div class="bp" data-testid="bp" tabindex="-1">
Copy link
Contributor

Choose a reason for hiding this comment

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

Do both of these need to be programmatically focusable? It looks like BaseViewer focuses on .bp-content when autoFocus is enabled.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The ContentPreview Element auto-focuses on .bp and the Preview SDK auto-focuses on .bp-content.

setTimeout(() => this.resize(), THUMBNAILS_SIDEBAR_TRANSITION_TIME);
setTimeout(() => {
this.resize();
this.thumbnailsSidebarEl.style = style;
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like setting style directly as a string is discouraged (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/style#Setting_styles).

Also, does this affect the animation transition at all?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It does appear to affect the hidden -> visible transition. I'll update it to remove the display: none immediately rather than via setTimeout for that case. Good catch!

@@ -232,9 +232,9 @@ class ThumbnailsSidebar {
* @return {HTMLElement} - thumbnail anchor element
*/
createThumbnailNav() {
const thumbnailNav = document.createElement('a');
const thumbnailNav = document.createElement('button');
Copy link
Contributor

Choose a reason for hiding this comment

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

Does button work better than a in this case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Anchors without an href attribute are considered placeholders rather than links and aren't included in the tab order (source). Since we just want to response to a user action rather than navigating, a button seems more semantically correct and also obviates the need for tabindex="0"

@ConradJChan
Copy link
Contributor

By adding the display: none, we can update the e2e helper functions to to check sidebar visibility normally (.should('be.visible') instead of checking via the presence of the classname

@jeremypress jeremypress changed the title Fix: Keyboard navigation shoud only focus meaningful elements Fix: Keyboard navigation should only focus meaningful elements Apr 1, 2019
@jstoffan jstoffan merged commit cb6fe25 into box:master Apr 1, 2019
@jstoffan jstoffan deleted the fix-tabindex branch April 1, 2019 21:13
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.

3 participants