Toolbar的一个停靠点，怎样容纳多个控件的焦点关系

W3C APG把toolbar定义为组织一组控件的容器，例子包括按钮、菜单按钮和复选框。其文字建议仅在群组包含三个或以上控件时使用这种分组元素。视觉上放在一起的控件，因而还需要向读屏用户表达群组的存在和目的；工具栏名称描述的是这一组，而不是把其中各项改成同一种按钮。[1]

模式所说的一个Tab停靠点，针对的是工具栏在外部键盘序列中的位置。进入这一处之后，内部仍有多个可获得焦点的控件，文档另用方向导航表达它们之间的移动。减少外部停靠数量，并未减少容器内实际控件数量。这是一种分层关系：页面序列中的群组入口，与群组内部具体焦点所在项，各自回答不同的位置问题。

横向与纵向工具栏的区别，也不只在画面排列。横向模式把左右方向用于控件间移动，上下方向可以重复这项导航，也可以留给需要上下方向操作的控件，例如spin button。纵向模式则把上下方向用于内部导航，左右方向可以重复导航，或保留给横向滑块等控件。原文这里区分了移动到某个控件，以及操作该控件本身两种用途。

多行工具栏继续沿用这种分工思路。文档允许左右方向的导航跨行延续，从而留下把上下方向交给控件操作的可能。若某个控件自身又需要工具栏导航占用的同一对方向，便形成用途冲突。指南因此讨论避免这种组合；确实无法避免时，限定为一个此类控件并放在末项，横向工具栏末尾文本框是原文的例子。这里保留的是模式对组合关系的描述。

进入工具栏时的落点，还有首次与再次进入的区别。第一次进入，文档规定焦点落在首个非禁用控件；工具栏此前已经含有焦点时，可以选择返回上一次获得焦点的控件。这个记忆位置是可选项，并非所有工具栏必有的历史恢复行为。没有采用该选项时，落点仍是首个非禁用控件。当前落点和曾经落点，不能只凭“返回工具栏”一句话合并。

禁用状态也有一处重要限定。指南说，键盘导航中的禁用元素通常不能聚焦；但当功能是否能被发现十分关键时，保留禁用控件的可聚焦性可能有帮助，让读屏用户更容易知道它存在。因此，存在某项功能、该项当前是否可用，以及焦点能否到达它，是文档分别讨论的事情。知道有这一项，不表示它已经恢复可用。

群组自身的标识与方向又提供另一层背景。APG区分有可见标签和没有可见标签两种情况，两者仍都需要为工具栏提供名称；其默认方向为横向，纵向排列则有相应方向表达。名称联系群组目的，方向联系内部导航模型，具体控件的状态则留在各控件层面。这些内容适合用来说明界面设计稿中的关系，本文没有运行示例或提供实现代码。