带有可访问性工具的直接输入区域

Posted 2023-03-12

【中文标题】带有可访问性工具的直接输入区域

【英文标题】：Direct input area with accessibility tools on

【发布时间】：2021-09-08 21:09:29

【问题描述】：

大家好。

这是我的第一个问题，我知道这可能有点棘手，但我会尝试。

我目前正在开发一个可访问的网络应用程序，并且我想构建一个“直接触摸区域”，就像一些适用于 ios 的本机应用程序一样，当用户专注于它时，其中的可访问性助手会被禁用。 我在前端开发中使用 html、javascript 和 CSS。

当辅助工具（android 版 TalkBack、iOS 版 VoiceOver）打开时，如果您用一根手指触摸屏幕，则无法与 DOM 交互，因为您处于“触摸浏览”模式。 我需要绕过这种特殊行为，但只是针对一个精确的区域。

我在各种 ARIA 属性、角色等方面苦苦挣扎，但还没有找到方法。 例如，有一个名为 aria-disabled (true|false) 的 HTML 属性，它使屏幕阅读器简单地忽略区域内容，因此在我的情况下它没有用。 “aria-hidden”属性也会发生类似的情况。

也许有人已经遇到过这个问题并以某种方式解决了？

任何帮助将不胜感激！

【问题讨论】：

请澄清您的具体问题或提供更多详细信息以准确突出您的需求。正如目前所写的那样，很难准确地说出你在问什么。

【参考方案1】：

我不太明白这个问题的意思，但也许“Aria-Disabled”会有所帮助？

Aria-Disabled Reference

【讨论】：

很抱歉，我在您回答问题时正在编辑问题。是的，我尝试过使用“Aria-Disabled”：它禁用了 DOM 的部分，但我仍然无法直接触摸该区域进行交互。相反，ARIA-Hidden 将内容隐藏到屏幕阅读器，但它仍然可见。我正在寻找的是能够用一根手指触摸那个特定的 ，就像关闭 TalkBack/VoiceOver 一样。目前，当我触摸该区域时，我必须用两根手指而不是一根手指。谢谢你的帮助！

【参考方案2】：

role="application" 是在屏幕阅读器不先捕获事件的情况下将事件直接传递给元素的方式。但是要非常小心这个角色。应谨慎使用。

请注意，此角色将不会关闭该元素的 VoiceOver。用户仍然需要能够浏览屏幕。您可以实现双击并按住以进入用户直接与您的对象交互的模式，然后实现双指“Z”滑动以退出该模式。

【参考方案3】：

首先，无法绕过触摸探索模式，因为它是由画外音或对讲处理的。更重要的是：这样做会造成伤害，因为这种行为会抓住用户并且他或她将无法浏览元素。作为一个天生的盲人和日常用户，我自己就是这样的屏幕阅读器：在应用程序的控件中滑动被阻止让我立即擦除它，让我感到沮丧。请记住，屏幕阅读器用户在通过滑动找到您的输入区域之前将无法触摸它。他或她可以知道确切的位置和大小，但这更像是命运的转轮。

https://www.w3.org/TR/wai-aria-practices 的 ARIA 1.1 在关于移动和触控支持的章节中指出，目前对此没有标准，也没有 ARIA 角色。

您可以在用户通过“触摸探索”找到该区域后激活该区域后切换到 aria-disabled，但我不知道用户将如何返回到其他控件。

使用应用程序元素似乎是最好的方法，但用户必须记住一个特殊的键，以便他们的屏幕阅读器离开应用程序，因为例如NVDA 或 JAWS 将在按下此魔法键之前将其读取应用程序框起来。这样我多次使用office365就被困在office文档中了！

【讨论】：

感谢您的准确解释。好的，我发现很难实现应用程序角色，并且我无法获得我想要的东西。我没有告诉你它是用于可访问的游戏，其中有一个旨在通过直接触摸访问的区域。该区域将通过使用屏幕阅读器进行浏览来识别，并且用户会知道他可以像关闭 VO/TalkBack 一样操作。无论如何，我真的很感谢你的帮助和你分享给我的链接。如果我能找到解决方法，我会告诉你的！最好的问候！

啊，好的，这是一个重要的部分。虽然这在移动设备上运行良好，例如在应用程序 thumbjam 中，但我不知道桌面系统上有任何类似的用户体验。也许使用屏幕阅读器中的 API 会有所帮助，但没有一个适用于所有阅读器的 API。