Browser Video Players Review

Browsers each provide built-in video players for the <video> element. Nearly four years ago Scott Vinkle wrote How accessible is the HTML video player?, where he compared these to one video player product. I decided it was time to test for myself. I structured my test and reporting a bit differently and I am not comparing to any product, so this is not a true follow-up on Scott’s work.

To manage your expectations, the tests included here are not thorough. They are not performed by daily users of the assistive technologies I employ. I ran the tests; I am not a daily user of any of these. As such, my own lack of skill may have impacted these results more negatively (or positively) than if a capable user ran these tests. I have only spent 27 hours (so far) testing and documenting these, so it is sloppy.

The Test Page

I used the following page (which you can visit directly for your own uncluttered testing):

It uses the video players exposed by browsers when using the HTML <video> element.

My testing kit:

• NVDA 2023.1 / Firefox 117
• JAWS 2023.2306.38 / Chrome 116
• Narrator / Windows 11 22621.1702 / Edge 116
• VoiceOver / macOS 13.4.1 / Safari 16.5.1
• Orca / Ubuntu 22.04.2 LTS / Firefox 115
• TalkBack 13.1 / Android 13 / Chrome 114
• TalkBack 13.1 / Android 13 / Firefox 116
• VoiceOver / iPadOS 16.5 / Safari 16.5
• BlueTooth keyboard paired with iPad and Android
• Platform voice control feature

The Code

The underlying HTML, which I have used for videos on my site for some years now (it is even in my site documentation):

<video preload="metadata" controls="" poster="JAWS-aria-errors_poster.jpg">
  <source src="JAWS-aria-errors.mp4" type="video/mp4">
  <track label="English" kind="subtitles" srclang="en-us" src="JAWS-aria-errors.vtt" default="">
  Sorry, your browser doesn’t support embedded videos, but don’t worry, you can <a href="JAWS-aria-errors.mp4">download it</a>. The <a href="JAWS-aria-errors.vtt">caption file</a> is also available in case your video player can import it.
</video>

I use the preload attribute to tell the browser to grab only the metadata for the file, ideally to save bandwidth but still give a user agent enough context on file size.

The controls attribute is a boolean and ensures the browser makes video controls available to the user (some places turn this off and autoplay the videos, Google web-dot-dev, a clear WCAG violation).

I usually have a poster image that is as compressed as I can manage. I like to grab it from somewhere in the video that will give a sighted user the most context for what is in the video before downloading and playing it.

I use MP4 for my videos and W3C’s WebVTT format for my closed captions (I rarely use open captions, or burned-in captions). You can convert SRT files (common if you filch captions from YouTube) at WebVTT.org.

Speaking of filching files, note that my code has links directly to the video and caption files in case the embed is not supported. Granted, most web users will not see those links, but many RSS clients will show this instead embedding the video. The VTT file can be imported into video players already installed on your system.

Note that the test video is hosted at my site along with the caption file. Using CodePen or a similar code sandbox is tricky since assets (caption files) are often hosted at a sub-domain. The browser will not / should not load captions from a different domain, so this test would fall down if the captions would not even load.

Also note that I did not try multiple audio tracks. I already know support is poor, but I also consider it trivial to offer another video with an audio description (AD) track on the same page.

Testing Results

I go into more support detail on assistive technology than the MDN Browser Compatibility table. However, MDN’s examines specific attributes (some of which I do not do here).

You may disagree with some of my ranking. If so, see the second paragraph of this post.

I have filed no bugs with vendors nor MDN’s browser compat repo as of this posting. This took a lot of time already, so free labor for multibillion dollar surveillance software and hardware companies can wait.

Following each table are headings corresponding to each row, with numbered lists corresponding to the superscript numbers in the row. I felt that linking everything introduced way too much noise to quickly parse the table. Related, those emoji indicators in the lists may go away for the same reason.

I use the following symbols in those lists:

• 👍 means everything is good.
• ‽ means it is an annoyance, but users unlikely to get stuck.
• ❌ means broken and absolutely a barrier to some.

Keyboard

Every browser that supports picture-in-picture did it poorly, with Firefox faring the best on desktop (Windows and Ubuntu).

Unsurprisingly, Chrome and Edge perform the same. Surpisingly, Safari / macOS stumbled with focus and operation.

On mobile, Android is clearly a better experience with a paired keyboard (Chrome or Firefox). iPadOS is not very good with a keyboard in general, though I am not sure if an Apple-made keyboard would imbue the iPad with a sudden desire to have a sensible focus order for the rare times something takes focus.

Windows / Firefox

1. If controls fade while the closed captions menu is open, focus is lost.
2. Does not return focus when closed, but otherwise keyboad operable.

Windows / Chrome

1. If controls fade when focus is on any of them, focus is lost.
2. If in kebab menu while full-screen then press Esc, it exits full-screen and focus is lost.
3. When launching picture-in-picture, focus does not move to the pop-out.
4. When focus is in picture-in-picture, closing it loses focus in system.
5. When focus is in picture-in-picture, activating “Back to tab” sometimes returns focus to the kebab menu.

Windows / Edge

1. If controls fade when focus is on any of them, focus is lost.
2. If in kebab menu while full-screen then press Esc, it exits full-screen and focus is lost.
3. When launching picture-in-picture, focus does not move to the pop-out.
4. When focus is in picture-in-picture, closing it loses focus in system.
5. When focus is in picture-in-picture, activating “Back to tab” sometimes returns focus to the kebab menu.

macOS / Safari

1. Cannot access volume slider with keyboard (full-screen or not).
2. Cannot adjust volume level; can only mute/unmute.
3. » control (handles playback speed, captions) sometimes works, sometimes does not; could not grok why.
4. Controls fade, but focus is retained and they operable.
5. Orange on gray (when on white BG) has 1.2:1 contrast ratio.
6. Scrubber gets no focus style.
7. Volume slider in full screen is a tab stop (but inoperable) and has no focus style.
8. When exiting full screen (Esc), focus goes to the video itself.
9. Space does not play / pause when video or scrubber has focus.
10. When launching picture-in-picture, focus does not move to the pop-out.
11. Focus cannot be placed in the pop-out.

Ubuntu / Firefox

1. Does not return focus when closed, but otherwise keyboad operable.

Android / Firefox

Nice!

Android / Chrome

1. If controls fade when focus is on any of them, focus is lost.
2. If full-screen and press Esc, the browser kebab menu opens and is difficult to dismiss.
3. When launching picture-in-picture, focus does not move to the pop-out.
4. If you manually put focus into it, buttons do nothing when activated.

iPadOS / Safari

1. Controls in embedded player are focusable, but not in a visual (nor logical) order (eg: mute is top-right corner, but last item coming from bottom right corner).
2. Wen entering full-screen mode, all controls are hidden; only Space works to play / pause; no way to bring up other controls without tap.
3. When in full screen and screen tapped to show all controls, only those displayed across top of screen accept focus (with hidden tab-stops between).
4. Controls in full screen that are not at top of window are inoperable.
5. Many controls inoperable until video is playing (such as full screen or mute).
6. Play button does not fire when starting video from stopped (but will advance video 10 seconds), nor does the “skip backward 10 seconds” button. I am guessing this suffers from the third of the two hard problems in computer science.
7. Mostly mooted by focus problems.
8. Blue (#1D84FA) on gray (#878787) has a 1:1 contrast ratio.
9. Focus is not retained or moved to any control.
10. Controls in picture-in-picture pop-out can only be focused when window is tapped.
11. Controls in picture-in-picture pop-out can only be operated if window is tapped.

Screen Readers

These represent common screen reader and browser pairings.

Chrome and Edge struggled with what to do when the controls faded. VoiceOver on iPadOS had problems with focusing and operating controls. There were accessible name challenges with TalkBack paired solely with Chrome and also Safari with VoiceOver on macOS.

Every browser that supports picture-in-picture still did it poorly. Orca fared the best on desktop with mobile browsers being slightly less broken.

JAWS / Chrome

1. If the controls fade while focus is on any control, focus is lost.
2. When launching picture-in-picture, focus does not move to the pop-out.
3. When focus is in picture-in-picture, closing it loses focus in system.
4. When focus is in picture-in-picture, activating “Back to tab” sometimes returns focus to the kebab menu.

NVDA / Firefox

1. If controls fade while the closed captions menu is open, focus is lost.
2. Pop-out button has no accName.
3. Pop-out button inoperable.

Narrator / Edge

1. If controls fade while focus on any control, focus is lost.
2. When launching picture-in-picture, focus does not move to the pop-out.
3. When focus is in picture-in-picture, closing it loses focus in system.
4. When focus is in picture-in-picture, activating “Back to tab” sometimes returns focus to the kebab menu.

VoiceOver / macOS / Safari

1. The video scrubber only announces as “slider”, both views.
2. The volume slider only announces as “slider”, full-screen view.
3. When launching picture-in-picture, focus does not move to the pop-out.
4. No controls in the pop-out can get focus nor announce when interacted via mouse.

Orca / Firefox

1. Pop-out button has no accName.

TalkBack / Chrome

1. Operable by double-tapping and then using explore by touch or swiping before controls fade.
2. The replay button in the picture-in-picture pop-out has no accName.
3. When launching picture-in-picture, focus does not move to the pop-out.

TalkBack / Firefox

1. Scrubber announces seconds as tens of thousands and without units.

VoiceOver / iPadOS / Safari

1. Controls must be found using explore by touch, with swiping only moving among sets are are visually on the same row.
2. Inconsistent; I could focus on “play”, and video would skip back 10 seconds; I activate “skip forward ten seconds” and video would play, “skip back 10 seconds” would do nothing.
3. When launching picture-in-picture, focus does not move to the pop-out.
4. Operable by double-tapping and then using explore by touch or swiping before controls fade.

Voice Control, Forced Colors, Speed

I broke these these two features into their own table since they did not belong in the others.

Windows browsers handle Windows High Contrast Mode / Contrast Themes / forced colors just fine. If these terms are new to you, read my post WHCM and System Colors.

Chrome on Android and Safari on iPadOS both struggled with voice control. This was another case of Firefox outperforming Chrome on Android. It also outperformed iPadOS as well (where Safari is the only browser).

20 December 2023: I amended this table to include the ability to control video playback speed. Things have improved since I covered this in my 2017 post Playback Speed in Default Video Players.

Windows / Firefox

1. Can operate as long as controls are visible, otherwise have to fall back to grids.
2. Picture-in-picture controls disappear quickly.

Windows / Chrome

1. Can operate as long as controls are visible, otherwise have to fall back to grids.
2. Picture-in-picture controls disappear quickly, but when visible required me to specify whether I want the picture-in-picture control or the one in the original video.

Windows / Edge

1. Can operate as long as controls are visible, otherwise have to fall back to grids.
2. Picture-in-picture controls disappear quickly, but when visible required me to specify whether I want the picture-in-picture control or the one in the original video.

Android / Firefox

1. Controls can be operated when not visible.
2. I am unable to find a method to do it and the documentation does not mention it.

Android / Chrome

1. Voice control only works when controls are visible (so pausing is tricky).

iPadOS / Safari

1. Mostly mooted by focus problems identified in keyboard use, making it difficult at best.

Media Queries: 20 December 2023

I wrote Media Queries in HTML Video, which is full of new examples to detail new support. This table captures the outcomes.

Unlike the prior examples, this table applies to Firefox 120, Chrome 120, and Edge 120 since that is when the feature was added. It also only represents three media queries I felt were a potential fit for video.

Audio Description: 20 December 2023

Today I posted AD Support in HTML Video, which covers approaches for providing audio description without having to maintain two separate videos. This table captures the outcomes.

Specification Issue

• ^* Unlike other features, I think this one may be a function of an unfinished WebVTT specification and general WHATWG disconnection from practical accessibility affordances. I find it hard to blame browsers here.

Wrap-up

The HTML <video> element may not be ideal for your audience. I get away with it on this site perhaps because:

• The videos are all downloadable, so a user can play in whatever local player they want;
• My audience may be more technical and willing to work around bugs;
• My audience may have have more Firefox users and fewer VoiceOver users than yours (Firefox has come a long way in 4 years);
• I have no interest in third-party video players with their need for maintainance, their offloading processing to users, and their niche features I will never touch;
• Nobody has complained (yet).

What you use on your site is your decision. As a user, I would prefer if you used <video>. That does not autoplay. And has controls. And captions. And uses a video that has been run through Handbrake.

Look at me not calling out any specific multinational corporate beheamoth that gets this wrong all the time while also pushing hundreds of kilobytes of custom video player down the pipe that my browser must then compile so it can provide me with a crappier and less private experience.

Update: 7 December 2023, Responsive Media

Scott Jehl discusses new support for responsive media using the <video> element in his post How to Use Responsive HTML Video (…and Audio!). An example from his post:

<video>
    <source media="(min-width: 2000px)" src="large.webm" type="video/webm">
    <source media="(min-width: 2000px)" src="large.mp4" type="video/mp4">
    <source media="(min-width: 1000px)" src="medium.webm" type="video/webm">
    <source media="(min-width: 1000px)" src="medium.mp4" type="video/mp4">
    <source src="small.webm" type="video/webm">
    <source src="small.mp4" type="video/mp4">
</video>

Essentially you can deliver different videos based on a media query and supported file type. Same goes for <audio>.

Support landed in Firefox 120 on 21 November 2023 and then in Chrome 120 a few days later. Safari already had support.

In my opinion, this is another feature in favor of native HTML video over many third-party privacy-invading video platforms.

Update: 9 December 2023, Examples of Responsive Media

I wrote a new post, Media Queries in HTML Video, that demonstrates how some media queries can allow you to deliver videos that could be more accessible for your audience.

I even made a brand new and terrible video to demonstrate it.

Update: 20 December 2023, MQs, AD, Speed

Three significant updates:

• I now report on the ability to change playback speed,
• A whole new section on media queries, and
• Another new section on audio description.