title attribute still not added to oEmbed iframe

Hi, is the module you're using https://www.drupal.org/project/ckeditor_media_embed?

I'm not too familiar with that one.

I'm pretty sure that the underlying mechanisms in the core Media system are separate from the contributed module's, so fixing one wouldn't have fixed the other.

Your CKEditor config should be able to natively support the core media embed system when Drupal 8.8 lands in December. Until then you may have better luck contacting the contributed module maintainer.

Good morning, the fix targeted in 3021452 pertains to media set up through a field formatter on media entity reference fields. I believe that in 8.8 and later, the same code will work with the core provided WYSIWYG button for embedded media.

Others will know better than me, but I think that it should be as easy as adding the new button to CKEditor, removing the one provided by the contributed module, and resaving content when 8.8 lands.

I can confirm the oEmbed iframe is indeed not receiving the title attribute. The outer iFrame does receive this though. This is using a clean Drupal 8.8.0 release with video media type. What is produced is:

<iframe src="/media/oembed?url=[your-url-here]&amp;max_width=0&amp;max_height=0&amp;hash=[hash]" frameborder="0" allowtransparency="" width="480" height="270" class="media-oembed-content" title="[Youtube Video Title]">
....

<iframe width="480" height="270" src="[youtubeUrl]?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
....
</iframe>

The reason for this is that youtube's API doesn't add the "title" attribute into the oEmbed response. The data is gathered and just passed through to the rendering.
https://api.drupal.org/api/drupal/core%21modules%21media%21src%21OEmbed%...

A quick google search for "Google oEmbed title attribute" will result in a large amount of results of people having the same issues.

The issue you have referenced is about the oEmbed field formatter. It doesn't really matter if its in a media type or elsewhere.

I can't speak to anything integrating with CKEditor Media Embed Plugin since I have never used that. If you have a particular issue with that module, it's best to report an issue on that module's page. but the issue you have reported is relevant to the oEmbed field formatter still.

Yes I am currently using core's functionality to embed all media types and display media as fields. It does display the same behavior because an embed media is just a rendered media entity so it still uses the oEmbed field formatter to display the iframe contents. The output of the video is identical for a field using oEmbed formatter as it is in the CkEditor (since the media uses the same formatter).

The easiest way to try that functionality is to install "Standard" profile, enable the media and media library modules and configure the text formats to allow embedded media (also add the media library button to the toolbars). Doing this will produce the code snippet I provided in comment #15

Your referenced issue is about the oEmbed field formatter provided by the media module and only works on media entities. The oEmbed field formatter takes a text field and renders out an iframe with the youtube video iframe nested inside. This is what happens when a media entity is embed in a Ckeditor or when the media entity is displayed by itself outside of the ckeditor.

The "Remote video" media type provided by Drupal core "standard" profile contains a text field where a user creates media entities by entering the url into a text field. This text field is then rendered out using the oEmbed field formatter to produce the iframes of the desired video. That field is then reused when embedding the media entity via CKEditor or an entity reference field.

If you do not have the media module enabled at all or are altering the embed code directly as HTML, your issue sounds to be unrelated to https://www.drupal.org/project/drupal/issues/3021452

If you are new to media library provided by Drupal core, I strongly suggest you review its functionality in the UI. A short demo from Dries is on youtube https://youtu.be/UoT2oava9ns

I fear we are getting off topic of the reported issue. I've created a short youtube video that shows the setup using "Standard" profile. At the end you will see the nested Iframe doesn't contain a "title" attribute

https://youtu.be/O_cyEOWsf_s

On the topic of the nested iframe lacking a title attribute, see https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/titl....

An accessibility expert may need to chime in, to confirm, but I would expect that title attribute inheritance should apply here.

Did a user experience an accessibility issue here or is the concern stemming from an automated checker tool?

@xeM8VfDh I'm seeing this just now in our Drupal profile. From an accessibility standpoint, particular for someone using a screen reader, hearing an empty frame or a double frame announced might be confusing as far as what the content is and how to interact with it.

If the title inheritance is supposed to work as the MDN docs stated, then it seems logical the second <iframe> should inherit an accessible name from the parent iframe. But, with VoiceOver/Safari and VoiceOver Chrome on macOS, the second frame announces as "frame, 0," due to not having a coded <title> attribute:

In NVDA/Firefox and Chrome/Windows 10, it announces as "[title of media], frame frame." That will get treated as one grouping at least (rather than two iframes), but it would be repetitive to hear "frame frame" each time there's a video embed. I haven't yet had the chance to test with JAWS.

If reducing the double iframe can be explored, that would be ideal since it gets rid of the redundancy and ensure there's an accessible title on the right iframe. If that can't happen, then the secondary frame should have some kind of name. How to make that solution not redundant would need to be explored though--hearing "frame [title of frame]" twice would also become redundant.

I think that what would help sort out this issue is steps to reproduce, added to the issue summary, and starting from a clean installation of Drupal. That would help us triage this issue and take whatever action is needed.

I've updated the issue description to include steps to reproduce, and removed the "Needs steps to reproduce" issue tag.

Looks like this falls under WCAG 4.1.2
https://www.davidmacd.com/blog/is-title-attribute-on-iframe-required-by-...

Beyond that, I've never heard a reasonable explanation of why we need to embed an iframe in another iframe...

A change notice that explains the ability to modify the outer iframe, https://www.drupal.org/node/3169717, alludes to the fact that this is done for security reasons.

It is also alluded to in an inline comment in the OembedIframeController:

// Even though the resource HTML is untrusted, IFrameMarkup::create()
// will create a trusted string. The only reason this is okay is
// because we are serving it in an iframe, which will mitigate the
// potential dangers of displaying third-party markup.

I infer that this effectively sandboxes the inner iframe so that it cannot display forms, trigger alerts/pop-ups, and run plugins from the site DOM, similar to the goal of the iframe sandbox attribute.

I'm not sure if that amounts to a reasonable explanation or not... :)

Barring an immediate solution in core, sites can add the title value to the inner iframe via preprocessing:

function mymodule_preprocess_media_oembed_iframe(array &$variables) {
  /** @var \Drupal\media\OEmbed\Resource $resource */
  $resource = $variables['resource'];
  $media = $variables['media'];
  $html_dom = Html::load($media);
  $iframes = $html_dom->getElementsByTagName('iframe');
  foreach ($iframes as $iframe) {
    if (!$iframe->hasAttribute('title')) {
      $title = $resource->getTitle() ?? "Embedded content from " . $resource->getProvider()->getName();
      $iframe->setAttribute('title', $title);
    }
  }
  $variables['media'] = Html::serialize($html_dom);
}

(Remember to use Drupal\Component\Utility\Html;!)

This will load the inner iframe into a DomDocument type object format, then check the iframe for the presence of a title tag. If not present, it will insert one, using the provider's title attribute, if available, and the provider name as a fallback.

I co-maintain https://www.drupal.org/project/iframe_title_filter , so I'll raise the question of adding this preprocess logic to that module, as it does seem to be in the purview of that module.

The point of the "double iframe" is that while most providers do return an iframe as part of the oembed response, the spec allows for arbitrary HTML, CSS, and JS to be returned from a third party provider (youtube, vimeo, etc...). The arbitrary JS part is where the concern comes from.

Surfacing such content on separate domain (the outer iframe, ie "no-admin-session-cookies.mysite.com") can effectively prevent common admin session takeover tactics if configured correctly.

Drupal is one of the few oembed implementations that actually implement it the way that the oembed specification suggests.

I had thought that it was determined that the inner iframe would inherit the outer iframe's title via Title Inheritance (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/titl...).

The point of the "double iframe" is that while most providers do return an iframe as part of the oembed response, the spec allows for arbitrary HTML, CSS, and JS to be returned from a third party provider (youtube, vimeo, etc...). The arbitrary JS part is where the concern comes from.

Maybe this has already been covered, and forgive me if I'm misunderstanding the discussion, but I know of nothing in core that is actively double-iframing anything. Whatever an oEmbed provider returns is considered untrusted and therefore sandboxed in a single iframe. And, as far as I know, that's where it ends for core. If the provider returned markup that includes an iframe, core has no opinion about that and won't try to modify it in any way. Since core absolutely cannot rely on, or even reliably predict what an oEmbed provider will return, I personally think that's the right move.

I agree with @mark_fullmer that further processing should be done by a custom preprocess function, or a contrib module to deal with more advanced modifications to whatever the oEmbed provider returns. I'm not sure core should have an opinion about this. Therefore, my inclination is to close this issue as a wontfix. I won't do that yet, since I'm open to being convinced otherwise, but it sounds to me like this is a provider-specific quirk that core should not address directly.

I think it's a fair assumption that YouTube may have been the provider in question for the original issue creator. While the core isn't double-iframing stuff directly, the end result is indeed confusing on the surface when one doesn't have first hand knowledge of where Drupal markup ends and where Provider markup begins.

I think that adding the title is something that YouTube should be doing. I agree that Drupal (certainly not the core) shouldn't be the one to fix a YouTube service a11y problem.

Perhaps more importantly, can an a11y maintainer check if there's an actual problem affecting users here, if it's just a false positive due to automated tools messing up on title inheritance, or if something else is amiss?

Perhaps more importantly, can an a11y maintainer check if there's an actual problem affecting users here, if it's just a false positive due to automated tools messing up on title inheritance, or if something else is amiss?

Agreed. Tagging for accessibility review.

Would be great to support authors to do this by default https://accessibilitycluster.com/main-results/video

We could apply a similar fix to what wordpress did:
https://core.trac.wordpress.org/ticket/40245
https://core.trac.wordpress.org/changeset/44942

The gist is that we can safely add a title attribute if the given conditions are met:

• the oembed metadata includes a "title" property,
• is a "rich" or "video" embed,
• includes an iframe tag,
• but the iframe tag doesn't have a title attribute

The title metadata/property can get added as the title attribute. This leaves two unresolved issues:

• The video title is not always the most accessible title for the iframe
  This could possibly be addressed by prefixing the title e.g. with "Video Embed: {title}", but then maybe we have to worry about translating that.
• Performance -- do we want to go the wordpress way of regexes, or is it better to use a parser? Note that the oembed markup gets cached, so this isn't a huge issue, and correctness is probably the best approach.

Moving this down to active because it sounds like there is still more discussion to be had.

Perhaps the Drupal community as a whole should chime in on https://groups.google.com/g/accessible/c/d-5z87lOWeY/m/MW1zLZiOCAAJ and push the vendor to fix the issue globally on every single YouTube oembed implementation in the world -- far beyond the scope of Drupal.

Fundamentally, this is Google's problem to fix. Drupal can provide a hackaround for it, but the real problem is much deeper, affecting so much more of the internet than is powered by Drupal.

Marking as postponed until google fixes it on their end.

Interestingly enough, https://www.youtube.com/oembed?url=http%3A//youtube.com/watch%3Fv%3DM3r2... DOES seem to add a title attribute.

Perhaps Google rolled out the feature, but it's not applied to every video? Or perhaps it's something that content creators need to opt into?

--

Just to clarify my opposition to attempting to address this in core. We cannot possibly be expected to fix all a11y issues injected into pages by third parties. While it's pretty obvious that YouTube is the most popular target to pick on here, there are probably thousands of other issues slipping through from any of the other providers.

Opening the door here puts us on a slippery and somewhat fragile slope. The oEmbed technology makes it really clear that the markup returned by the third party is arbitrary. For a concrete example, it's a mistake to assume that YouTube will always send back an iframe in its response.

This really sounds like a problem to solve in contrib to me. - or perhaps it can be addressed more responsibly by simply boycotting vendors that do not prioritize accessibility.

--

Update: I just checked a couple other videos -- looks like the title attribute is present in the YouTube response! Is this even an issue anymore?!

just checked a couple other videos -- looks like the title attribute is present in the YouTube response! Is this even an issue anymore?!

I can corrobrate that the title attribute is also present on a video that was previously used to demonstrate its absence. There's a related issue in the contrib module iframe_title_filter where I note this. I haven't been able to find documentation that YouTube/Google fixed this, though.