我有一个反馈表,我在其中询问用户取消的原因,如下所示:
label {
display: block
}
button {
display: block;
}
<form>
<fieldset>
<legend> Reason for cancellation? </legend>
<label>
<input type="checkbox"> Reason 1 </input>
</label>
<label>
<input type="checkbox"> Reason 2 </input>
</label>
<label>
<input type="checkbox"> Reason 3 </input>
</label>
<label>
<input type="checkbox"> Reason 4 </input>
</label>
<label>
<input type="checkbox"> Other </input>
</label>
<textarea aria-label="other reason"></textarea>
<button> Submit </button>
</fieldset>
</form>
文本区域与Other
复选框相关,即,仅当用户选择Other
选项时它才会被激活,否则它保持禁用状态
如何在标记中表示该关联?
我应该使用另一个字段集对复选框和文本区域进行分组吗?我不确定这在语义上是否正确,而且一般来说这是不鼓励的。 https://accessibility.blog.gov.uk/2016/07/22/using-the-fieldset-and-legend-elements/#:~:text=It%20is%20possible%20to%20nest,fields%20belong%20within%20which%20fieldset .
我应该使用 aria-controls 或 aria-owns 之类的东西吗?
在复选框标签中只提及
其他(请在下面填写原因)
是否就足够了,以便当标签公布时,用户可以知道有复选框后面的文本区域,可以通过 tab 访问也可以更改用户体验,始终允许用户出于任何选定的原因选择性地填写文本区域,因此文本区域可以是同一字段集的一部分,并且可以全部启用时间
注意: 我看过一些例子,特别是 Google Forms 和 Search Engine Journal。 Google 表单通过将文本框放在复选框旁边来解决此问题,文本框始终处于启用状态,并且只要您将注意力集中在文本框上,复选框就会自动选中。
搜索引擎日志,没有明确关联控件,但他们在复选框标签中提到了它,以填写下面的原因。
最佳答案
关于使用 ARIA 的解答
您可以使用 aria-controls,它似乎很适合您的情况。 它看起来比 aria-owns 更合适,请参阅 this question about difference between aria-own and aria-controls .
但是,屏幕阅读器支持非常不一致,即使支持,最终也很少被屏幕阅读器用户了解和使用。 因此,此外,像您建议的那样在明文中添加精度总是好的。 “其他原因(请在下面说明)”。在复选框的标签中添加该指示是一个不错的选择。 无论如何,这种增加的精度永远不会对任何人造成伤害,所以你没有理由不这样做。
关于用户体验设计的回答
如果您添加了精度“请在下面解释”,则根据复选框启用文本区域确实没有问题。 简而言之,确保文本区域按 Tab 键顺序位于启用复选框之后,以确保用户不会错过它,也不需要来回填写它。 除非你有一个奇怪的设计,否则通常应该是这样。
另一种选择,在输入原因时自动选中复选框同样没有问题,但您在执行此操作时需要更加小心:
- 不要选中聚焦文本区域的复选框,否则纯键盘用户会在不想要的时候触发它,甚至普通用户也可能点击文本区域然后改变主意
- 不要选中在文本区域中输入字符时的复选框。这可能是一个坏主意,因为我可能会开始输入一些内容,最后清除所有内容并改变主意
当文本区域非空时失去焦点时,选中复选框怎么样?
您可以选择显示一个 snackbar 或类似的东西,并使用 aria-live=polite,告诉您该复选框已被自动选中,因为您已经输入了某些内容。 这种对自动修改的内容的奖励指示在更复杂的形式中将非常有用,但对于您此处介绍的情况,它完全是多余的,因为关系很明显。
关于javascript - 可访问性 - 分组复选框,其中一个复选框具有相关的文本区域,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/67406894/