视障人士的输入助手和可访问性答案

【问题标题】：Input helpers and accessibility for visually impaired视障人士的输入助手和可访问性
【发布时间】：2013-08-28 06:54:46
【问题描述】：

我正在编写一种特定类型的北美电话号码输入助手，它在输入旁边显示一个框，动态显示部分输入结果的格式化结果。例如，如果用户迄今为止在输入中键入了“2345678”，则该框将显示“(234) 567-8___”。

如果用户随后键入“@”，则该框将显示红色“(234) 567-8@__”以指示无效字符，或者如果用户随后键入“012”，则该框将显示“ (234) 567-8012" 为绿色，表示有效、完整的条目。

有没有人知道尝试让这也为屏幕阅读器用户提供反馈是否会有所帮助？也许，通过给输入助手框一个 aria-live=polite 属性值？ ...或者那会很烦人吗？

【问题讨论】：

【解决方案1】：

如果您想向使用屏幕阅读器的人显示错误，则需要将错误文本添加到页面上具有aria-live 属性和hide it accessibly（如果您选择）的不同节点。

请注意，aria-live='polite' 将等待当前读取顺序完成。如果您希望用户立即停止并调整他或她的操作，assertive 值更合适。

作为替代方案，使用客户端验证并在提交时引发错误。考虑使用<input type='tel' /> 来执行此操作。这将是更标准且破坏性更小的解决方案。

在任何一种情况下，以与输入相关联的方式宣布预期的格式，无论是事先还是作为错误消息的一部分。

【讨论】：

助手已经是一个单独的元素，用于为有视力的用户提供建议，所以我想简单地添加 aria-live 属性。我的理解是，一旦用户在打字过程中暂停，“礼貌”就会开始说话，这似乎是合适的，而不是在每次按键后都试图说话。使用“tel”的输入类型是一件好事，但就其本身而言，在格式化方面没有任何作用。模式属性将验证，但不会自动填充括号等，或提供有关最终重新格式化的值/有效性的反馈。
啊——我明白你对单独元素的意思了。这是错误或完成报告，应该中断。
我想我的问题不在于如何去做，而在于这样做是否是一件好事。由于我发现它对视力正常的用户很有用，我猜盲人也会觉得它有用，但我不知道。也许，这会比它的价值更烦人？
在我看来，用声音宣布盲人用户的拼写错误/格式更改是破坏性和烦人的。对于有视力的用户来说，它比视觉突出显示更具干扰性，即使它等待输入完成。我怀疑如果您宣布所需的格式并进行客户端验证，它会更符合盲人用户的预期行为。
感谢您的意见。 :)