Require an initial click on embed previews for interactivity #12981
Conversation
|
This fixes more issues too, such as if you embed a twitter timeline, you can get caught scrolling the timeline as you use the mousewheel to scroll down the page. But with this, you scroll as expected. |
| .wp-block-embed-interactive-overlay { | ||
| position: absolute; | ||
| width: 100%; | ||
| height: 100%; |
There was a problem hiding this comment.
when using top, right, bottom, left, there's no need for width and height.
| </figure> | ||
| ); | ||
| { ! interactive && <div | ||
| role="dialog" |
There was a problem hiding this comment.
this div is not an ARIA dialog, doesn't have a particular semantic meaning nor can be focused so this role needs to be removed
|
Left a couple minor comments. More importantly, seems to me while this approach helps with selecting the block, it also introduces a potentially confusing interaction model, Especially users who use input devices other than mouse / touch or assistive technologies might be confused. Also, I'm not sure mouse / touch users would understand why a first click doesn't "play" and a second click does. I'd tend to think we'd need a different approach. We should always take into consideration all devices and design for all users. Keyboard users, for example, can still get to the player controls: in the screenshot below, I've used a rgba red background on the overlay to make it clearly visible:
As you can see, my mouse is on the paragraph above the embed. With the keyboard, I'm still able to tab through all the player controls and activate them (see the "watch later" control). Many users make a mixed use of mouse and keyboard: most likely, they would be confused by the different interaction with the overlay. If we really want to make the player "inert" to allow a better block selection mechanism, then I'd tend to think the player should be "inert" for all users until the block is selected. Offering a different experience to different users seems to me not so ideal. A while ago, there has been an experiment to introduce a new selection and navigation mechanism with the blocks: see "navigation and edit mode" tried in #5709 and recently revived with the proposal in #11581. I'd be in favor of pairing the experience for all users: navigation / edit mode would help users to have the same experience, regardless of the device they use. |
That's not possible, unfortunately. If we have an overlay making previews inert based on |
|
I'm about to head out for some family things, but I have ideas to share that could get a version of this in. We also have some past mockups that I think we can dig up. I think there's a path forward, but I'll share more tomorrow. |
It is possible, at least for keyboard users. I've pointed to #5709 / #11581 have you had a look at those? Screen reader users would need something more, as with a screen reader it's always possible to use arrows navigation to get the content.
I disagree 🙂We're aiming to build accessible software. The first step is providing the same content and experience to all users in a device-independent way, as this is the real nature of the web. |
|
Thank you for fearlessly taking a stab at this. I strongly agree this is something we need to fix. Regarding the specific way we fix this, I have reopened #483 which has a bunch of mockups, and was supposedly fixed in #5730. Do we know why that fix regressed? CC: @aduth In any case, to address the mouse/keyboard situation, can the mockup on that old ticket inspire an approach that would be the same for both?
I imagine it could work like this:
Is the above possible? Does it address the keyboard/mouse issues? If we need for you to be able to interact with the contents of the embed inside the editor, we could add a a button on top of the dimmed/disabled embed: "Interact with content" (or a better label). Clicking this button would make the embed not disabled again, until you deselect the block. It could look like this:
Can we use tabIndex to make the embed container un-interactable by keyboard until it has been "unlocked" with the button press? |
This is possible as long as we change the
As I understand it, it would need to be done this way with an interactive element for screen readers to work properly. One of the issues brought up in the core editor chat was that the static |
But a static div with a button inside, clearly labeled, perhaps even with a verbose description, that would presumably be fine, right? I think we need to lean into the design principle that a selected block can show additional controls and interface. So I think this shouldn't be a problem. |
Yes, absolutely. The problem with this PR is it's only a static div, no elements that a screenreader would recognise. So the second mockup would be great! However, if we got the |
Ideally yes, even if not as part of this PR (and by that I mean I think it's okay to ship a small fix and then a bigger fix later). But I have a feeling this PR might need to go into 5.1 as opposed to 5.0.3 which might not happen depending on things. But yes, because the way it is right now, any YouTube videos appear "interactable" even if they aren't (i.e. they require two actions). It's probably better to embrace that we are intercepting the actions and making it more visually clear what's happening. The balance in all these cases is finding a way that isn't creating "heavy UI", so as to consider all aspects of accessibility, including use cases 1 and 6 in this poster. But because this "action interceptor UI" is only visible when the block is selected, it is not additional UI that weighs down the whole thing, and it's clear how to "get it away" (with the button action). |
Short version: no 🙂 Long version: assistive technologies do allow to navigate to elements with a tabindex -1 so the embed content would still be interactive for these users. As accessibility team we should try to explain this better to all the designers involved, as it seems to be a recurring question. Looking at the history, I see in in #517 (comment) etc. there is also some discussion about the different embed types. Should this apply to only videos or to all the embed types? I see the overlay approach was already implemented and then removed in #816. Seems to me the main concerns were about scoping the CSS #816 (comment) and problems with a "resizing iframe" #816 (comment) Later, a solution that used the blur event was implemented in #4011 to my understanding that's no longer possible after #4872. Lastly, the issue was fixed again in #5730 as Joen mentioned. Checked in Gutenberg 2.9.0 it worked. Worth noting the video couldn't be played at all, not even after multiple clicks. Stopped working in Gutenberg 3.0.0 so maybe this part is a regression? Granted, even in 2.9.0 keyboard and assistive technologies users were still able to tab to the video player so even then the implemented solution was mouse-only. Trying some lateral thinking: in #483 Joen mentioned "Abstract live preview". Do we really need to display a fully functional video? Is it possible to display the video poster image instead? Do all video embed providers have a poster image in their response? This would also make the page way lighter. A button #483 (comment) could be used to load the actual video + player. |
So long as these embeds are super basic (and they really are just the oembeds at this point), I don't personally think they should be fully functional. Though I would really hate for us to go into the abstracted live preview territory, even if I did think so in the past. With the improvements made to editor styles, the editor itself is increasingly a preview of the final content, and discrepancies in that preview are therefore likely to cause user concerns: "Am I doing this right? It looks wrong". This used to be solved, and I know this is solved in the classic editor. I think Ella is AFK, but perhaps @azaozz can provide insights? For what it's worth, if we can make the entire embed completely inert, for mouse and keyboard users alike — totally un-interactable — I think that would be fine, so long as the visual of the embed is the same. And if we did this, yes, it would be nice if we could do this for only videos, so non video embeds were still interactible. |
😭
😭 Ok, then we should remove the
🔔 🔔 🔔 🔔 I think we might have a winner here 😁 Allowing an email to show the poster with a button which displays an interactive full preview when clicked sounds like it sovles all of this.
Sorry, but they really should be for the next round of embed enhancements that change things like YouTube start time, player theme, branding, Twitter media options, etc.... It would be a poor UX if we had to get the user to preview their post to check all the options were set right and looked right, when the current implementation of that branch (admittedly, only on my local machine right now...) updates the preview live. |
Looks like it used the same approach as we had before with the FocusableIframe, which we can't use now because of the API change. |
Yep I think it's a TinyMCE thing. However, even in the Classic Editor users are able to get to the player when using a screen reader... it's just a bit more difficult.
Yeah I'd love to see some exploration in that direction.
Not sure #4011 / #4872 have something to do with that 🙂 there must be something else that makes the |
I agree, but if step 1 was to make the embeds completely inert, step 2 could then be to introduce the dimmer + button from the mockup to make it not inert, would that work? |
If you do step 1 by itself, you get rid of embed previews completely for things like Twitter that have no thumbnail. Please don't do that 😄 |
Well, I'm not referring to the abstracted preview that Andrea suggested, I'm not in love with that idea. I'm suggesting we still have the embed exactly as it is in this very branch, but it just utterly inert, you can click it to select the block, but nothing inside the iframe is interactible. I'm not sure it's possible, clearly we can't redirect the tabindex to let you not select it, but I know that for clicks we can use |
|
The reason for the state was because |
|
Ah, yes! And my memory must be failing me, since I had just remarked the other day on the specific comment describing this behavior 😅 I confirmed that a multi-selection wrongly occurs with my naive alternative implementation, so feel free to proceed. |
|
Thanks to everyone for the help on this one! |
notnownikki
deleted the
update/embed-interactive-content-requires-initial-click
branch
This fixes the block selection UX for video embeds. Previously the click on the video to select the block would start the video playing. Now that previous require a click to become interactive, the initial click selects the block without side effects.
This fixes the block selection UX for video embeds. Previously the click on the video to select the block would start the video playing. Now that previous require a click to become interactive, the initial click selects the block without side effects.
Description
This fixes the block selection UX for video embeds. Previously
the click on the video to select the block would start the
video playing. Now that previews require a click to become
interactive, the initial click selects the block without
side effects.
How has this been tested?
Embed a youtube video. Click outside of the block. Click the video. The block should be selected, and the video should not start to play.
Types of changes
Bug fix
Checklist: