This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The embed element has no fallback abilities, and thus is completely useless for: - users of accessibility technology - users of text browsers or other browsers which don't support plugins (but still are required to support <embed>) this includes search engines and data mining tools - users with plugins disabled - users with a missing plugin for the required content and no ability to install one In addition, the embed element has no use that could not be served by the object element, that in addition has rich fallback and more media types usable (including still images and nested browsing contexts). Therefore, the embed element, its attributes and its processing requirements, should be moved to the obsolete section (where currently reside applet and marquee) Conformance checkers should inform the page author about the object element (as validator.w3.org always did) and conforming documents must not include an embed element.
(In reply to comment #0) > - users of accessibility technology Could you please elaborate? (Plug-ins are themselves responsible for being accessible.)
(In reply to comment #1) > (In reply to comment #0) > > - users of accessibility technology > > Could you please elaborate? (Plug-ins are themselves responsible for being > accessible.) > Plugins are not responsible for that, their responsible for rendering the embedded content, which is most of time not accessible. Flash, for example, are not accessible to users with screen readers (you cannot syntethize the content of a flash animation), users with color disabilities (you cannot limit yourself to red/blue while designing), users with motor disabilities (there is no tab-index or access-key), etc. Java can be even worse, being completely generated by imperative code. Video is an other example: most video formats don't provide appropriate captioning content. This is one of the reasons a <text> element was proposed for HTML5 video. Music is a third example: if an user can't hear, having a rendered audio plugin in a page can be disturbing, I imagine. And you cannot of course expect that .mp3 includes the lyrics in text format or that the mp3 browser component tries to infer the words from audio analysis (it is difficult to understand them by humans, can you imagine an automated algorithm?). As such, it is often disabled by such users, and because of this and the existence of more accessible alternative solution, embed should be obsoleted / deprecated / made non conforming.
(In reply to comment #2) > Plugins are not responsible for that, their responsible for rendering the > embedded content, which is most of time not accessible. > Flash, for example, are not accessible to users with screen readers... No, that is incorrect. Recent versions of Flash have begun to introduce the ability to make Flash based content accessible. Last I heard, there were some limitations with current support in some screen readers, though that was a while ago and I'm not sure how much progress has been made since. But the point is that Flash and other plugins can and should be implemented using accessible techniques. For more info, see http://www.adobe.com/accessibility/products/flash/
That's good to hear, although it looks too much like @summary for table (basically, an alternative text-only version of the animation): we're back to the built-in vs bolt-on accessibility debate. Besides, most users are not aware of that or use old software that cannot show accessible information, and most of existing Flash content does not use such techniques. It is much easier to change the enclosing HTML than to reformat a flash animation (which requires expensive proprietary software).
Plugins are native applications, and have (or should have) built-in accessibility. Authors who need fallback can use <object>. What harm does <embed> do? Unless there is a specific harm caused, I will leave it as conforming, since so many authors use it.
Quoting from http://www.w3.org/mid/389DB061A33346478A6C4F633FE6E96F@joe1446a4150a8 ------8<------ Speaking of editorial control, I still think 4.8.4 The embed element now in Working Draft needs to be removed from this main list and moved to be obsolete. I see the bug 7075 is stopped due to given opinion that <embed> doesn't do any harm. Still, I respectfully disagree now more than ever. Now let's look at this again and decide that <embed> then-innovative and then-important although ill-specified and documented element msut not even be considered for support in HTML 5. Sure, old browsers can do it if they think they need to, but support shall be optional. It will be possible for an author to find out that <embed> is not supported in HTML 5 by using an HTML 5 validator. Any authoring tool can produce the <object> element and supporting <param> pairs to replace any <embed> element. In fact, for certain media, the tool might generate to <audio> or <video> elements. So absolutely dropping <embed> will be better and more fun for everyone involved. With added depth in the discussion of <canvas> we can also see an important detail. If <canvas> is actually presenting any problems with fallback and/or interpretation by alternative user interface requirements, then <embed> is totally impossible. Thank You and Best Regards, Joe ------8<------
> It will be possible for an author to find out that <embed> is not supported in > HTML 5 by using an HTML 5 validator. Any authoring tool can produce the > <object> element and supporting <param> pairs to replace any <embed> > element. We tried that with HTML4 without success for 10 years. <canvas> and <embed> are very different; <embed> embeds a live piece of native code with native accessibility semantics, whereas <canvas> is at the mercy of the script. I've not made <embed> non-conforming, since the arguments put forward for doing so are not compelling.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.