问(何时)屏幕阅读器用户使用选项卡吗？

EN

因此，首先，你是混淆了标签和焦点。虽然屏幕阅读器用户可以使用箭头键导航，但他们也可以显示页面上的链接列表，或窗体、区域、表或(最常见的)标题，以便导航到他们感兴趣的部分/了解页面布局。

标签是有用的，因为有很多人不能，挣扎或不喜欢使用鼠标，但不需要帮助屏幕阅读器，即脑瘫，因为准确性问题。

希望这能让你明白点什么。

至于在多页表单上自动对焦输入，这更像是一个UX issue...is，如果您自动对表单进行对焦，那么它对所有用户来说是很好的UX。

我会说是的，要求人们点击，标签或使用快捷方式获得输入，如果这将是99%的人需要采取的行动是不好的UX。

注意，我说的是<input>，而不是标题。

您要做的是研究如何在流程的第一页上指示这是一个多页和多步骤的表单。

您还应该考虑使用一个复选框作为第一步，上面写着“此表单是多页的，您希望我们在加载新页面时自动调整第一个问题吗？”并将其默认选中。

这样，如果有人愿意的话，可以选择停止自动对焦。

另外(或者，如果不需要复选框，则可以考虑在submit按钮附近添加一些文本(并将其与aria-labelledby和ID正确关联)，这说明下一步将加载新页面，第一个输入将自动聚焦。

另一件事是，假设您已经正确命名了页面(表单、名称或流程--步骤2)，那么屏幕阅读器用户可以很容易地确保它们在正确的页面上。

因此，如果这是一个多页表单，而不是标题级别1，则集中输入。

导航后聚焦标题是单页应用程序(SPAs)的一个技巧，因此您可能已经看到了这一点，如果您通过AJAX加载页面内容，那么这是建议的导航方式之一。您指出了下一页“加载”，这使我认为这是一个多页应用程序，但我认为我最好添加，以防万一，作为一般提示。

请记住，所有这些建议都是一般性的。根据您的表单、站点设计、加载模式、用户基础(经验丰富的用户/内部系统与一般公众)等，最佳实践可能有所不同。

因此，简短的回答-使用自动聚焦在输入，如果这是一个多步骤的形式，你认为这是适当的，很明显，输入将是下一个要填写的东西。

然后，与使用屏幕阅读器的人一起测试，并获得关于它是否有意义、是否令人困惑或意外的反馈。

您混淆了屏幕阅读器用户和键盘用户。其中一个并不一定意味着另一个。

有阅读障碍但视力正常的人可以使用屏幕阅读器，这样他们就可以听到大声的文本，而不是自己努力阅读，但由于他们使用鼠标或触摸界面，所以他们不是键盘用户。

使用手有困难但视力正常的人可能无法使用鼠标或触控界面。他们不需要屏幕阅读器，但只需要使用键盘或其他特定的输入设备来模仿键盘中最重要的键(特别是选项卡、箭头键、输入和转义)。某种形式的操纵杆可以是这样的装置。

考虑到上面所说的，设计一个合适的键盘导航并优化它总是有意义的。对于一些屏幕阅读器用户来说，这可能并不重要，但对键盘用户来说非常重要，因为这可能是他们与应用程序/页面交互的唯一途径。

我是一个屏幕阅读器用户。与其他人一样，我认为对输入焦点的混淆与结构和上下文的关注有关。关于何时“优化”TAB经验的第一个问题。它总是很重要，因为键盘导航是我作为屏幕阅读器用户在工具箱中使用的一个支持支柱。此外，任何基于输入的非屏幕阅读器可访问性工具都可能使用这种访问方式。

作为一名开发人员，我一直给其他人留下深刻印象的指导方针是，您希望代码的自然结构和流程为您完成大部分工作。其次，这个过程应该遵循你的目标受众的期望，而且你似乎想要遵循“向导”的风格。因此，让我详细说明在使用屏幕阅读器时向导风格问卷流的典型期望。

UX点:页面重新加载是完全的还是动态的？

这很重要，因为这直接影响到我当前的读者“游标”，以及我将如何导航以找到问题。

从上述声明中，我将假设H2将被一致使用。因此，我将自然地使用快速导航到第一个H2。

现在，我将使用屏幕阅读器工具来阅读这个问题(不管是TTS还是盲文输出)。

一旦我觉得我有了它的意义，我通常会使用TAB来找到第一个输入控件。按钮不是输入控件，因此违反了用户的期望。我正在寻找复选框，无线电框，文本字段和/或组合框。

如果是复选框或无线电框，那么我将假设一个组，并希望分组(遗憾的是很少出现)，并将使用策略来处理我已经发现的情况。如果分组，那么我将大量使用制表符快速移动，并听到特定框的“上下文”与输入集中在一起。

最后，一旦我回答了这个问题，我正在寻找下一个问题或前进/先前的机制。它们通常以按钮的形式出现。

我希望，我正在演示如何使用基本结构构建约定/期望，而不是试图将过程强加于用户。第三，像a11y项目这样的站点在编码方面非常有帮助。