限制日期选择器中的手动日期输入时可能出现的可访问性问题

Question

我想知道如果仅将日期输入限制为选择器是否会出现任何可访问性问题。

我想限制用户仅使用日期选择器设置日期，并阻止用户使用键盘手动输入日期（例如在这个问题中）。

如果我禁用键盘输入并将用户限制为仅使用选择器：

这会导致任何可访问性问题吗？

Answer 1

这显然会造成可访问性问题，或者至少对几种用户造成重大不便：

• 屏幕阅读器用户：即使可以访问日期选择器，许多屏幕阅读器用户也不太习惯在此类组件中导航。无论对于初学者还是高级用户来说，直接输入所需的日期都更加简单快捷。
• 仅使用键盘的用户：出于与上述相同的原因，让他们必须在日期选择器中导航会带来很多不便
• 语音控制：如果你不能直接告诉在字段中输入什么，那么使用它也会变得痛苦。有些用户无法使用键盘、鼠标或触摸屏，但仍依赖它。
• 特殊设备：某些设备的行为与键盘非常相似，因此通过阻止键盘输入，您也可能会阻止使用它们。示例包括盲文显示器、条形码/二维码阅读器、眼动仪等。如上所述，这不仅仅是为了方便，它们对于用户自主工作也至关重要。

为用户提供多种输入数据的选择是可访问性的一个重要关键。您提供的可能性越多，用户找到适合他/她的方法的机会就越大。 这也使得界面更加友好。

说到 WCAG，A 级各处都需要适当的键盘支持。鼓励提供多种输入可能性（键盘+其他输入）。 请参阅 WCAG 2.2 的 2.1 和 2.5 节。 所以明确阻止键盘操作当然会让你不合规。

事实上，你应该问自己为什么要阻止键盘输入。当然没有充分的理由这样做。

如果您担心用户输入格式错误的日期，或者格式正确但从业务角度来看无效的日期（例如预订已满或过去的日期），您应该：

1. 清楚地告诉用户需要/期望什么，包括“dd/mm/yyyy”等指示格式或举例，以及您的业务何时可用（例如“周一至周五 08:00-18”） :00".
2. 通过智能组合视觉线索、表单验证 API、aria-invalid 属性、aria-live 消息，在检测到错误时立即通知用户并帮助他/她修复错误。您会发现很多涉及这些主题的文献。
3. 始终检查服务器端的输入

最后，如果尽管我上面有解释，您仍然想阻止键盘输入，请注意，它可能不像您想象的那么简单。 一些辅助工具和一些设备直接设置输入值并完全绕过正常的键盘事件。您还应该认为用户可以通过选择上下文菜单中的“粘贴”项而不是 Ctrl+V 来粘贴值。 而且，最重要的是，请记住，始终可以完全绕过整个前端并直接向服务器提交任何内容。