-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[Block Library - Latest Posts]: Prevent opening the links in editor #40593
Conversation
Size Change: -512 B (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
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.
@ntsekouras I am worried about A11Y issues with this. By default, links are supposed to do something even if the action could be confusing. I am not sure preventing the click event is really a wise choice for screen readers or UX in general. Is there some way to pop an alert or something to give users some idea why nothing happens? That to me would be much better UX than links that don't work.
Thanks for the feedback @alexstine! Could it help with the screen readers case if we changed the link to something like Having more pop ups doesn't feel like an ideal UX to me and just noting that this is the approach for many other blocks that had the same problem, so if we find a better solution we should also revisit that cases. |
I just wanted to note that the RSS block also disables links by wrapping rendered HTML in the gutenberg/packages/block-library/src/rss/edit.js Lines 165 to 170 in f705d1c
|
There are previous discussions about this, but I can't find the specific link right now. There are 14 blocks that use a "pseudo link", an a tag where the href is #pseudo-link-block-name. 6 blocks are wrapped in |
Thanks for the details, @carolinan. I think I see a pattern here. Blocks that use server-side rendering are wrapped in the |
43e126e
to
110838d
Compare
It seems |
@ntsekouras, |
Oh, shoot.. You're right! |
110838d
to
0ff40d3
Compare
useDisabled just changes the I tried a css approach only for the editor( |
@talldan recently discovered a bug with @alexstine, what do you think about this method for preventing clicks? |
@Mamaduka If it is CSS, I doubt it will be accessible. The link should still be clickable via the keyboard and just not appear clickable for users with mouse. This doesn't feel right either. I know it may have been used with the navigation block, but I am never a fan of creating more accessibility issues just because it was used once before. Would really like to get this right. 👍 @joedolson Any ideas for having a disabled link? The whole problem to me is a disabled link doesn't make any sense at all. Seems like these should be buttons or something. Hate to hack it, but maybe something like this?
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled Hopefully there is a better way than that but it's all I got right now. I am moving over the next few days so I will likely be AFK for some time. |
It's certainly an interesting problem. From an accessibility standpoint, we want to present the same information to all users. The first step, then, is to determine what that information is and what makes it equal. If the links are not disabled, all users have the same experience, and the same risks - opening a link within an iframe, accidentally moving away from your editing context, etc. If they are disabled, then all users should also get the same experience: they should be able to perceive that this is a link, and that it is disabled.
So, ultimately, the problem is "how do we disable a link without also causing it to become unavailable to screen readers" - and there really aren't any semantics for describing that, because the hyperlink is intended as the fundamental linking characteristic of HTML. The disabled state of a hyperlink is plain text, and the way you disable a link is by removing the anchor element. This is a pretty weird state: browsable and readable text within an editing context that isn't editable, but also shouldn't be operable - only perceivable. It may be the best option to leave them as they are - normal links - but prevent their click events so that they're non-functional. I'm in favor of a pop-up that notifies the user that links inside these containers are disabled, although perhaps it only needs to happen once for each block. |
Once for each block sounds good to me as well. 👍 |
Maybe the information could be part of the block description? |
0ff40d3
to
022ea6b
Compare
I updated the code to use @costdev 's approach. |
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.
Looks good at first glance, just a couple of questions.
I'll try to test this soon if someone doesn't beat me to it.
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.
This looks great 👍 Thanks, Nik!
P.S. Left a small note, but feel free to ignore it. I might be missing some details 😄
What is the strategy for moving this out of the latest posts block to allow it to be re-used for other blocks with links? |
Personally I'd give it a bit time to be tested in the new GB version and then we can create an issue for updating what is needed. It's going to be pretty easy to be extracted to a reusable hook. |
@@ -466,7 +483,11 @@ export default function LatestPostsEdit( { attributes, setAttributes } ) { | |||
.join( ' ' ) } | |||
{ /* translators: excerpt truncation character, default … */ } | |||
{ __( ' … ' ) } | |||
<a href={ post.link } rel="noopener noreferrer"> | |||
<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.
In other places, we don't use real links at all. Example:
href="#comment-reply-pseudo-link" |
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.
It's been discussed thoroughly to find the best accessible solution for this and we'll probably replace this pseudo-links with the approach of this PR.
…40593) * use css to make them unclicable * show toaster with warning * update copy * announce once per block
I just cherry-picked this PR to the wp/6.0 branch to get it included in the next release: 8a4478f |
@ntsekouras Do you remember if this was ever followed up on? |
@carolinan I don't think we have.. |
What?
Fixes: #40075
This PR just prevents the default behaviour(that is opening the links) when clicking the link in
Latest Posts
block, in editor.Why?
There is no need to open the links in the editor and especially in the site editor where the content is loaded in an iframe, it might cause an inception effect.
Testing Instructions
Latest Posts
block in editor and in site editor and update the block settings to show the title, featured image with link and post excerpt(see more
is shown conditionally depending on the post's excerpt and block settings).