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

This one looks a bit strange to me.
We are kind of reinventing the wheel, plus opening up potential security
risks.
In one of the comments on the original ticket someone suggests the reason we
are inventing an ARIA password role is because authors are reluctant to use
the natively provided password role in the host language.
This is not a problem in HTML, not in my experience, but I can't speak for
other languages.
But I think replicating what should be readily available and highly
encouraged mechanism of the host language, to keep user input data secure,
by offering a password role that authors are sure to mishandle on occasion
(like any other role and attribute) does not match well with the idea that
ARIA is supposed to be used only when the host language semantics fall
short.
If we assign a recommended user agent behavior to the password role, we are
widening the scope of ARIA to force certain functionality, up til now ARIA
has only been a descriptive spec.

I think if we are going down this road, that perhaps it would be better to
have an aria-secure attribute that can be applied to a text input field and,
when present, should trigger the same behavior as a password role.

My $0.02
Cheers
-Birkir

-----Original Message-----
From: Léonie Watson [mailto:tink@tink.uk] 
Sent: Monday, January 18, 2016 4:49 AM
To: 'James Craig' <jcraig@apple.com>; 'Accessible Rich Internet Applications
Working Group' <public-aria@w3.org>
Cc: 'Joanmarie Diggs' <jdiggs@igalia.com>
Subject: RE: aria-ISSUE-1005: Consider password role [ARIA 1.1]

> 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 13:34:25 UTC