WAI-ARIA对自动完成小部件的支持

最新推荐文章于 2020-12-17 03:50:46 发布

dnc8371

最新推荐文章于 2020-12-17 03:50:46 发布

阅读量319

点赞数

文章标签： python java linux 大数据 vue ViewUI

在本文中，我想讨论AutoComplete小部件的可访问性。在您键入该字段时，通常会使用“自动完成”窗口小部件提供建议。在当前的工作中，我基于Twitter的Typeahead （一个灵活JavaScript库）实现了JSF组件，该库为构建可靠的typeahead提供了坚实的基础。 Typeahead小部件具有伪代码形式的可靠规范，该规范详细描述了UI对事件的反应。 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 。简单尝试一下工具。