Canvas API：常见用途与隐私情境
了解浏览器 Canvas 如何用于图形、动画、游戏和媒体，以及无障碍替代内容与明确的安全边界。
Canvas API 允许网页使用 JavaScript 在 HTML canvas 中绘制图形。它是浏览器中常见的工具，可用于图表、插图、动画、游戏图形和媒体体验。思考 Canvas API 的隐私问题，应从页面用途开始：用户应该看到什么或完成什么、创建该结果需要哪些信息，以及无法使用视觉层时还应提供什么。
Canvas 是一种渲染表面，本身并不是完整界面。位图可以显示图表或游戏场景，但不会自动向屏幕阅读器说明每个绘制对象，也不会让每个交互区域都能通过键盘操作。涉及不同来源的内容时，Canvas 也受浏览器安全边界约束。因此，负责任的使用应结合明确的视觉用途、等效的无障碍信息、合适的备用内容，并遵守页面的来源限制。
如需了解追踪技术及其隐私影响，请阅读 Canvas 指纹识别文章。Canvas API 的常规使用仍需要明确的用户可见结果、等效的无障碍信息，以及对浏览器渲染内容时所处情境的关注。如需了解浏览器、网站、账户和网络等层面的更广泛关系，请参阅跨层面浏览器隐私指南。
了解 Canvas 的用途
HTML canvas 提供一种位图，脚本可以在页面运行时更新。WHATWG HTML 标准将其描述为一种依分辨率而变化的绘图表面，可动态渲染图表、游戏图形、艺术作品或其他视觉图像。MDN 同样将 Canvas API 描述为使用 JavaScript 和 canvas 元素绘制图形的方式，重点是二维图形。这些说明提供了实用起点：Canvas 用于为页面创建可见内容和交互。
图表是一个直接的例子。页面可以绘制条形、线条、标签或类似地图的视图，帮助用户理解一组信息。重要的问题不只是图画是否显示出来，还包括用户能否理解数值、区分相关类别，以及在位图不合适时能否通过其他形式获得相同结论。视觉结果应服务于任务，而不应成为唯一承载其含义的地方。
动画也是常见用途。页面可以随时间更新场景，以传达变化、展示动作或让交互显得灵敏。运动可以帮助说明过渡，但也可能让人分心或感到不适。负责任的体验应让用户暂停或减少非必要动画，并避免让重要说明只能通过观看动画来理解。停止动画后，界面仍应易于理解。
游戏和交互式插图会使用 Canvas，在用户操作时重绘场景。视觉表面可能包括游戏区域、移动物体或变化中的得分。该表面周围仍需有易懂的控件和状态信息。用户应知道如何开始、暂停、继续，以及如何理解结果。如果键盘交互很重要，页面就需要在可见的交互区域与可聚焦控件之间建立有意义的对应关系，而不能假设像素本身就足以提供访问途径。
Canvas 也可以用于照片或实时视频体验。页面可能显示视频帧、应用可见效果，或在媒体上叠加图形。用户应清楚该功能的用途，尤其是在媒体会被采集、转换或保存时。说明页面何时使用摄像头输入、何时正在处理，以及结果是否会被保存或发送到别处。不要让用户仅凭画面在动就自行猜测这些情况。
每种情况下，都应先考虑输出结果和用户期望的操作。询问视觉内容是否需要持续变化、用户是否要选择或操作其中部分内容，以及静态图像或语义化 HTML 是否更简单。绘图或重复更新适合任务时，Canvas 很有用。对于能够用文字、表格或普通页面元素清楚表达的内容，Canvas 并非自动就是正确选择。
从用途出发作决定，也更容易解释功能、测试替代方案，并决定交互结束后用户提供的输入是否仍需保留。
让视觉结果无障碍
Canvas 内容本质上是位图。浏览器可以显示像素，但图画不会自动向辅助技术呈现其中各个对象的含义。完全由像素构成的图表看起来可能很清楚，却无法向屏幕阅读器提供可用数值。绘制在位图上的文字也可能难以放大、选择、翻译或重新设置样式。应把等效表达作为功能的一部分来设计，而不是等视觉内容完成后再补救。
对于图表，应在页面中提供底层数值或简洁的文字摘要。数据表可以提供精确数值，简短说明则可以表达主要趋势或结论。这些替代内容应对应图画中呈现的相同信息，并在图画更新时保持同步。如果用户可以筛选图表，文字或表格也应反映所选视图，而不是描述其他状态。
对于地图或示意图，应说明重要关系，而不能只依赖视觉位置。简短描述可以解释用户应注意的路线、分组或变化；列表或结构化细节则可以呈现单个项目。让这些替代内容与选择和缩放控件保持同步。用户不应只能从装饰性标签或其他位置没有说明的颜色差异中，重新推断图形的用途。
对于游戏或交互场景，应明确用户需要访问的操作和结果。HTML 标准要求，在 Canvas 可交互时，画布中的交互区域与可聚焦区域之间建立一一对应关系。实际设计中，可见目标应配有易懂的控件和反馈。键盘用户需要能够执行相同重要操作的路径，并且焦点应清晰可见。得分、警告或完成结果不应只通过颜色或短暂的视觉变化呈现。
适用时应使用语义化 HTML 呈现标签、说明、按钮和状态消息。Canvas 可以提供自定义视觉层，普通页面元素则负责结构和无障碍名称。这种分工也有助于应对图画加载失败、脚本不可用，或用户使用无法解释位图的工具等情况。无障碍页面不要求所有人都以相同方式感知同一视觉表面。
考虑对比度、文字大小、是否过度依赖颜色、运动和缩放。图表系列不能只用颜色区分，重要标签应在用户实际使用的大小下保持清晰。让用户暂停动画，并在画布调整大小时保留必要控件。对于实时体验，应以不要求用户追踪持续变化场景的方式呈现状态和操作。这些都是围绕绘图的产品决定，不是 Canvas 自动提供的能力。
使用与受众相关的交互方式和辅助技术进行测试。确认非视觉描述符合当前图形，键盘操作容易发现，焦点顺序合理，并在需要时播报变化。静态无障碍检查可能发现不了仅在筛选、缩放、暂停或完成任务后才出现的问题。图画或控件发生重要变化后，应重复检查。
提供有用的备用内容
当 Canvas 的视觉呈现不可用时，备用内容是页面提供的替代内容。HTML 标准规定了元素无法以位图渲染时 Canvas 如何呈现其备用内容。这些内容本身应有用：可以说明视觉内容的用途、提供必要数据，或链接到等效体验。空白区域或泛泛的消息无法保留用户要完成的任务。
让备用信息与实时图画保持一致。如果图表反映了更新的数据，替代文本、表格或摘要就不应停留在旧状态。动画暂停后，页面仍应传达相关状态。游戏场景在用户操作后发生变化时，其无障碍控件和状态信息应描述当前结果。应把替代内容视为该功能的另一种呈现方式，并与 Canvas 本身采用相同的维护责任和更新路径。
备用内容与无障碍相关，但并不相同。仅在 Canvas 不受支持时出现的内容，在 Canvas 正常渲染时可能无法被屏幕阅读器访问。反过来，Canvas 的无障碍名称也不一定能描述其中详细的图表或交互场景。两种情况都应提供适当替代：有意义的备用行为，以及无法按当前方式使用位图的用户可获得的等效体验。
应考虑多种故障情况。页面可能在绘图脚本未加载时打开、无法使用渲染上下文、媒体源缺失，或必要资源被阻止。用户仍应能理解功能用途和接下来可以执行的操作。如果无法提供等效交互体验，就说明这一限制，不要把无法工作的表面呈现为完整功能。
低带宽或受限设备、打印视图，以及图形并非最实用表达方式的工作流，也适合采用备用内容。文字摘要可以快速传达重点；可下载表格可以支持后续工作；对于非交互插图，静态图像可能已经足够。应根据用户任务选择替代方式，而不是认为一种格式适用于所有情况。
当视觉内容带有可选行为时，让用户选择清晰可见。用户可能更喜欢静态视图、减少动画、更简单的表达或暂停控件。记住偏好有助于维持连续性，但要说明偏好适用的范围，并允许日后更改。若范围更窄的选择已能满足当前需要，就不要从一次操作推断出宽泛偏好。
遵守浏览器安全边界
Canvas 遵循 Web 平台的来源模型。页面绘制某些跨来源内容时，如果没有获得该资源要求的许可，Canvas 位图就不再被视为 origin-clean。此时，HTML 标准会限制对该位图的访问及其序列化。该边界有助于防止页面把 Canvas 当成不受限制地检查其他来源内容的途径。
这项限制不是需要绕开的偶然渲染故障，而是不同来源内容的安全模型的一部分。如果功能需要来自其他来源的图像或媒体，应采用受支持的共享安排，并由资源所有者明确许可预期访问。否则，应将体验限制在浏览器允许的操作内，并在此限制影响用户任务时作出说明。
围绕资源来源及其许可预期来设计工作流。页面可能可以显示媒体，却不允许把其像素当作本地可读取或可导出的数据。这是不同的能力。说明页面会如何处理资源，取得平台要求的许可，并避免承诺页面中显示的所有媒体也都能被转换或保存。
处理照片和视频时，说明用户可见的各阶段：选择或提供媒体、预览、应用效果，以及保存或分享结果。如果体验使用实时输入，应提供清晰的开始和停止途径，并说明输入何时处于启用状态。处理过程应符合用户请求的用途；除非解释过的任务本身需要保留或传送结果，否则不要这样做。
让用户容易分辨某项操作影响的是原件还是单独生成的结果。预览效果不应悄悄替换用户提供的文件；保存时应让目标位置和格式易于理解。如果任务可以取消，应提供清晰途径，让用户能在结果保存或分享之前停止。这样，用户无需了解渲染实现，也能对媒体作出知情选择。
资源被阻止或无法按适用的来源规则使用时，应清楚地失败。提供尊重资源所有者政策的替代方式，例如在适合任务时请用户选择本地文件，或提供不可交互的预览。不要暗示可以通过页面设计绕开浏览器限制。应把安全边界视为产品设计的约束，而不是需要击败的障碍。
负责任地设计和维护 Canvas 功能
从一段简短的用户可见结果描述开始规划功能。说明 Canvas 为何适用、任务需要哪些数据和媒体输入、结果是否会随时间变化，以及有哪些非 Canvas 表达方式。这样能让设计师、开发人员和用户理解功能范围，也能使隐私讨论与真实任务相关，而不是停留在对某项技术的模糊说法上。
优先选择满足用途的最简单呈现方式。相较于自定义位图，表格或语义化 HTML 图表可能更容易检查和调整。游戏、动画或交互式可视化则可能适合动态绘图。决策应考虑交互、响应性、无障碍和维护，而不只是视觉风格或实现便利。
明确输入和保留选择。告知用户功能何时需要所选图像、摄像头或视频输入，或已保存偏好。区分显示用户所请求结果所需的处理，与可选存储或共享。让用户控制媒体使用的开始和结束；在信息离开浏览器或之后仍可访问之前，应作清楚说明。
让视觉呈现和替代呈现中的界面保持一致。标签、控件、状态和备用内容应使用一致名称，并描述相同状态。视觉内容更新时，其文字等效内容和交互反馈也应更新。用户暂停动画或切换视图时，应通过不依赖像素的方式传达状态。
功能用途、媒体来源、用户控件或浏览器支持发生变化后，应重新检查功能。测试常规成功路径、资源受阻路径及相关无障碍路径。确认备用内容仍然有用、来源限制得到遵守，并且用户能了解媒体或结果是启用中、本地的、已保存的还是已共享的。这些检查有助于负责任地实现功能，但不能证明所有潜在隐私问题都已消除。
Canvas 是创建浏览器图形的灵活方式，但好的实现不只是能够显示的位图。应让绘图服务于明确的用户用途，为其含义提供等效访问，保留有用的备用内容，遵守 origin-clean 边界，并说明用户输入和结果会发生什么。这样能提供可用功能，同时不夸大 API 或其隐私属性能够保证什么。
