spark wai

在这篇文章中，我想讨论一个AutoComplete小部件的可访问性。 在您键入该字段时，通常会使用“自动完成”窗口小部件提供建议。 在当前的工作中，我基于Twitter的Typeahead （一个灵活JavaScript库）实现了JSF组件，该库为构建健壮的typeahead提供了坚实的基础。 Typeahead小部件具有伪代码形式的可靠规范 ，详细说明了UI对事件的React。 Typeahed可以在相应的输入字段中显示提示，例如google的搜索字段显示该提示，突出显示匹配项，处理自定义数据集和预编译的模板。 此外， Bloodhound建议引擎还提供预取，智能缓存，快速查找以及回填远程数据的功能。

尽管有许多功能，但Typeahead的一大缺点是对WAI-ARIA的支持不足（我要说到现在为止，它是完全缺失的）。 AutoComplete小部件的设计应使屏幕阅读器和其他辅助工具的用户可以立即使用。 我决定添加完全的WAI-ARIA支持，完成此任务并将我的请求请求发送到GitHub。 以下是带有解释的新“ WAI-ARIA感知”标记（未省略相关HTML属性）。

<input class="typeahead tt-hint" aria-hidden="true"><input class="typeahead tt-input" role="combobox"aria-autocomplete="list/both"aria-owns="someUniqueID"aria-activedescendant="set dynamically to someUniqueID-1, etc."aria-expanded="false/true"><span id="someUniqueID" class="tt-dropdown-menu" role="listbox"><div class="tt-dataset-somename" role="presentation">...<span class="tt-suggestions" role="presentation"><div id="someUniqueID-1" class="tt-suggestion" role="option">... single suggestion ...</div>...</span>...</div>
</span><span class="tt-status" role="status" aria-live="polite" style="border:0 none; clip:rect(0, 0, 0, 0); height:1px;width:1px; margin:-1px; overflow:hidden; padding:0; position:absolute;">... HTML string or a precompiled template ...
</span>

tt-hint类的第一个输入字段模拟视觉提示（如上图）。 提示以可视方式完成对匹配建议的输入查询。 可以通过按右箭头或Tab键完成对建议（提示）的查询。 该提示与屏幕阅读器无关，因此我们可以将aria-hidden =“ true”应用于该字段。 屏幕提示会忽略该提示。 为什么不重要？ 因为我们将通过aria-live =“礼貌”（将在下面进行说明）通过“状态”区域强行阅读匹配的建议。

下一个输入字段是用户输入查询的主要元素。 它应该具有角色=“ combobox”。 对于自动完成，建议使用此角色。 有关更多详细信息，请参见WAI-ARIA官方文档 。 实际上，docu还显示了AutoComplete的粗略标记结构！

主输入字段应具有各种ARIA状态和属性。 aria-autocomplete =” list”表示当用户输入时，输入以列表的形式提供自动完成建议。 aria-autocomplete =“ both”表示提示也由提示（除了列表）提供。 aria-owns属性指示输入字段和带有建议的列表之间存在父/子关系。 当无法使用DOM层次结构表示关系时，应始终设置此属性。 否则，屏幕阅读器将很难找到包含建议的列表。 在我们的例子中，它指向列表的ID。 最有趣的属性是aria-activedescendant。 视力不佳的用户通过箭头键在列表中导航。 aria-activedescendant属性将焦点更改传播到辅助技术-对其进行了调整以反映已导航到的当前子元素的ID属性。 在上图中，选中了“阿拉伯的劳伦斯”项目（突出显示）。 aria-activedescendant设置为此项的ID，屏幕阅读器会向盲人用户“ Lawrence of Arabia”读取。 注意：焦点停留在输入字段上，因此您仍然可以编辑输入值。 我建议在Google的Web Accessibility简介中阅读有关此属性的更多信息。

aria-expanded属性指示带有建议的列表是展开（true）还是折叠（false）。 列表状态更改时，此属性将自动更新。

带有建议的列表本身应具有“列表框”角色。 这意味着，小部件允许用户从选项列表中选择一个或多个项目。 应将role =“ option”应用于列表中的各个结果项目节点。 我建议阅读一篇有趣的文章“在构造自动完成列表时使用“列表框”和“选项”角色” 。 对于屏幕阅读器来说不重要的部分应标记为role =“ presentation”。 该角色说“我的标记仅适用于非盲人用户”。 您可能会问，角色=“应用程序”是什么？ 对我们重要吗？ 并不是的。 在阅读了“并非所有ARIA小部件都应具有角色=”应用程序”之后，我跳过了它。

标记中的最后一个元素是具有角色=“状态”和属性aria-live =“礼让”的范围。 这有什么用？ 您可以通过让用户知道自动完成的结果（通过自动朗读的文本）来为小部件增添趣味。 小部件应将要说的文本添加到移到视口之外的元素中。 这是所提到的具有应用样式的span元素。 样式与jQuery CSS类ui-helper-hidden-accessible完全相同，后者以可视方式隐藏内容，但仍可用于辅助技术。 span元素的aria-live =“ polite”属性意味着–应该在下一个宽限间隔（例如，当用户停止键入时）宣布该元素内的更新。 通常，aria-live属性指示实时内容中的一段以及应宣布更改的详细程度。 我在项目中将自动完成的口语文本定义为由Handlebars编译JavaScript模板（也可以使用其他任何模板化引擎，例如Hogan ）。

Handlebars.compile('{{#unless isEmpty}}{{count}} suggestions available.' +'{{#if withHint}}Top suggestion {{hint}} can be chosen by right arrow or tab key.' +'{{/if}}{{/unless}}')

当用户停止键入内容并显示建议时，屏幕阅读器会读取可用建议的数量和顶部建议。 非常好。

最后但并非最不重要的是测试。 如果尚未安装屏幕阅读器，请安装Google Chrome扩展ChromeVox和Accessibility Developer Tools 。 这些是开发的好工具。 请观看简短的ChromeVox演示和Accessibility Developer Tools演示 。 或者，您也可以尝试使用免费的独立屏幕阅读器NVDA 。 简单尝试一下工具。

翻译自: https://www.javacodegeeks.com/2014/10/wai-aria-support-for-autocomplete-widget.html

spark wai