I have an audioless video implemented using HTML5's <video> tag. I'm trying to find out if auto-playing the video and automatically looping it (assuming I add a button to remove loop as well) would cause accessibility issues? I know there are rules regarding audio as well as video with audio that prevent you from doing that, so I'm also wondering if this video is practically considered a GIF.
The video can be found here for reference:
http://www.med.uottawa.ca/bmi/eng/lee.html
This is technically an accessibility violation if it plays for more than 5 seconds. It affects users with disabilities such as attention deficit disorder. You need to provide a button to stop the video from playing immediately, not only a button that disables the automatic loop.
Related
I am developing an application where I need to display some animation in the canvas along with the video as a separate element, for the same I need to maintain the synchronisation between two DOM elements very precisely.
I was thinking of playing the animation as video tag plays the video. Is there any way I could see how the html5 video tag is implemented?
Theoretically, each browser can have their own implementation of the video tag. Besides of that, they will try their best to follow some rules specified by w3.org
This is the video tag draft:
https://www.w3.org/TR/2011/WD-html5-20110113/video.html#video
If yout want to sync something with a video you will want to use some video tag events:
https://www.w3.org/2010/05/video/mediaevents.html
A timeupdate event listener can be set on the video which will allow you to synchronize other elements on the page with the video as it plays. Video elements have many other events in addition to timeupdate, such as play, pause, and seeking.
The implementation of video elements will differ depending on the browser and may not be completely public, such as how they work with DRM.
I have autoplay in the video tag, but it still requires mousing over it. From what I read it's because it requires user interaction to play the video, so users won't be annoyed by videos playing without their consent. Is there a way to get around that or fake the event well enough to fool the browser?
No. And if there was a way to fool it, Apple would just close that loophole on the next release.
I am going for a most simplistic playback of background audio. I don't even want to capture media controls or anything. I just want to start the app and play audio until I explicitly close it. That is, it should play audio while hidden.
I used this article and this question as reference and I followed their guidance:
<MediaElement Name="someMedia"
AudioCategory="BackgroundCapableMedia"
IsLooping="True"
Source="Assets/some.mp3"
AutoPlay="true"/>
Also, I added Background Tasks to my Package.appxmanifest's Declarations, checked Audio and set the start page. What am I missing?
You should also enable SystemMediaTransportControls and handle two events on it and on your MediaElement to keep them in sync.
Check this article:
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/jj841209.aspx
On iOS, and I think Safari, we have Apples HTTP Live streaming, which can take a playlist of video files in a certain format, buffer them one by one, and play them seamlessly back to back.
Is there any way to achieve this in other browsers? I can of course detect the video finishing, and then start buffering and playing the next one, but I want to remove the buffering by downloading subsequent videos as each earlier video finishes. I do not want to hack this by stacking up video elements and switching between them. There are various serious consequences to this method.
Perhaps if there is a way to use javascript to download the files into in-memory buffers and somehow point the video element to play from these buffers?
I've seen swapping in video elements for each segment tried, and it's never smooth.
There is an HTML spec in the works that defines exactly the process you're describing, concatenating media segments into a buffer that can be fed into a media element.
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
This isn't available in browsers today but is working its way into Chrome/Safari. Even when it is, it will take a good amount of work to implement this process.
Your best bet if you need it now would be to use a Flash player that can handle HLS, like OSMF, JWplayer, and soon Video.js.
In html5, you can preload videos, preload the meta information, or not preload at all. The only problem, of course, will be with Internet Explorer which will download everything or nothing at all (and not even show the controls).
This is all controllable with javascript, too. If you want to play them back-to-back automatically, though, this would need to be done with javascript or some third-party tool. Reading where the file is playing is accessible through the API.
Update: This question is no longer valid. See comment below.
YouTube embedding is done using iframes nowadays.
HTML5 introduces the seamless attribute, that not only should affect presentation, but make the integration with the host page tighter. (It should not be announced to screen readers as a separate document.)
HTML5 introduces the sandbox attribute, that restricts the iframe and thus improves security.
In a world where browser support for these 2 attributes is complete, will they benefit or in any way adversely affect the page, when embedding YouTube videos? (Yes, the last half of the question is primarily about seamless.)
I am thinking about recommending my students to always use these 2 attributes for YouTube videos and benefit automatically as browser support becomes available.
I'll focus on just discussing the sandbox attribute.
To play YouTube videos in a sandbox you need to do the following:
Add sandbox="allow-scripts allow-same-origin"
Add ?html5=1 to the video URL
A problem with #1 is that Flash will not be loaded; whether Flash is required depends on a few things, such as the end-user's browser, their YouTube settings or when a video is simply not available as an HTML5 video (this is worsened by #2).
Another (more serious) problem with #1 is that the combination of allow-scripts and allow-same-origin effectively removes any security benefit you would have otherwise enjoyed.
Conclusion
Forget about using the sandbox attribute for YouTube video embedding.
Further reading
HTML5 Sandbox and some notes
Error playing embedded youtube video in a sandboxed iframe
No, fullscreen does not seem to work with both attributes enabled, if you are in the HTML5 beta check an example here:
http://bcmoney-mobiletv.com/view/2133/monty-python-tax-sketch/
However, when I leave the HTML5 beta program it plays back in the standard YouTube Flash player, which ignores those iFrame attributes completely.
So, it really depends what your goals are. If you want added security and an experience that feels more like an in-page web video that is controlled by your page, go ahead and use those attributes, however, if you want to give the user a full range of controls and options, leave off sandbox and/or seamless.