多个滑块换了左右位置，Tab顺序为何仍应保持不变

一个轨道上有两个滑块，画面中的左右顺序可能随着数值改变。键盘使用者按Tab访问它们时，顺序是否也跟着调换？W3C的ARIA Authoring Practices Guide在多滑块模式中给出明确说明：访问次序应保持不变，不随滑块数值及视觉位置改变。[1]

这一模式讨论的是由两个或更多滑块组成、共同设置一组相关值的控件。文档说，它们经常位于同一轨道上，每个滑块负责其中一个值。把它画成一条线，并没有让多个值自动变成一个键盘访问对象；APG要求每个滑块都进入Tab序列。

先要确认这些值之间有没有约束。原文指出，许多范围滑块不允许交叉，例如一个滑块表示最小值，另一个表示最大值，前者的上限可能受后者约束；也有控件中的值彼此独立。因此，“滑块能交换左右位置”只是某些情境中的可能行为，不应写成所有范围选择器都必须允许的功能。

次序规则则不以是否交叉为转移。APG说明，即使某个滑块可以经过另一个，它在Tab序列中的次序仍保持原样。[1] 视觉位置回答当前值在轨道上的什么位置，键盘次序回答按Tab接下来访问哪个滑块。两者有联系，却不能简单使用“永远先访问左边那个”来代替明确的控件身份。

设想一份允许独立数值变化的比较界面，设计稿将两个滑块分别标作甲与乙。当甲移到乙的另一侧时，说明中的“先甲后乙”与“先左后右”会产生不同含义。这个例子只是帮助检查交接语言，没有运行真实控件。设计资料应让读者知道名称指向哪个值，也应把值约束与访问次序分别交代。

文档的状态属性说明进一步体现了每个滑块各自拥有值与可访问名称的关系。不过，本篇不提供属性配置代码，也不依据一张视觉稿确认实现已经满足这些要求。所读页面还提醒，某些触摸辅助技术使用者可能遇到操作困难，需要在实际设备与辅助技术组合中测试。

对界面设计交接而言，保留稳定的对象名称比依赖一时的左右位置更利于说明状态变化。本文只解释APG模式中的关系与条件，首次发布日期未核实，没有执行键盘、触摸或读屏测试，也不将采用模式视为完整可访问性验收通过。