Chrome 157 的 HTML-in-Canvas：Canvas 里终于有了“真正的 DOM”，但可访问性的账单才刚刚开始

Chrome 157 在 2026 年 11 月稳定发布了 HTML-in-Canvas。开发者可以用 drawable 属性标记元素，然后通过 drawElementImage() 或 updateElementGeometry()，把真实的、可交互的 DOM 子树——表单、可选中文本、屏幕阅读器支持、页内查找、自动填充——画进 2D、WebGL 和 WebGPU 的 Canvas 里。Three.js 通过 HTMLTexture 提供了实验性支持，Babylon.js、PlayCanvas 和 PixiJS 8.19.0 已经有了自己的接入点。

这件事的分量比“Canvas 可以画 HTML 了”要重得多。在 HTML-in-Canvas 之前，任何被画进 Canvas 的内容都失去了 DOM 的可访问性和交互行为：一个用 Canvas 渲染的表单，屏幕阅读器读不到；一个用 Canvas 渲染的文本，页内查找找不到；一个用 Canvas 渲染的按钮，键盘无法聚焦。Canvas 的渲染性能优势，是以把内容从可访问性树里摘出去为代价的。HTML-in-Canvas 把这条代价收窄了：画进 Canvas 的不再是一张像素快照，而是一个仍然活着的、保留语义的 DOM 子树。

但这不是一个“可访问性问题解决了”的结论。一个新的能力会带来新的工程问题。焦点管理：当 DOM 元素被画进 Canvas，Tab 顺序应该怎么走？浏览器需要知道这些“画出来的元素”在可访问性树里的位置，而 Canvas 本身是一个单一的渲染表面，焦点在 Canvas 内部和外部之间的切换需要一个明确的模型。命中测试：点击一个“画出来的按钮”和点击一个普通 DOM 按钮，事件路径不一样；开发者需要确保 drawElementImage() 画出的几何形状和实际的事件命中区域对齐，否则用户看到的是按钮，点到的是空气。性能：把真实 DOM 画进 Canvas 不是零成本的，每一个被绘制的子树都需要在渲染管线和可访问性树之间保持同步；如果每一帧都更新，开销可能超过直接使用 DOM。

一个务实的判断是：HTML-in-Canvas 关闭的是一个长期存在的可访问性缺口，但它打开的是一个新的集成层。如果你的产品重度依赖 Canvas 渲染（数据可视化、地图、游戏 UI、富媒体编辑器），这个特性值得认真评估，因为它让“性能优先的渲染”不再必须以“可访问性归零”为代价。但如果你的场景用普通 DOM 就能满足，引入 Canvas 渲染只会增加复杂度。先确认你的瓶颈确实是 DOM 的渲染开销，再决定要不要把内容搬进 Canvas，并且为焦点、命中和屏幕阅读器行为建立可测试的验收标准。