画外音和屏幕读取器：如何编码无线电按钮
我在iPad上使用Voiceover/Chrome来测试我正在开发的页面上的可访问性是否有效。我将蓝牙键盘连接到iPad，然后单击“选项卡键”以浏览页面上的元素。该页面上使用的以下代码可与VoiceOver一起使用：
<div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="0" aria-labelledby="q1015678-2430294-button"> <span id="q1015678-2430294-button">Good</span>
</label>
</div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="1" aria-labelledby="q1015678-2430295-button"> <span id="q1015678-2430295-button">Bad</span>
</label>
</div>
</div>
但是，当我在Windows上使用屏幕读取器/Chrome时，上面的代码发音为“良好”，然后说“好，无线电按钮”。在两个选择中，对于另一个“不良”单选按钮也是如此。
编码无线电和屏幕阅读器工作的无线电按钮的正确方法是什么？
更新
这是测试中使用的HTML。配音未能发现在V2和V3中编码的按钮。它可以正确识别和发音“此开始”，v1中的按钮和“这是终点”。
我能够用左/滑动手势浏览所有按钮。问题是使用键盘上的“选项卡键”将选项卡通过按钮。 iPad上的iOS为15.4.1。
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<form>
<div tabindex="0" role="text">this is the beginning</div>
<div>-----------v1------------</div>
<div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="0" aria-labelledby="q1015678-2430294-button"> <span
id="q1015678-2430294-button">Good</span>
</label>
</div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="1" aria-labelledby="q1015678-2430295-button"> <span
id="q1015678-2430295-button">Bad</span>
</label>
</div>
</div>
<div>----------v2-------------</div>
<div>
<div class="radio">
<label for="q1015678-2430294-button2">
<input type="radio" name="ddd" value="0" id="q1015678-2430294-button2"> <span>Good 2</span>
</label>
</div>
<div class="radio">
<label for="q1015678-2430295-button2">
<input type="radio" name="ddd" value="1" id="q1015678-2430295-button2"> <span>Bad 2</span>
</label>
</div>
</div>
<div>-----------v3------------</div>
<div>
<label for="xyz1">radio button 1</label>
<input type="radio" id="xyz1" />
</div>
<div>
<label for="xyz2">radio button 2</label>
<input type="radio" id="xyz2" />
</div>
<div>-----------------------</div>
<div tabindex="0" role="text">this is the end</div>
</form>
</body>
</html>
如果我将以下文本框放在表单中，则配音可以通过页面上的元素正确发音。
<textarea name="ta">This is textarea</textarea>
更新3
在我对V1的测试（原始代码）中，Spacebar能够在Safari和Chrome中激活我iPad上的单选按钮。
I use VoiceOver/Chrome on a iPad to test whether accessibility works on a page I am developing. I connect a Bluetooth keyboard to the iPad and click on the Tab key to go through elements on the page. The following code used on the page works with VoiceOver:
<div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="0" aria-labelledby="q1015678-2430294-button"> <span id="q1015678-2430294-button">Good</span>
</label>
</div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="1" aria-labelledby="q1015678-2430295-button"> <span id="q1015678-2430295-button">Bad</span>
</label>
</div>
</div>
However, when I use Screen Reader/Chrome on Windows, the above code pronounces "Good Good" before saying "Good, radio button". The same goes for the other "Bad" radio button when tabbing through the two choices.
What is the proper way of coding radio buttons that works with both VoiceOver and Screen Reader work?
Update
This is the HTML used in the test. VoiceOver fails to discover buttons coded in v2 and v3. It can identify and pronounce correctly "This the beginning", buttons in v1, and "This is the end".
I was able to tab through all buttons with the left/swipe gestures. The problem is to use the Tab key on a keyboard to tab through the buttons. The ios on the iPad is 15.4.1.
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<form>
<div tabindex="0" role="text">this is the beginning</div>
<div>-----------v1------------</div>
<div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="0" aria-labelledby="q1015678-2430294-button"> <span
id="q1015678-2430294-button">Good</span>
</label>
</div>
<div class="radio">
<label tabindex="0">
<input type="radio" name="abc" value="1" aria-labelledby="q1015678-2430295-button"> <span
id="q1015678-2430295-button">Bad</span>
</label>
</div>
</div>
<div>----------v2-------------</div>
<div>
<div class="radio">
<label for="q1015678-2430294-button2">
<input type="radio" name="ddd" value="0" id="q1015678-2430294-button2"> <span>Good 2</span>
</label>
</div>
<div class="radio">
<label for="q1015678-2430295-button2">
<input type="radio" name="ddd" value="1" id="q1015678-2430295-button2"> <span>Bad 2</span>
</label>
</div>
</div>
<div>-----------v3------------</div>
<div>
<label for="xyz1">radio button 1</label>
<input type="radio" id="xyz1" />
</div>
<div>
<label for="xyz2">radio button 2</label>
<input type="radio" id="xyz2" />
</div>
<div>-----------------------</div>
<div tabindex="0" role="text">this is the end</div>
</form>
</body>
</html>
If I put the following textbox in the form, the VoiceOver is able to pronounce it correctly with the tab key tabbing through the elements on the page.
<textarea name="ta">This is textarea</textarea>
Update 3
In my tests of v1 (the original code), the spacebar is able to activate a radio button on my ipad in both Safari and Chrome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
乍一看，您的代码中有两件事看起来很奇怪：
在第一个点的标签内，标签上的tabindex = 0使该标签可集中。但是，标签不应该集中。只有单选按钮应该是，默认情况下是不指定Tabindex的。
这就是为什么您首先访问标签的原因，并且由于您首先访问标签，因此您无法对其做任何事情。
解决方案：从标签中删除Tabindex = 0的
第二点，它可能起作用，但仍然是一个奇怪的结构。
当您需要引用与正常标签不同的标签元件时，必须使用ARIA标签。
＆lt; label＆gt;参考＆lt; input＆gt;element in 属性>属性，则您不需要额外的Aria-labelledby。＆lt; label＆gt;中作为＆lt; input＆gt;时，您也不需要Aria-labelled。＆lt; label＆gt;是实际可访问的标签，则最好切换到另一个更常规的构造，其中＆lt; input＆gt;isn 't在＆lt; label＆gt;中。然后，使用Aria-labelledby时的混乱将减少，如果您希望仍然具有与＆lt; label＆gt;中的标签不同的标签。我希望这足够清楚。我的建议：切换到这样的简单结构：
At a first glance, two things look strange in your code:
For the first point, the tabindex=0 on the label make that label focusable. However, the label isn't supposed to be focusable. Only the radio button should be, and it is by default without specifying tabindex.
This is precisely why you first reach the label by itself, and since you first reach the label by itself, you can't do anything with it.
Solution: remove tabindex=0 from the label
For the second point, it might work, but it's still quite an odd construction.
The aria-labelledby has to be used when you need to reference a labelling element different than the normal label.
<label>references the<input>element in itsforattribute, you don't need an additional aria-labelledby.<label>as the<input>, you don't need aria-labelledby either.<label>be the actual accessible label, you'd better switch to another more conventional construction where the<input>isn't inside the<label>. Then there will be less confusion when using aria-labelledby, if you want still to have a different accessible label than what's inside the<label>.I hope it's clear enough. My advice: switch to a simpler construction like this:
如此答案，激活“完整的键盘访问“选项使无线电按钮可随着标签的规定触及。
我的第一个答案提供有关代码的建议保持有效。
好消息是，我们观察到的不是错误。苹果使它像这样有意。
坏消息是，配音和完整的键盘访问效果不佳。
例如，当打开完整的键盘访问时，我无法再启用/禁用快速导航，并且使用转子遇到了很大的麻烦。其他一些重要的配音功能似乎也受到影响。
作为盲人和配音用户，我真的无法启用完整的键盘访问。
从那里开始，可以推断出，作为屏幕读取器用户，您不应该使用选项卡进行导航。您应该专门使用屏幕读取器特定功能。
在这里，vo手势。
它还表明，实际上，您的测试是错误的：
如果在PC上您可以同时测试这两种情况，则看起来它不在iPhone和iPad上，因为Apple似乎已决定将两种用户完全分开。知道为什么，以及最多的Macintosh会很有趣。
As explained in this answer, activating the "full keyboard access" option make the radio buttons reachable with tab as they normally should.
My first answer giving advice on the code stays valid.
The good news is that what we have observed isn't a bug. Apple made it working like this intentionally.
The bad news is that VoiceOver and full keyboard access aren't playing well together.
For example, when full keyboard access is turned on, I can no longer enable/disable quick navigation, and I have big troubles using the rotor. Several other important VoiceOver functions seem to be affected, too.
As a blind and VoiceOver user, I really can't keep full keyboard access enabled.
From there, one can deduce that, as a screen reader users, you aren't supposed to use tab to navigate. You should exclusively be using screen reader specific functions.
Here, VO gestures.
It also shows that, in fact, your test is incorrectly designed:
If, on a PC, you can test both at the same time, it looks like it's not on iPhone and iPad, because Apple seem to have decided to completely separate the two kinds of users. It would be interesting to know why, and where the most goes the macintosh.