我正在寻找有关残疾用户如何利用隐式提交（https://www.w3.org/TR/html50/forms.html#implicit-submission）的见解？
我想知道在可访问性世界中是否必须在输入文本为焦点时在回车键上提交表单？我确定它在某些情况下可能有用，但我知道在其他情况下也可能有害...
例如，如果某些键盘用户按下Enter键想要添加新行，而是发送表格怎么办？如果他在扫描所有表单输入之前按了较长的表单，然后提交缺少一些重要信息的表单怎么办？
另一方面，无需提交所有表格即可集中精力提交按钮并提交...而无需提交所有表格即可提交表格
我知道JAWS和NVDA提供了键盘快捷键以转到下一个按钮，因此我想知道它是否真的对他们有用。在此问题上，用户使用阅读器或键盘导航来浏览Web有什么期望？
答案 0 :(得分：1)
QuentinC的回答很好，所以我不会回答每一个问题。
我建议您不要尝试干扰隐式表单提交，除非您有充分的理由这样做。
例如，如果某些键盘用户按下Enter键想要添加新行，而是发送表格怎么办？
对于<textarea>，按Enter键通常会产生新行，并且不会发生隐式表单提交。对于<input type="text">，按Enter键将隐式提交表单。
尽管如此，某些应用程序还是会覆盖此行为（在我看来，这是令人困惑的方式）。消息传递应用程序是一个常见的示例，该应用程序已覆盖Enter键，因此表示“发送消息”。为了获得新行，他们放置了一些自定义行为，例如CTRL + ENTER来创建新行。不过，这不是<textarea>的默认行为。更糟的是，不同的消息传递应用程序却相反。一些提供用户首选项，以配置按Enter键发送消息还是添加新行（Slack提供了首选项）。
另一方面，无需提交所有表单即可集中精力提交按钮并提交...而无需提交所有表单即可提交表单。
这是避免干扰浏览器默认行为的隐式表单提交的主要原因。作为键盘用户，我经常使用它。屏幕阅读器提供了各种导航快捷方式，但对于不使用辅助技术的有眼力的键盘用户而言，这些功能不可用。
答案 1 :(得分：0)
网络上的大多数表单都具有内置的隐式提交行为，因此辅助技术的用户不会对此感到惊讶，并且我在使用屏幕阅读器时也没有遇到过这种问题。
但是，您应该确保您始终提供适当的按钮来提交表单。 See WCAG 3.2.2
您还应确保尽可能方便地在以后/以后返回和更改数据。
答案 2 :(得分：0)
我是屏幕阅读器用户。我认为，使用Enter键进行隐式提交是绝对必要的。 除非它引起的烦恼超过了解决的烦恼，但这是极为罕见的。
通常，屏幕阅读器和纯键盘用户比普通用户要慢得多。 而且我确认，当Enter键无法按预期工作时，必须手动导航到“提交”按钮很烦人。
碰巧的是，如果您做的正确，这是隐含的，您无需做任何支持。 不破坏隐式输入提交的最基本规则是：
<input type="submit"/>，<button type="submit"/>或<input type="image"/>表示按下Enter键后自动触发的提交按钮。 必须存在提交按钮，不得禁用它，并且不显示：none ，以便通过enter进行隐式提交。 如果您愿意，该按钮可能在屏幕上不可见。
第二条规则提醒您单击按钮不正确，因为在另一个字段中按Enter时不会触发该操作。 从而打破隐式提交。这是隐式提交无法按预期工作的最常见原因。
第三个规则确保在执行隐式提交时按下右键。 如果有多个按钮，通常应采用DOM顺序中的第一个按钮，但浏览器有时会有不同的行为，尤其是IE。因此，最好是始终避免这种情况。
现在为您的小恐惧：
例如，如果某些键盘用户按下Enter键想要添加新行，而是发送表格怎么办？
原则上不会发生意外情况。
输入文本字段时，屏幕阅读器会看到它，无论是单行（<input type="text"/>）还是多行（<textarea>）
如有疑问，请记住贴上适当的标签。 如果标签是“注释”，“消息”或“地址”，则可以合理地认为该字段为多行；如果它是“名字”或“城市”，我暗中知道它不是。
如果他在扫描所有表单输入之前按了较长的表单，然后提交缺少一些重要信息的表单，该怎么办？
这很常见，但您不必担心。
为您提供清晰有效的错误消息给用户，同时在表单内部尽可能简单地导航是您的工作。 返回，理解和修复错误越困难，最终提交表单的机会就越少；它的下降速度非常快，屏幕阅读器用户的下降速度更快。 如何做好是另一个问题。