- From: Léonie Watson <tink@tink.uk>
- Date: Mon, 18 Jan 2016 09:49:02 -0000
- To: "'James Craig'" <jcraig@apple.com>, "'Accessible Rich Internet Applications Working Group'" <public-aria@w3.org>
- Cc: "'Joanmarie Diggs'" <jdiggs@igalia.com>
> From: James Craig [mailto:jcraig@apple.com] > Sent: 18 January 2016 07:19 > > I am reluctant due to potential security implications. I think this proposal > should be shuttled through the security interest groups before the branch is > merged into the main draft. +1 I think we need to solve the obfuscation problem before we do though. Otherwise they're likely to ping it straight back as basically insecure. The definition indicates that screen readers might beep as a character is entered into the password field, or "speak each displayed character as it is inserted". As I understand it, the problem is that unless scripted otherwise, there will be no visual obfuscation of those characters on screen. With a host language equivalent like <input type="password">, the characters are obfuscated by the browser and screen readers echo the obfuscated characters as they appear in the field. For example, NVDA in Firefox announces "star" for each character, and they appear as such visually. We could add a strong requirement for developers to script the visual obfuscation, but I don't think that is sufficiently reliable. No visual obfuscation at all is a problem, but it might be worse if we ended up with a situation where a screen reader announced obfuscated characters (based on the role), but the application did not provide the visual equivalent. One solution might be for the browsers to provide the same obfuscation that they do for the host language equivalent? Léonie. -- @LeonieWatson tink.uk Carpe diem
Received on Monday, 18 January 2016 09:50:35 UTC