The VideoPress Player, Rebuilt From Scratch  🔗 **Source:** [The VideoPress Player, Rebuilt From Scratch](https://jetpack.com/resources/the-videopress-player-rebuilt-from-scratch/) > [!note]+ Document Notes > --- > tags: [videopress, jetpack, media-player, web-accessibility, frontend-rewrite, wordpress-ecosystem] > author: Devin Walker (byline as captured) — Automattic / Jetpack > source: Jetpack blog (jetpack.com), product/engineering announcement post > reference: Readwise Reader document 01m2p4f861knb9txg0d05hf8f8 — "The VideoPress player, rebuilt from scratch" (~439 words of prose; canonical permalink not present in the capture, asset URLs resolve to jetpack.com/wp-content/uploads/2026/09/) > date created: 2026-09-19 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > ## 🏷️ Title > **The VideoPress player, rebuilt from scratch** — a short Jetpack announcement post describing a ground-up rewrite of the VideoPress front-end video player, shipped as the default for all users with no plugin update required. > Working subtitle for internal use: *A mobile touch-target bug became a full front-end rewrite, and the rewrite shipped keyboard support, bottom-sheet menus, an end screen, and a new dominant-color algorithm.* > ## 🧭 Table of Contents > 1. 🏷️ Title > 2. 🧭 Table of Contents > 3. 🔗 References (in-page) > 4. 📝 Summary > 5. 📖 Main Content (with 🗒️ Notes) > 6. 📚 References (primary sources preferred) > 7. 🗣️ Paraphrase > 8. 📰 Newsletter > 9. ✅ Action Items > 10. 🧪 Hypotheses > 11. 📊 Methodology > 12. ❓ Questions > 13. 🔮 Future Research > 14. 💡 Implications > 15. 🧠 Learning Styles Assessment > 16. 📊 Accessibility Assessment > 17. 🌍 DEIB Assessment > 18. ✅ Logical Validity > 19. 🛡️ DARVO Analysis > 20. 🎯 Conclusion > 21. 🔄 Refactor Appendix > ## 🔗 References (in-page) > I checked the fetched body for links rather than assuming. The post body itself contains **exactly one outbound link inside the article prose**, plus site-chrome links appended by the capture. Full inventory: > **In the article body:** > - `https://video.wordpress.com/embed/SmJWllH8?cover=1&autoPlay=0&controls=1&loop=1&muted=1&persistVolume=0&playsinline=0&preloadContent=metadata&useAverageColor=1&hd=0` — the demo video, rendered in Reader as "Some content could not be imported from the original document. View content ↗". This is the post's one piece of primary evidence and it did not survive capture. Note the query string: `useAverageColor=1`, which is interesting given that the post's headline improvement is *replacing* the average-color algorithm. > **Images embedded in the body (four, all on jetpack.com):** > - `/wp-content/uploads/2026/09/videopress-2.png` (hero, appears twice — once at `?w=2048&allow_lossy=1`, once unsized) > - `/wp-content/uploads/2026/09/improved-player.png?allow_lossy=1` > - `/wp-content/uploads/2026/09/customize-seek-bar.png?allow_lossy=1` > **Site chrome captured after the article ends (not the author's argument):** > - `https://jetpack.com/pricing/` — "Explore plans" CTA > - `https://wordpress.org/support/plugin/jetpack/` — support forum, since comments are closed > - Three related-post links: Jetpack 16.1.3 Critical Security Update; Your Next Post Can Be a Podcast; Performance Plugins Need to Keep Pace With WordPress > **Finding, stated as a finding and not as an unchecked assumption:** the post cites **zero** external technical sources. There is no link to a pull request, no link to the Jetpack monorepo, no changelog entry, no issue number, no `wp-calypso`/`jetpack` GitHub reference, no design doc, and no accessibility conformance statement. For a post whose central claim is "we rewrote most of it from scratch," the absence of a single code reference is a real, load-bearing gap — this is an announcement, not an engineering write-up, and it should be read that way. > ## 📝 Summary > **What happened.** Automattic's Jetpack team rewrote the front-end of the VideoPress player rather than continuing to patch it. The proximate trigger was a concrete mobile defect: the seek bar's touch target overlapped the settings controls, so tapping settings on a phone could scrub the video to a completely different position. The fix — moving the seek bar above the control row — could have been a small CSS/layout change. Instead the team used the defect as a wedge to justify replacing most of the player's front-end code. The shipped result bundles: restructured control layout; refreshed visual design with new animations; redesigned settings and sharing menus that render as bottom-sheet panels on phones and tablets; responsive menu behavior when the player is embedded in a constrained container; double-tap-to-seek gestures; full keyboard navigation of controls and menus; a post-playback end screen offering replay and share; and a replacement for the dynamic seek-bar color algorithm that selects the most vibrant color in the frame instead of the frame average, producing an ambilight effect, with a block-editor override for people who want fixed colors. The new player is already the default for everyone and requires no plugin update. > **Why it matters.** Three reasons, in ascending order of importance. > First, *reach without consent*. VideoPress is embedded across Jetpack and WordPress.com sites. A default-on player swap means the rendering surface changed under every site owner using it, simultaneously, with no version bump to review and no opt-out mentioned. That is a legitimate deployment strategy for a hosted service, and it is also a real change-management event for anyone who has customized, QA'd, or documented the old player. > Second, *accessibility arriving as a side effect*. "Full keyboard support" is presented as a feature added during a redesign. Read plainly, that means the prior player was not fully keyboard operable — a WCAG 2.1.1 (Keyboard) failure in a media player shipped at WordPress scale. The post frames this as an addition rather than a remediation. That framing matters for how the ecosystem talks about accessibility debt. > Third, *the rewrite decision itself*. "We decided to rewrite most of it from scratch" is the single most consequential sentence in the post, and it is asserted without any supporting reasoning: no discussion of the old stack, its test coverage, its maintenance cost, the rewrite's duration, or the regression risk absorbed. For an ecosystem that routinely debates incremental-versus-rewrite, this is a data point with the data omitted. > **Stakeholders.** > - *Site owners and publishers using VideoPress* — get a better mobile player they didn't ask for, on a timeline they didn't set. > - *Mobile viewers* — the clearest beneficiaries; the described touch-target bug was a genuine usability failure. > - *Keyboard and switch-device users* — beneficiaries, though the post gives no conformance detail. > - *Screen reader users* — conspicuously unaddressed. Keyboard operability is necessary but not sufficient. > - *Deaf and hard-of-hearing viewers* — **captions and subtitles are never mentioned anywhere in the post.** In a 2026 post about rebuilding a video player from scratch, that silence is the most significant omission in the document. > - *Theme and plugin developers* — a front-end rewrite can change DOM structure, class names, and CSS specificity; anyone who styled or scripted against the old player markup is exposed, and the post says nothing about it. > - *Jetpack support and WordPress.org forum volunteers* — comments are closed on the post, so all feedback routes to the support forum. > - *The Jetpack/Automattic team* — owns the regression surface of a from-scratch rewrite now live everywhere. > **Risks.** > 1. *Silent regression surface.* A from-scratch rewrite shipped as default-on to all users, with no staged rollout described and no feature flag mentioned, concentrates risk. The only feedback channel offered is a general support forum. > 2. *Breaking custom styling.* No word on DOM or class-name stability. This is the most likely source of "my site looks wrong" reports. > 3. *Accessibility claim without evidence.* "Full keyboard support" is unqualified and untested-in-public. No focus-visible commitment, no focus-trap behavior for the bottom-sheet panels, no ARIA roles, no audit. > 4. *Gesture conflicts.* Double-tap-to-seek is   Recently, we’ve been on a spree to modernize all things VideoPress. The most recent and visible result of this effort is the video player. The previous VideoPress player had some issues with the seek bar’s touch area overlapping and interfering with the settings controls on mobile devices. The seek bar now sits above the control buttons, so opening the settings doesn’t also send you to an entirely different part of the video. While addressing those issues, we took the opportunity to review other parts of the player that looked very outdated. And instead of iterating on the existing frontend code, we decided to rewrite most of it from scratch.  The result is a much more modern look and feel, with updated controls, new animations, and nicer settings and sharing menus — not just nicer but also more usable on mobile screens. On phones and tablets, settings and sharing open in panels that slide up from the bottom, with room to actually tap what you meant to tap. You can also double-tap the video to seek backward or forward. And when the player is embedded in a smaller space, the menus adapt to fit. We’ve also added full keyboard support, so you can navigate the controls and menus without reaching for a mouse. When a video ends, a new end screen gives you the option to replay it or share it with someone else. And as the saying goes, a video is worth a million words, so what better way to illustrate it than with the player itself? Some content could not be imported from the original document. [View content ↗](https://video.wordpress.com/embed/SmJWllH8?cover=1&autoPlay=0&controls=1&loop=1&muted=1&persistVolume=0&playsinline=0&preloadContent=metadata&useAverageColor=1&hd=0) We also took the opportunity to improve a pet peeve of mine: the dynamic color seek bar algorithm. The previous algorithm often resulted in a boring grey color because it used the average color of the video frame. The newer algorithm instead tries to find the most vibrant color in the frame, resulting in more of an ambilight effect. And if you don’t like the ambilight effect, you can still customize the seek bar colors to your heart’s content using the block editor settings.  The redesigned player is already the default for everyone, with no plugin update required. We hope you like it, and if anything feels amiss, any feedback is more than welcome. Crafting Jetpack @Automattic, Creator of @GiveWP, WordPress enthusiast, #WordCamp speaker, mediocre golfer, post-rock obsessed cat lover and aspiring world traveler. #### Explore the benefits of Jetpack Learn how Jetpack can help you protect, speed up, and grow your WordPress site. [Explore plans](https://jetpack.com/pricing/) Comments are closed for this article, but we're still here to help! Visit the support forum and we'll be happy to answer any questions. [View support forum](https://wordpress.org/support/plugin/jetpack/) [](https://jetpack.com/resources/jetpack-16-1-3-critical-security-update/)[Jetpack 16.1.3: Critical Security Update](https://jetpack.com/resources/jetpack-16-1-3-critical-security-update/) [](https://jetpack.com/resources/your-next-post-can-be-a-podcast/)[Your Next Post Can Be a Podcast](https://jetpack.com/resources/your-next-post-can-be-a-podcast/) [](https://jetpack.com/resources/performance-plugins-need-to-keep-pace-with-wordpress/)[Performance Plugins Need to Keep Pace With WordPress](https://jetpack.com/resources/performance-plugins-need-to-keep-pace-with-wordpress/), The VideoPress Player, Rebuilt From Scratch, Devin Walker, 01m2p4f861knb9txg0d05hf8f8.