possible improvement to our embed code

[deborah]

please forgive me if somebody else is already working on this. I was looking at accessible embedded flash players, and I came across "making video accessible", which talks about, among other things, using SWFObject JavaScript to detect whether or not Flash and/or JavaScript are enabled. If flash is not enabled, the embed is replaced with a link to the object.

I think that would be a huge accessibility win, and it would be one of those accessibility = universal design issues, because I've also seen people who don't have accessibility needs but browse with No Script or an equivalent complain about the way our embeds work.

What other people think? I haven't looked at the embed code at all, and I admit I am incredibly ignorant about the way multimedia works in general.

Comments

[lightgetsin]

Actually, I have never made a DW video embed work at all. It's weird -- the little flash thing with all the terrible buttons never expands when I hit the graphic.

LJ's works for me, though, which is what's really odd.

[deborah]

weird. Do you know if there's a bug filed about this? Because that's pretty strange.

[lightgetsin]

Hrm, I've been meaning to look for a while now. Will check today.

[lightgetsin]

Hmm. If it's in the bug tracker, it's not under an obvious name.

[polemista]

I know I'm being petty, but EVERYONE has "accessibility needs".
You know, we all want to be able to enter a supermarket, or use a public bathroom. It's just that for non-disabled people it's usually not a problem because their access needs are taken for granted. ;)

Re: The embed thing. I'm not sure I comprehend. What happens if you embed a YouTube video with that feature?

[deborah]

right now, if the user has JavaScript or flash disabled by default, instead of being able to access the YouTube video, the user just has a couple of inches of blank space on the screen. Of course it's not just people with disabilities to browse without JavaScript or flash, but certainly there are plenty who do.

The fix suggested in the link I gave would, in the absence of enabled JavaScript and flash, provide a standard HTML link directly to YouTube.

Actually, from an accessibility standpoint it would be better to always provide a link directly to YouTube as a standard HTML link. (That is, provide a link directly to whatever video embed service is being linked.) A lot of times embeds don't work very well with adaptive technology (as lightgetsin points out above), and many users might have more functionality at the video hosting site and then in an embed. Come to think of it, I do.

[ex_peasant441]

I imagine the greatest accessibility gains would be if we concentrated on finding a way to encourage users to add a proper description and/or captions for their embedded media. Perhaps with a prompt as part of filling in the embed form. That is done for icons, but not for embedded images or other media.

[deborah]

I imagine that would be a good idea, especially if we linked to a document on how to provide captions. But the reason I made this suggestion is because it would be a concrete which would not require user input, which could just happened programmatically every time. Asking users to add a proper description and captions would be a great thing, but providing HTML links that are always present and don't require embeds to work would be cheap and always work.

[jeshyr]

Good points on both sides. Also, most people when linking videos are linking other people's videos and hence really can't add captions - most YouTube videos don't allow you to add captions yourself. Descriptions of the video's content, sort of like alt text for the video, are a great idea though. See my comment in the next thread!

Dreamwidth Video Tags

[jeshyr]

In terms of accessibility/universal design I'd love to see embedded video on Dreamwidth have two things:

1. Always show a link directly to the video, as well as the embed itself. Preferably let the video's name be the embed link, rather than something generic like "video here".

2. Encourage video descriptions to be added by the user, which helps in terms of usability/accessibility in a heap of ways.

I don't think that things like YouTube/Vimeo embedded videos can actually use the technology that deborah linked to, unfortunately, because we don't have the video player locally. Unless (or until...) DW starts to actually hosts videos locally and uses our own SWF player we can't do that, but if we had a video/embed "tag" then we could at least improve on what's currently available.

Eg YouTube provided "embed codes" which specify the whole video and player etc but aren't currently very accessible.

If we have the URL though, we can generate that set of embed tags ourself. Or, this is the good bit, we can generate something equivalent but with better accessibility. I've seen discussions of accessible controls for the YouTube embedded video player which could be used, for example.

This method would be most flexible as we could update it and automatically have older embedded videos use the new generated stuff because what's stored in the journal would be the Dreamwidth embed tag, not the YouTube/Vimeo/etc. embed tags.

Here's my top-of-the-head suggestion for a tag format:

<video name="John Lennon Google Doodle" url="http://www.youtube.com/watch?v=TYHCeUfoAnw" description="John Lennon song 'Imagine' with animated pencil drawn sketches. Has captions.">

I suspect the various video site's APIs mean that we can pull the name from those sites (YouTube, vimeo, etc.) if we have the URL, so that part may be redundant. Also if it's possible that we can query the API to tell us whether the video has captions available and somehow include this information, eg by putting "(captioned)" after the video's name, that would be really good.

The YouTube Lyte WordPress plugin may also have relevant goodness in it, it has optional links to Easy YouTube as well as YouTube in the embeds it generates.

Note that this entire idea was spawned from your post and hence has had about 15 minutes total of research, it may be entirely un-implement-able. If people like the idea and want to take it further, I suggest we grab fu and/or exor674 in here to discuss the issues of whether this is implementable and/or desirable from the point of view of scaling and all that.

r

PS
Thanks for bringing this up. I had been exploring the YouTube Lyte stuff with respect to my WordPress blogs but had somehow not thought to apply it to Dreamwidth. Silly me!

Re: Dreamwidth Video Tags

[exor674]

Well, one problem I come up with on a quick skim, we'd have to use something besides <video ...>, as that's an actual tag, and if we ever wanted to add support for html5 video, yeah... *g*