指针事件与鼠标、触控和触笔的无障碍输入

Pointer Events 为 Web 应用提供了一套通用事件模型，可处理鼠标、触控和触笔输入。这种共享模型有助于组织拖动、绘制和直接操作等交互，但并不意味着所有输入方式都可以互换。可靠的界面会把指针事件作为一种交互方式，同时保留键盘操作、提供实用的命中区域，并在交互被打断时妥善保留或清理状态。

重要的设计问题不是如何判断一个人拥有什么实体设备，而是当前操作能否通过其可用的输入方式舒适地完成。用户可能在同一项任务中切换鼠标、触控、触笔、键盘、语音控制或辅助技术。页面应根据交互及其结果作出响应，而不应试图建立关于用户或设备的画像。

有关应用测试，请参阅浏览器交互验证和设备模拟测试。如果工作流程涉及多个平台，跨平台浏览器配置文件介绍了如何记录预期差异。

共享事件模型，而非设备分类器

Pointer Events 规范以设备无关的方式定义了处理指向输入的事件和接口。在常见的应用代码中，这意味着常见操作可以使用 pointerdown、pointermove、pointerup 和 pointercancel，而不必为每一种支持指针的输入来源维护完全独立的交互逻辑。浏览器会为当前指针事件提供事件属性，包括标识符和概括性的指针类型。这些属性适合将事件关联到正在进行的交互，但不能据此推断某人的身份、能力、设备所有权或意图。

鼠标、触控和触笔具有不同的物理特性。鼠标通常有光标和离散按键；手指接触屏幕的面积较大，也可能触发浏览器导航手势；触笔可提供精细定位，在受支持的情况下还可能具有按键或压力相关属性。页面打开期间，用户也可以连接或断开输入设备。应用应让控件易于理解和操作，而不应假定输入配置始终不变。

事件模型有助于共享行为，而不是抹平有用的差异。如果绘图应用确实需要特定于触笔的行为，绘图区域可以提供该行为；但基本按钮仍应保持按钮的语义。如果可以提供键盘无障碍替代方式，拖动手柄就不应成为调整列表顺序的唯一途径。菜单也不应要求触控用户无法触发的悬停状态。应从任务及其结果出发，再选择容易发现且可恢复的输入交互。

W3C Pointer Events Level 3 推荐标准是事件模型及其行为的规范性来源。MDN Pointer Events 指南则提供了在 Web 应用中使用这些事件的实用概览。浏览器支持情况和具体细节可能变化，因此应检查产品所依赖的具体事件或属性当前是否兼容。熟悉的 API 名称并不保证它在所有浏览器版本或嵌入式 Web 视图中的行为完全相同。

跟踪从按下到完成的交互

pointerdown 是开始交互的合适时机。它表示指针已经接触目标，或以其他方式开始了输入操作。对于拖动，应用可以记录起点、正在移动的项目和当前指针标识符；绘图工具可以开始一笔笔画；自定义控件则可以记录一次待定的激活，并把最终决定留到交互完成时。

与其把每个事件都视为孤立命令，不如维护少量明确的交互状态。状态可以表示某个项目正在拖动、某笔绘画仍在进行，或一次按压仍待确认；同时也应明确如何清除状态。如果用户放弃手势、离开页面，或浏览器接管交互，应用不应让控件一直呈现按下状态，也不应让拖动指示器继续跟随过时坐标。

pointermove 会报告与该指针相关的移动。页面可以据此更新预览、移动选中对象或绘制笔画。移动事件可能频繁到达，平台或浏览器也可能合并若干采样。因此，应用行为应取决于当前交互及其最终结果，而不是假定每一次物理移动都会一对一地触发处理器。适当时，应用可以安排或合并成本较高的渲染，同时让状态始终对应当前活动指针。

对于支持多个指针同时操作的界面，例如双指画布手势，应使用指针标识符来维护状态，而不要假定同一时刻只能有一个活动指针。对于简单控件，明确只支持一个活动交互可能更容易说明和测试。无论采用哪种方式，都要定义第一个指针活动期间第二个指针开始操作时会发生什么。忽略第二个指针、取消当前操作或切换到多指针模式，都应是明确的产品决策，而不是意外副作用。

pointerup 表示一次活动指针操作结束。此时可以提交拖动目标、结束笔画，或判断一次按压是否应激活控件。提交之前应验证目标位置并告知操作结果。如果项目不能放置在某个位置，应将其恢复到明确有效的位置，并说明限制，而不是留在含糊状态。类似点击的操作也不应只因按压开始就触发；用户可能已经移开指针、取消操作，或触发了平台手势。

平台定义了指针事件的顺序细节，其中可能包含面向鼠标内容的兼容事件。不要把同一业务操作同时绑定到多个事件系列，以免重复激活。应为每种交互选择一条清晰的处理路径，并在产品支持的浏览器和输入条件下进行测试。如果应用代码也处理键盘激活，应使用控件正常的语义激活行为，而不是通过无关事件处理器重复实现仅针对指针的操作。

交互不一定以 pointerup 结束，页面还必须把 pointercancel 视为真实的终止路径。浏览器在需要处理其他行为，或交互无法按预期继续时，可能取消指针操作。具体情况取决于平台和操作。应把取消视为停止当前手势的信号，丢弃或妥善结算临时状态，并让界面恢复可用；这并不表示用户做错了什么。

取消处理对触控交互尤其重要，因为浏览器和页面共同承担手势处理职责。如果用户在页面上开始移动，浏览器可能把该动作解释为平移或缩放，而不是应用内拖动。CSS touch-action 允许应用声明希望在特定区域处理哪些直接操作行为。应选择控件实际需要的最窄行为范围。广泛禁用浏览器手势可能降低页面可用性，也可能妨碍熟悉的浏览器行为。

在 pointerup 或 pointercancel 后，应清除活动交互状态和临时视觉效果。如果交互使用了指针捕获，也要处理捕获丢失通知。清理操作应支持重复执行：多个结束事件可能与组件卸载、路由变更或浏览器发出的取消同时发生。幂等清理可防止重复提交和过期界面。例如，列表拖动应当只提交一次到有效位置，或者恢复原位置，不能两者都做。

使用指针捕获让拖动保持关联

拖动时，指针可能移出交互开始所在的元素。如果没有明确策略，事件目标可能转移到其他元素，导致原控件收不到完成操作所需的事件。指针捕获允许某个元素在特定指针活动期间继续接收该指针事件，即使指针已移动到页面其他位置。代码可以使用活动指针标识符调用 setPointerCapture() 请求捕获，并在适当时释放捕获。

对于含义会延伸到原命中区域之外的交互，捕获很有用，例如拖动滑块控件、移动项目、调整面板大小，或在画布上绘制。捕获不会冻结指针，也不会让指针留在被捕获元素内部；它会改变事件目标，使交互能够被可预测地完成和清理。应让可见反馈跟随指针当前位置，并明确呈现操作结果。

对于浏览器视为直接操作的触控和触笔输入，平台可能会在指针开始后建立隐式指针捕获。这有助于让连续手势始终关联到最初的目标。如果应用显式捕获指针，应只在活动指针已开始后这样做，并为捕获结束做好准备。完成或取消时应释放相关状态，不要假定捕获会在每一种生命周期转换中持续存在。

捕获不能替代周全的交互边界设计。被捕获的指针仍可能被取消，用户也仍必须能够停止或撤销持续时间较长的操作。如果拖动会控制重要内容，应提供清晰预览、可预测的提交时机，以及从意外放置中恢复的方式。不要让一个微小且不精确的移动变成不可逆操作。如果点击、键盘命令或菜单可以更简单地完成同一任务，也应提供这些替代方式。

还要考虑渲染过程中被捕获的元素遭到移除或替换时会发生什么。框架可能随着状态变化重新创建 DOM 节点；新节点不会自动延续旧节点上的每一种交互。条件允许时，应保持交互所属元素稳定，并确保组件卸载时完成清理。如果用户在拖动期间切换路由或关闭对话框，不要让隐藏的交互继续在后台活动。

让鼠标、触控和触笔操作易于理解

鼠标交互可以提供悬停反馈，但悬停只能是补充。不要把重要说明、标签或控件隐藏在只有鼠标才能触发的状态下。用户可能同时连接触控屏和鼠标，也可能在通常被称为移动设备的设备上使用键盘。只询问一次用户拥有什么设备，并不能描述之后发生的每次交互。

触控输入需要易于触达、彼此区分的控件。触控并非只是精度较低的鼠标：接触区域更宽，手指会遮挡部分屏幕，浏览器也可能为滚动或缩放保留手势。相邻操作之间应留出足够空间以减少误选，使用能说明结果的标签，不要让小图标成为唯一可操作区域。较大的目标区域是一项实用设计选择，能减少多种输入方式下的错误，而不是用来识别设备。

触笔可能适用于书写、绘图、批注或选择精细内容。如果应用使用了触笔专属属性，也应为不提供这些属性的指针提供合理的基础行为。例如，支持压力感应笔画的笔记界面，在使用手指或鼠标时也应保持可用。不要让压力、倾斜角度或特定触笔功能成为普通导航或填写表单的前提。

不要从 pointerType 推断用户的技能或无障碍需求。该属性描述的是 API 中宽泛的事件类别，并不能证明某人正拿着某种具体产品、使用哪只手、能够完成某种手势，或偏好哪种输入方式。用户可能依赖开关设备、语音输入、替代指针或浏览器无障碍功能，这些方式未必能整齐地归入鼠标、触控或触笔标签。应用应避免将指针特征作为身份信号保留，并且只收集具有明确且已披露产品用途的交互数据。

浏览器仍负责交互环境的许多部分，包括原生手势、焦点行为和辅助技术集成。网页不应试图通过自定义事件模拟来替代这些机制，也不应向站点或服务隐藏输入方式。应围绕用户的正当控制权构建界面：显示当前状态、尊重平台行为，并允许用户选择可用的操作方式。

键盘操作是一条并行途径

Pointer Events 本身不提供键盘操作能力。视觉上明显的拖动手柄，对键盘用户仍可能无法使用。完成工作流程所必需的每项任务，都应能在不移动指针的情况下到达并操作。按钮、链接、表单字段和开关适用时，应使用原生交互元素。原生控件已经具备焦点和键盘交互行为，而自定义视觉元素不会自动继承这些行为。

WCAG 的键盘操作指南说明了并行要求：功能应能通过键盘界面操作，不能要求用户按某一特定指针移动路径完成操作。Pointer Events 可以支持其中一条交互路径，但不能替代这一键盘要求。

对于自定义组件，应定义用户如何进入组件、在其各部分之间移动、激活操作并离开组件。焦点必须清晰可见。应采用该类控件预期的键盘行为，并通过合适的语义暴露控件名称、角色和状态。例如，自定义滑块不仅需要跟随 pointermove 的滑块，还需要可聚焦控件、易懂的数值反馈和键盘调整方式。可排序列表应提供键盘方法，让用户选择项目、移动项目、确认新位置，或取消并恢复原顺序。

如果语义按钮或表单控件能够表达同一操作，就不要只把应用逻辑绑定到低层指针事件。通过键盘、辅助技术或指针激活原生按钮，都应执行相同命令。对于原生语义不足以表达复杂操作的画布交互，应配合控件或结构化替代方式，让用户完成同等有意义的工作。如果任务需要编辑内容或选择数值，替代方式就不应只是无法继续操作的文本描述。

键盘和指针操作路径不必外观相同。指针拖动可能很自然，而键盘用户可以获得明确的“上移”和“下移”命令。关键是两条路径都能达到相同且有意义的结果，并传达状态变化。项目移动后应显示或播报确认，让焦点留在合适元素上，并允许用户取消。避免设置迫使用户快速完成手势的时间限制。

测试焦点顺序时也要检查指针操作顺序。打开弹出层时，应按交互需要将焦点放到适当位置；关闭后，应把焦点移回容易理解的位置。指针选中操作不应全局移除焦点指示。用户可能先用触控选择控件，再继续使用硬件键盘。应将这些切换视为正常情况，并让当前焦点和选中状态保持可见。

在不同输入条件下验证结果

跨设备测试最有用的方式，是在一组小而明确的条件下检查相同用户任务。应包括桌面环境中的鼠标与键盘路径、手机或平板上的触控优先路径，以及应用确实支持时的触笔输入。再加入桌面上的纯键盘操作和至少一种窄视口。如果正在调查兼容性问题，应记录浏览器和平台版本，但不要把测试变成用户设备普查。

为每项任务定义可验证的结果：菜单打开并可以关闭、卡片移动到有效位置、绘图完成、数值改变，或错误恢复。然后测试完整生命周期：开始操作、移出原目标范围、在相关情况下分别在控件内外完成操作、取消、打断组件，并重复操作。确认界面不会卡在按下、拖动或模态状态。

触控测试应包括浏览器手势。滚动包含可拖动区域的页面，确认该区域在需要时允许正常滚动，也确认有意进行的直接操作不会意外吞掉所有页面移动。应在最小相关元素上检查 touch-action 设置，而不是在整个应用中禁用手势。除非产品有明确且合理的交互需求，否则应验证缩放和浏览器导航仍然可用。

应在实际观看尺寸下检查目标质量。在可能的使用情境中尝试单手操作，测试屏幕边缘附近的控件，并查找间距过近的控件。不要只用精确光标点击大显示器中央。还要检查用户的手指或手掌遮挡控件一部分时，可见标签和状态是否仍清晰。如果工作流程支持屏幕方向变化和滚动，也应进行测试。

接下来，不使用指针重复核心任务。通过键盘导航、激活控件、修改数值、重新排列内容并从错误中恢复。确认焦点始终可见，且不会被对话框或粘性区域遮住。如果工作流程承诺支持辅助技术，还应涵盖产品承诺支持的技术和平台。指针事件测试不能代替对名称、角色、状态播报和阅读顺序的测试。

自动化测试有助于验证状态清理和事件处理，但不能证明目标大小舒适、标签易懂或键盘操作路径合理。应将自动检查与代表性设备和浏览器版本上的实际操作评审结合起来。记录简洁的测试矩阵，包括任务、输入路径、预期结果、实际结果、浏览器与平台，以及后续事项。截图和交互日志应仅保留测试所需内容，避免采集个人内容或不必要的指针遥测数据。

如果某个平台出现缺陷，应先隔离用户实际看到的行为。检查页面是否收到取消事件、指针捕获是否结束、焦点是否移动，以及浏览器手势处理是否符合预期设计。只有在有助于解释行为时，才比较受支持的浏览器版本或其他代表性设备。不要推断用户身份，也不要伪造事件模式来强迫出现不同结果。兼容性工作应改善使用该应用的人所获得的真实交互体验。

对每项重要交互使用下面的可执行验收矩阵：

请依据 W3C Pointer Events Level 3 推荐标准 和适用的 WCAG 2.2 成功标准执行这些场景。使用两个具体任务：拖动卡片重新排序，以及在画布上绘制笔画，并记录可观察结果，而不是推测输入设备。

场景	前置条件与操作	通过标准	要记录的证据
卡片拖动完成	抓起卡片，移出原目标范围，在有效位置释放。	一次 pointerdown/pointerup 生命周期只提交一次排序；新顺序和成功提示可见，后续控件可用。	事件记录、顺序和可见状态。
绘图完成	在画布按下，绘制一笔后在起点区域内或略移出后释放。	笔画只提交一次并保持可见，完成状态同时以视觉和辅助技术可感知的方式提供。	指针记录、已绘制笔画和状态提示/播报。
取消	执行 pointercancel（或明确的 Escape/中止命令），然后观察 lostpointercapture 清理；另测 pointerup 后的 lostpointercapture。	取消路径只回滚一次；pointerup 已提交的路径保持只提交一次。lostpointercapture 本身不会回滚或重复提交；同时清除捕获、样式和临时笔画。	事件序列及取消/提交后的断言。
键盘替代与焦点	仅用键盘重新排序卡片并取消一次。对于绘图，先判断任务是否依赖自由路径；若不依赖，提供等效的结构化/数值键盘替代。	键盘排序可到达且可操作，焦点可见并播报成功/取消。绘图在需要时提供已说明的产品特定键盘或结构化替代；仅文字描述不能完成编辑或数值选择。	按键序列、焦点元素、任务判断和状态文本。
恢复与失败	使用无效放置位置或在操作中移除所属视图，然后重新尝试。	清除临时状态；用户看到可执行的失败消息和明确的恢复结果；重试不会造成重复操作并能完成任务。	失败消息、恢复状态、恢复操作和第二次结果。

只要缺少任一通过标准，或结果只能根据 pointerType、时间差或设备标签推断，该场景就算失败。验收关注可观察结果，不是检测产生输入的人或设备。

实用检查清单

发布前，确认每种自定义指针交互都定义了开始、移动、成功结束、取消和清理路径。验证临时状态会在中断后移除，且操作不会重复提交。只有在交互需要将事件目标延伸到原元素之外时才使用指针捕获，并妥善处理捕获结束。

确认悬停不是发现或使用功能的唯一方式。触控目标应有实用尺寸并保持适当间距，浏览器滚动与缩放仍然可用，触笔专属增强也不会阻碍其他用户完成任务。应有意识地选择 touch-action，并将任何限制控制在确实需要的交互区域内。

最后，使用纯键盘完成同一项必要任务。检查焦点可见性、语义、状态反馈和取消操作。测试有代表性的浏览器、视口和输入条件；记录实际验证过的内容，并确保测试证据与目的相称。Pointer Events 提供了有用的共享基础，但无障碍交互取决于围绕它构建的完整体验：控件易懂、用户有选择权、操作可恢复，并且兼容平台行为。

公开来源

• W3C Pointer Events Level 3 推荐标准
• MDN Pointer Events
• WCAG：键盘操作
• WCAG 2.5.2：指针取消（取消行的直接来源）
• WCAG 2.5.8：目标尺寸（最低）（目标尺寸指南；应用可采用更严格阈值）
• WCAG 2.4.7：焦点可见 与 2.4.11：焦点不被遮挡（最低）（焦点标准；单次提交和重试属于应用验收要求）