“Works in all browsers” is rarely a useful acceptance statement for a project film. Agree a defined set of devices, browsers and viewing tasks that reflects the audience. The result should show what was actually tested and what remains outside the evidence.
The MDN canPlayType reference describes a browser's indication of likely media support, including uncertainty. Such a capability signal can help implementation, but it does not replace playing the actual content through the chosen page and host.
Choose the coverage deliberately
Ask the website owner what evidence informs the proposed test environments. Existing audience information, organisational device requirements and the purpose of the page can guide the selection. Avoid adding a long list of technology names solely to make the brief look comprehensive.
Record versions and relevant conditions. A browser name without its device context or version can conceal meaningful differences. If testing uses emulation rather than a physical device, label that method so the release owner understands the evidence being offered.
Include a route for untested or unsupported environments. The page may provide a transcript, a clear message or another approved viewing option. That fallback should be tested too; listing a browser as unsupported does not make an unusable blank area a satisfactory audience experience.
Define tasks within each environment
Start with opening the page and playing the film, then add the features actually commissioned: seeking, caption selection, fullscreen or a described version. A successful first frame is not evidence that every important control works.
Use representative content passages rather than an unrelated sample clip. The project film may include captions, diagrams or language options absent from a vendor's demonstration. The test matrix should connect each result to the approved asset and deployed player configuration.
Report failures by task. One environment may play correctly but fail to expose a caption option. Another may have a layout issue at a particular width. Those findings call for different responses and should not be compressed into a single unexplained pass or fail.
A hypothetical broad compatibility claim
Imagine a builder receives an assurance that a new embed supports modern browsers. During release review, a mobile browser plays the film but cannot select the supplied text track through the configured menu. The assurance was based on the video format, not on the complete player.
The buyer asks for a task-based matrix and a correction or supported alternative for the affected route. The final statement names the tested environments and features. It is more limited than “all browsers”, but far more useful to the person deciding whether to launch.
Keep the matrix maintainable
Agree what changes require retesting: a new player version, a different host, an important browser update or a revised feature set may matter. A routine film replacement may need a smaller content-specific check if the implementation is unchanged, subject to the responsible team's assessment.
Ask Live Images about suitable media and companion files for the intended audience. Confirm production scope, then have the website supplier provide the interoperability evidence and the responsible accessibility reviewer cover its separate requirements.
Prepared with AI assistance for Live Images. Planning guidance is general; suitability and production scope must be agreed for your project.