JavaScript可访问性实验失败的教训

Photo credit: daveynin

照片来源：daveynin

It’s quite common for password fields to have a “Show Password” function — a checkbox or button which temporarily converts the field to plain text, so that users can see the password they’re typing.

密码字段具有“显示密码”功能是很常见的—复选框或按钮可将字段临时转换为纯文本，以便用户可以看到他们输入的密码。

However it occurred to me that this might not be secure for screenreader users, because a person who’s blind might not know if someone else is looking at their screen (for example, in a semi-public space such as an office or conference room).

但是我想到这对于屏幕阅读器用户可能并不安全，因为盲人可能不知道别人是否在看他们的屏幕(例如，在办公室或会议室等半公共场所)。

Password fields are obfuscated for screenreaders just as they are visually — the screenreader will say star or similar for each typed letter, rather than announcing the letter itself. Just as it is for sighted users, the screenreader user has no interactive feedback to confirm that they’ve typed their password correctly.

屏幕阅读器的密码字段与视觉上一样模糊不清-屏幕阅读器将为每个键入的字母说星号或类似字母，而不是宣布字母本身。 就像有视力的用户一样，屏幕阅读器用户也没有交互式反馈来确认他们是否正确输入了密码。

So I wanted to explore the possibility of scripting this functionality, so that a screenreader user could hear what they’re typing while the field remains visually obfuscated. Then a user who’s listening with earphones would have the security of knowing that their password is not being revealed to anyone around them.

因此，我想探讨编写此功能脚本的可能性，以便屏幕阅读器用户可以在视野模糊的情况下听到他们正在键入的内容。 这样，使用耳机收听的用户便可以安全地知道自己的密码没有泄露给周围的任何人。

It didn’t work!

没用！

But along the way, I was reminded of some home truths about accessible JavaScript, and of an unfortunate problem with ARIA live regions which has wider implications for accessible scripting in general.

但是一路上，我想起了一些有关可访问JavaScript的家庭常识 ，以及关于ARIA活动区域的一个不幸问题，该问题通常对可访问脚本有更广泛的影响。

第一个原型 (The First Prototype)

The basic idea I had in mind was quite simple: an element with aria-live="assertive" would be added to the page, then whenever the password field was edited, its value would be copied to that element. Since it’s a live region, the new value would be immediately announced by screenreaders, but it would also be hidden with off-left positioning and wouldn’t be in the tab order, so it wouldn’t be otherwise apparent.

我想到的基本思想很简单：将带有aria-live="assertive"的元素添加到页面，然后每当编辑密码字段时，它的值就会复制到该元素。 由于它是一个实时区域 ，因此新值将由屏幕阅读器立即宣布，但它也将以左偏位置隐藏，并且不会按Tab键顺序显示，因此在其他情况下不会很明显。

Here’s the code for that (or view the first prototype on its own page):

这是该代码(或在自己的页面上查看第一个原型 )：

If you’re using an ARIA-supporting screenreader, the Hear Password button should enable this functionality and immediately speak whatever value is already in the field. Then while it remains enabled, the screenreader will announce the value as it’s typed (as well as saying star).

如果您使用的是支持ARIA的屏幕阅读器，则“ 听到密码”按钮应启用此功能并立即说出该字段中已有的任何值。 然后，当它保持启用状态时，屏幕阅读器将在键入值时宣布该值(并说出star )。

If you’re not using a screenreader, you won’t hear anything. Although it would be possible to implement direct text-to-speech using something like meSpeak.js, I don’t think that’s a good idea — because anyone who needs this functionality already has a screenreader.

如果您不使用屏幕阅读器，则听不到任何声音。 尽管可以使用诸如meSpeak.js之类的文字直接进行语音转换 ，但我认为这不是一个好主意-因为任何需要此功能的人都已经拥有屏幕阅读器。

More to the point, they have a screenreader in which they control the voice and speech rate; external TTS would just get in the way.

更重要的是，他们有一个屏幕阅读器，可以在其中控制语音和语速 ； 外部TTS只会给您带来麻烦。

The following video demonstrates what a screenreader user would experience (using Firefox + NVDA):

以下视频演示了屏幕阅读器用户的使用体验(使用Firefox + NVDA)：

Now one problem that’s immediately obvious is that copying the whole value to a live region means that the value is treated as a word; each time the user types a letter, the entire value is announced, rather than just the letter they typed. This is quite different from the behaviour of a standard text field, where the spoken feedback tells you the individual letters as they’re typed.

现在，一个显而易见的问题是，将整个值复制到活动区域意味着将该值视为一个单词。 每次用户键入字母时，都会宣布整个值，而不只是宣布他们输入的字母。 这与标准文本字段的行为完全不同，在标准文本字段中，语音反馈会告诉您键入各个字母。

In that example I typed a password that could be interpreted as a word, but what if the value is more convoluted, something like "NCC-1701"? Well, in that case NVDA will says n c c one thousand seven hundred and one, which is problematic for another reason: it didn’t tell us that the first three letters were capitals rather than lower-case, and it didn’t announce the dash at all. The situation is slightly better in Jaws, which does speak the dash, but it still doesn’t mention the capitals.

在该示例中，我键入了一个可以解释为单词的密码，但是如果该值更难以理解(例如"NCC-1701"怎么办？ 好吧，在那种情况下，NVDA会说ncc 011 ，这是有问题的另一个原因：它没有告诉我们前三个字母是大写字母，而不是小写字母，并且它没有宣布破折号完全没有 大白鲨的情况略好一些，虽然确实有些破折号，但仍然没有提及首都。

This is a pretty fundamental problem. If your password happens to be a single lowercase word, then this solution would work quite well, but if it’s a mixture of special characters, then you might not get to hear the whole password at all. You might, for example, think that you typed "ncc1701" rather than "NCC-1701", and the difference is obviously significant when we’re verifying a password!

这是一个非常基本的问题。 如果您的密码恰好是一个小写单词，那么此解决方案将非常有效，但是如果混合使用特殊字符，则可能根本听不到整个密码。 例如，您可能会认为您键入的是"ncc1701"而不是"NCC-1701" ，当我们验证密码时，区别显然很明显！

And that’s not even a particular difficult example. What if your password was something complex like "goHuE&-A" — NVDA would pronounce that as go hooey and a, which is really not helpful at all! Or what if your password was something like "gate", but you actually typed "gaite" — the spoken feedback would be exactly the same in both cases.

这甚至不是一个特别困难的例子。 如果您的密码很复杂，例如"goHuE&-A" ，NVDA会将其发音为go hooey和a ，那真的没有任何帮助！ 或者，如果您的密码类似于"gate" ，但您实际上输入的是"gaite" ，则两种情况下的语音反馈都将完全相同。

第二原型 (The Second Prototype)

Maybe we could improve this by providing more detailed feedback. Instead of speaking the whole value whenever the value changes, we could speak the individual letters in response to keypress events.

也许我们可以通过提供更详细的反馈来改善这一点。 代替在值更改时说出全部值，我们可以对keypress事件做出响应而说出各个字母。

Here’s the modified code for that approach (or view the second prototype on its own page):

这是该方法的修改代码(或在其自己的页面上查看第二个原型 )：

And here it is being used in Firefox + NVDA:

这是在Firefox + NVDA中使用的：

In one sense it’s better, since it provides more detailed feedback as you’re typing, but in another sense it’s worse, because it limits your input speed. Each letter still says star before it speaks the actual character, so you have to wait for that to happen in order to hear the character; if you type more quickly, then you don’t hear any of the letters until you’ve stopped, at which point you only hear the last one (as demonstrated in the video).

从某种意义上说，这是更好的选择，因为它可以在您键入时提供更详细的反馈，但在另一种情况下，则更糟，因为它会限制输入速度。 每个字母在说出实际字符之前仍然说星号 ，因此您必须等待它发生才能听到字符； 如果您输入速度更快，则直到停止前您都不会听到任何字母，此时您只会听到最后一个字母(如视频中所示)。

So all this updated prototype does is solve one problem by creating a different one.

因此，此更新后的原型所做的全部工作就是通过创建另一个原型来解决一个问题。

没有更多的原型！ (No More Prototypes!)

Maybe there are ways we can improve it. Perhaps we could split the value by spaces, for example, to output "h e l l o" instead of "hello", so that the individual letters are spoken instead of the whole word. That would work for letters, but it wouldn’t address the problem of not speaking capitals or punctuation, and would only compound the problem with passwords that contained spaces.

也许有一些方法可以改善它。 也许我们可以用空格将值分开，例如，输出"hello"而不是"hello" ，以便说出单个字母而不是整个单词。 这对于字母是有效的，但是它不能解决不讲大写字母或标点符号的问题，只会使包含空格的密码更加复杂。

In any case, we’re well into the realms of ugly hacking now! Sometimes, it gets to the point where more hacking just leads to more hacking, and we have to step back from what we’re doing, and ask — was the whole thing a bad idea? Unless we can make it respond just like a regular plain text field, we’re never going to have an intuitive solution.

无论如何，我们现在已经进入了骇客入侵的境界！ 有时，到了更多的黑客攻击只会导致更多的黑客攻击的地步，我们必须退一步，然后问-整件事是个坏主意吗？ 除非我们能够像普通的纯文本字段一样使它响应，否则我们将永远不会有一个直观的解决方案。

And as watchwords go, that’s pretty useful. If we can’t create an intuitive solution — if the only way to do something is to endlessly hack around the minutiae of a kludgy solution — then maybe it wasn’t worth doing in the first place.

随着流行语的发展，这非常有用。 如果我们不能创建一个直观的解决方案 -如果做某件事的唯一方法是无休止地破解一个笨拙的解决方案的细节-那么也许一开始就不值得这样做。

这是活的吗？ (Is This Thing Live?)

But there’s a bigger problem to contend with that makes it all rather irrelevant, which is that it doesn’t works in IE + Jaws; since that’s the most popular combination, failing to work there is a pretty big deal.

但是还有一个更大的问题要解决，那就是使它变得毫无意义，因为它在IE + Jaws中不起作用 。 由于这是最流行的组合 ，因此无法正常工作很重要。

Here’s the first prototype again being used in IE + Jaws:

这是IE + Jaws中再次使用的第一个原型：

You can see how pressing the Hear Password button simply announces the updated state of the button, it doesn’t read the value in the live region. The reason for this comes down to the behaviour of aria-live="assertive".

您可以看到按下“ 听到密码”按钮是如何简单地宣布按钮的更新状态，而不读取活动区域中的值。 其原因归结为aria-live="assertive"的行为。

The aria-live attribute has three possible values, that determine how assertive the message should be:

aria-live属性具有三个可能的值，这些值确定消息应具有的断言：

• "off" means the change in content is not announced.

  "off"表示未宣布内容更改。

• "polite" means the change should only be announced when the user is idle (i.e. waiting until the screenreader stops whatever it’s speaking at the time)

  "polite"是指仅当用户空闲时(即等到屏幕阅读器停止当时正在说的一切)时，才应宣布更改

• "assertive" means the change should be immediately announced (i.e. interrupting whatever the screenreader is speaking at the time)

  "assertive"表示应立即宣布更改(即中断屏幕阅读器当时正在讲话的内容)

But recently, Russ Weakley and I did some testing with ARIA live regions in preparation for a forthcoming Learnable course, and what we discovered is so significant that it deserves a bold paragraph all on its own:

但是最近， Russ Weakley和我与ARIA居住区进行了一些测试，为即将推出的可学习课程做准备，我们发现的内容是如此重要，以至于它值得一个大胆的段落：

Assertive live regions are not usually assertive.

断断续续的生活区域通常不那么有主见。

In other words, most browser/screenreader combinations don’t actually honour the "assertive" value, they treat it the same as "polite". Specifically — only VoiceOver with Chrome or Safari will actually interrupt the user to announce an assertive message; all other tested combinations (including NVDA or Jaws with any browser) won’t announce it until the screenreader is silent.

换句话说，大多数浏览器/屏幕阅读器组合实际上并不尊重"assertive"值，而是将其与"polite"相同。 具体来说-只有安装了Chrome或Safari的VoiceOver才会实际打断用户宣布断言消息； 在屏幕阅读器保持静音之前，所有其他经过测试的组合(包括NVDA或带有任何浏览器的Jaws)都不会宣布它。

What we have in these prototypes then, is an assertive region being treated as polite. The value did get announced in Firefox + NVDA because clicking the Hear Password button doesn’t trigger anything else — NVDA doesn’t read the updated button text, and since nothing else is being spoken, a polite message can be announced. However in IE + Jaws, clicking the button does cause it to read the updated button text, which means that the reader is not idle, and therefore the live region isn’t announced.

这样，我们在这些原型中所拥有的就是一个自信的区域，被视为礼貌。 确实在Firefox + NVDA中宣布了该值，因为单击“ 听到密码”按钮不会触发其他任何事件-NVDA不会读取更新的按钮文本，并且由于没有其他内容在讲，因此可以宣布礼貌的消息。 但是，在IE + Jaws中，单击按钮确实会导致它读取更新的按钮文本，这意味着阅读器不处于空闲状态，因此不会宣布活动区域。

结论 (Conclusion)

None of this should be taken as a reason for not implementing standard Show Password functionality (i.e. that simply switches the field type). Those solutions can be accessible to screenreaders, the only concern is the potential security/privacy risk they present.

所有这些都不应被视为未实现标准“ 显示密码”功能的原因(即，仅切换字段类型)。 屏幕阅读器可以访问这些解决方案，唯一需要关注的是它们带来的潜在安全/隐私风险。

But if the alternative is not to provide any means for any users to see their password, then it’s arguably better to do that, than to do nothing. (Though there might be a usability case for saying that password fields simply shouldn’t be masked at all, but such questions are beyond the scope of this article.)

但是，如果替代方案是不为任何用户提供任何查看密码的手段，那么这样做总比什么都不做要好。 (尽管可能有一个可用性案例，说根本不应该屏蔽密码字段，但是这些问题不在本文讨论范围之内。)

We could perhaps mitigate the risk by explaining it for screenreader users, which we can do by adding aria-label to the triggering button. When a button or link has aria-label, a screenreader will speak the label text instead of the element’s content — so it must at least contain the same information, but can also have supplementary information that’s only relevant for screenreader users (and this technique has a whole variety of uses):

我们也许可以通过向屏幕阅读器用户进行解释来降低风险，我们可以通过在触发按钮上添加aria-label来做到这一点。 当按钮或链接具有aria-label ，屏幕阅读器将说出标签文本， 而不是元素的内容-因此它必须至少包含相同的信息，但也可以具有仅与屏幕阅读器用户相关的补充信息(此技术具有用途广泛 )：

<button aria-label="Show password as plain text. Note: this will visually expose your password on the screen.">
  Show Password
</button>

Ultimately though, what’s important to take from this experiment is a basic truth about accessible scripting: if it can’t solve a problem in a usable and intuitive way, then it hasn’t solved the problem.

最终，从这个实验中获取的重要信息是有关可访问脚本的基本事实： 如果它不能以可用的直观方式解决问题，那么就不能解决问题 。

Accessibility is not an exercise in meeting abstract checks, it’s about improving usability for people with specific needs. So a solution that’s technically accessible but is not usable for these groups of users, can’t really be considered accessible at all.

可访问性不是满足抽象检查的一种练习，它是关于提高有特定需求的人的可用性 。 因此，从技术上来说可访问但对于这些用户组不可用的解决方案，根本无法真正视为可访问。

翻译自: https://www.sitepoint.com/show-password-javascript-accessibility/