W3C home > Mailing lists > Public > public-aria@w3.org > January 2016

RE: aria-ISSUE-1005: Consider password role [ARIA 1.1]

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>
Message-ID: <01d301d151d5$7bf5b840$73e128c0$@tink.uk>
> From: James Craig [mailto:jcraig@apple.com]
> Sent: 18 January 2016 07:19
> I am reluctant due to potential security implications. I think this
> should be shuttled through the security interest groups before the branch
> merged into the main draft.


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

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?


@LeonieWatson tink.uk Carpe diem
Received on Monday, 18 January 2016 09:50:35 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:18 UTC