[Block Library - Latest Posts]: Prevent opening the links in editor #40593
Conversation
ntsekouras
added
[Type] Bug
ntsekouras
requested review from
Mamaduka,
gziolo,
ndiego,
aristath and
carolinan
|
Size Change: -512 B (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
@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.
alexstine
added
the
[Focus] Accessibility (a11y)
|
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 |
ntsekouras
force-pushed
the
fix/latest-posts-links-in-editor
branch
from
43e126e
to
110838d
Compare
It seems |
|
@ntsekouras, |
Oh, shoot.. You're right! |
ntsekouras
force-pushed
the
fix/latest-posts-links-in-editor
branch
from
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? |
|
Just wanted to link this discussion back to this issue: #15799 — that links "hidden" by Disabled are still functional with a keyboard/screen reader, since they're using the |
ntsekouras
force-pushed
the
fix/latest-posts-links-in-editor
branch
from
0ff40d3
to
022ea6b
Compare
I updated the code to use @costdev 's approach. |
|
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. |
adamziel
added
Backport to WP Minor Release
| @@ -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.
In other places, we don't use real links at all. Example:
There was a problem hiding this comment.
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 |
adamziel
removed
the
Backport to WP Minor Release
What?
Fixes: #40075
This PR just prevents the default behaviour(that is opening the links) when clicking the link in
Latest Postsblock, 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 Postsblock in editor and in site editor and update the block settings to show the title, featured image with link and post excerpt(see moreis shown conditionally depending on the post's excerpt and block settings).