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

PostPublishPanel: return focus to element that opened the panel #11543

Merged
merged 27 commits into from
Nov 9, 2018

Conversation

oandregal
Copy link
Member

@oandregal oandregal commented Nov 6, 2018

Addresses the last bit of #4187 (comment)
Depends on #11584
Closes #4187

Description

This PR manages where focus goes after the PostPublishPanel is closed. At the moment, it's lost and just goes to the body element.

peek 2018-11-09 13-33

Changes this PR introduces:

  • Uses the withReturnFocus HOC to return focus to the element that had it before opening the publish sidebar.
  • Changes the Header settings not to be unmounted when the publish sidebar is opened. This requires us to hide the "Saving draft" button, because it is not completely hidden by the publish sidebar.
  • Uses a single component as the Publish button, instead of the two we had. This helps in that the DOM node that opens the publish sidebar isn't changed by a new component. It does so by teaching the PostPublishButton how to behave like a button (publish directly) or a toggle (opens the publish sidebar instead).

Questions

  • Should we deprecate PostPublishToggle in favor of the PostPublishButton component in this PR We'll go with deprecating it and removing it in 5.1.

@oandregal oandregal self-assigned this Nov 6, 2018
@oandregal oandregal added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Nov 6, 2018
@oandregal
Copy link
Member Author

This approach gotchas:

  • we need to hide the "Save draft" button as it isn't hidden completely by the PostPublishPanel.
  • we need to refactor the publish toggle / button components to use only one element, otherwise, focus will be lost after changing from toggle to button (for ex: using the toggle to open the PostPublishPanel, which will get unmounted once the post is published in favor of the button).

@oandregal oandregal added the [Status] In Progress Tracking issues with work in progress label Nov 7, 2018
@oandregal oandregal force-pushed the update/focus-after-post-publish branch 3 times, most recently from ce47e64 to 5067de3 Compare November 8, 2018 13:33
@oandregal oandregal changed the base branch from master to fix/disable-publish November 8, 2018 13:34
@oandregal oandregal force-pushed the update/focus-after-post-publish branch from 5067de3 to 0f99f9d Compare November 8, 2018 13:35
@oandregal oandregal added this to the 4.4 milestone Nov 8, 2018
@oandregal oandregal force-pushed the update/focus-after-post-publish branch from 0f99f9d to 4f9a323 Compare November 8, 2018 15:10
@oandregal
Copy link
Member Author

So, against my original concerns, this PR has ended up being a fine approach. It is ready for review. The only thing I wonder is whether we should deprecate the toggle component. Normally, I'd do it, but given the point we're at in the release cycle I'd want to hear more opinions.

@oandregal oandregal removed the [Status] In Progress Tracking issues with work in progress label Nov 8, 2018
@oandregal oandregal requested review from a team and tofumatt November 8, 2018 15:13
Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

I'm unclear on whether #11584 needs to be merged before this will work as intended—is that the case?

Right now after closing the panel focus seems lost and is not returned to the element that opened it (the "Publish" button).

@tofumatt
Copy link
Member

tofumatt commented Nov 9, 2018

For what it's worth: if we aren't using the PostPublishToggle component anywhere internally it seems the kind of thing we could deprecate as I'm unsure where else it would be being used…

But then we're past API freeze and should respect that, maybe we deprecate it as normal and remove it in a few versions, recognising that that'll be after WordPress 5.0.

Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

I'll try this again a bit later today after I'm back from squash, but for now I have a few change requests regarding the deprecations.

Any chance you could record a screencast of this working on your machine? It would help to see what you're seeing 😄

packages/edit-post/src/components/header/index.js Outdated Show resolved Hide resolved
packages/edit-post/src/components/header/index.js Outdated Show resolved Hide resolved
<PublishButtonLabel forceIsSaving={ forceIsSaving } />
{ componentChildren }
<DotTip tipId="core/editor.publish">
{ __( 'Finished writing? That’s great, let’s get this published right now. Just click “Publish” and you’re good to go.' ) }
Copy link
Member

Choose a reason for hiding this comment

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

I find "Just" to be a weasel word and would like to remove it, but I know that's a bit out-of-scope for the PR. Just saying' 😆

@oandregal
Copy link
Member Author

oandregal commented Nov 9, 2018

@tofumatt Added a GHIF in the description. This is what I've done (the image is not great):

  • Click the "Publish" button.
  • Tab and Intro to close the pre-publish panel.
  • Intro to open the publish panel again.
  • Intro to publish the post.
  • Shift+Tab and Intro to close the post-publish panel.

At this point, the Publish button has the focus although it's disabled. Then, I've done a few Tabs and Shift+Tab to move focus among the Header settings components forward and backward to demonstrate it.

Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

I tested this locally and now it's working perfectly. Thanks so much!

I left a few suggestions but once they're addressed 🚢

Thanks so much for this! Once it's merged, all the Gutenberg merge accessibility issues are covered! 🎉

@@ -1,5 +1,9 @@
Gutenberg's deprecation policy is intended to support backwards-compatibility for releases, when possible. The current deprecations are listed below and are grouped by _the version at which they will be removed completely_. If your plugin depends on these behaviors, you must update to the recommended alternative before the noted version.

## 4.6
Copy link
Member

Choose a reason for hiding this comment

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

Best to keep this consistent with the rest of the file:

Suggested change
## 4.6
## 4.6.0

<div className="edit-post-header__settings">
<div className="edit-post-header__settings">
{ ! isPublishSidebarOpened && (
// This button isn't completely hidden by the publish sidebar.
Copy link
Member

Choose a reason for hiding this comment

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

👍

This is an awesome, super-helpful comment. Ace!

const toggleProps = {
'aria-disabled': isToggleDisabled,
'aria-expanded': isOpen,
className: 'editor-post-publish-panel__toggle',
Copy link
Member

@tofumatt tofumatt Nov 9, 2018

Choose a reason for hiding this comment

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

editor-post-publish-panel__toggle seems like the right name.

EDIT: oops, I meant editor-post-publish-button__toggle

Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

Damn, looks like we shouldn't be deprecating stuff here:

#11679 (comment)

Might be best to remove that for now. Really sorry, I thought deprecations would continue as normal, but seems like the mechanism will be different going forward, so for now maybe we shouldn't.

@aduth
Copy link
Member

aduth commented Nov 9, 2018

Damn, looks like we shouldn't be deprecating stuff here:

#11679 (comment)

The changes of #11679 are not really relevant to speaking to whether or not a thing can be deprecated still. The changes there are merely a reflection of the fact that the dependency becomes unused once the current deprecations are removed.

@tofumatt
Copy link
Member

tofumatt commented Nov 9, 2018

Right, but I thought @youknowriad was saying deprecations after 4.3 we don't know how we'll handle them.

Maybe I'm confused and these deprecations are fine? I'm confused 😅

@youknowriad
Copy link
Contributor

Right, but I thought @youknowriad was saying deprecations after 4.3 we don't know how we'll handle them.

Since we said we're in API Freeze, yes I did say that and I think we should be more strict now to keep our engagements. We shouldn't deprecate anything impactful.

I think PostPublishPanelToggle is not going to impact any plugin though because it's something npm consumers will likely use but less WP plugins.

@tofumatt
Copy link
Member

tofumatt commented Nov 9, 2018

Fair enough then; changed back to approved 😄

@tofumatt
Copy link
Member

tofumatt commented Nov 9, 2018

We're actually going to merge this into 4.3; I'll take it over from here and tweak the deprecations. Thanks again for working on this 👍

@youknowriad youknowriad modified the milestones: 4.4, 4.3 Nov 9, 2018
isPrimary
isLarge
onClick={ onClick }
disabled={ isButtonDisabled }
Copy link
Member

Choose a reason for hiding this comment

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

For what reason did we need to stop passing the disabled prop? While this and many other buttons in the header appear as disabled, they don't act as disabled. You can immediately press "Publish" on a new post and the publish panel is (wrongly?) shown.

As it relates to focus return, it's not clear to me how it's relevant, since the panel would have presumably never been opened if it were disabled.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch. #13194 should fix it.

The disabled property didn't play well with the withFocusReturn HOC, IIRC. I can dig up the exact details if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Publishing Flow accessibility
5 participants