Re: Slicing and dicing password role discussion

Hi Michael, all.

First of all, I would like to say that Michael deserves a raise.

Regarding the most awesome table (thanks), there is, I believe, another
case: <div role="password" contenteditable />

To be honest, that was what I was assuming would be done by authors who
have a need for their own special input in order to do the obscuring of
characters. Then again, IANAA. :)

In light of the <input type="text" role="password"> scenario, I would
suggest the following:

1. Addition of statement in the ARIA spec that due to security
   concerns, authors MUST NOT apply the password role to the input
   element. If authors do apply the password role to the input element,
   user agents MUST ignore that role so that assistive technologies do
   not incorrectly suggest to the user that input is being obscured.

2. Similar statements wherever else they are applicable (Core AAM?
   HTML AAM? APG?)

--joanie

On 03/31/2016 10:00 AM, Michael Cooper wrote:
> There's a thread on the ARIA admin list about the password role:
> 
> https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/thread.html#msg18
> 
> 
> (Note I think once the discussion got past objecting to the proposed
> consensus, it should have moved to the main working list since it became
> substantive rather than administrative, which is why I'm posting here
> out-of-thread. I'll work separately on mechanisms to ensure that happens.)
> 
> I think there's been an emerging consensus about what should happen in
> an ideal world, but a lot of concern about what might happen in the real
> world if the password role is deployed. Some of those concerns seem to
> me to boil down to, it's great if the right thing happens in response to
> the password role, but disastrous if your tool happens not to support
> it. Almost nobody wants to rely on the author to work around those
> situations, so it really comes down to tool support.
> 
> The problem is, there's a bit of a "can't get there from here"
> situation. If the password role is something authors can use, it will
> probably be in use in the wild before all user agents have started
> supporting it. Therefore authors' use of it could be highly problematic.
> Yet if it isn't something authors use, tools will probably not support
> it. We also have to consider the situation in which we do not provide
> the password role, but authors don't want to use input type=password, so
> they use something completely unsecured - which I think some in the
> thread believe is likely to happen.
> 
> Given that there's no absolutely clear path, I tried to break down the
> different options so we could see least-bad choices. The attached table
> considers 1) what would happen if mainstream user agents support the
> password role (including passing information about it to the AT), 2)
> what would happen if AT support password without relying on features of
> the UA, and 3) what would happen if neither support the role. This is
> explored for input type=password (i.e., what happens now on passwords
> and is broadly implemented), password role on another field, and author
> feature that has no password semantic of any kind. I put emphasis tags
> around aspects that are "bad". I assumed "good" is, from the discussion:
> 1) user knows it's a password field, 2) input is masked on screen, 3)
> input is masked in auditory output, 4) key echo is off so the password
> does not leak to listeners as it's being typed.
> 
> If I got the data right, there's almost no perfect situation. But there
> are some really bad situations - when there is no password semantic, or
> when neither the mainstream UA nor the AT recognize the password
> semantic. Yet if either the UA or the AT recognize the password role,
> things get a lot better (best if both do). There were proposals in the
> thread both for UA requirements (which is normal for ARIA, except some
> of them are for UI requirements which would be exceptional), and for AT
> requirements (which is not normal for ARIA).
> 
> Looking at all this, I think the decision about what to do first comes
> down to whether we believe authors will deploy non semantic password
> inputs if we do nothing, but would mark them with the password role if
> it existed. If we think authors won't try to do this much, it seems best
> to rely on the existing input type=password as that has some of the
> least scary effects. I haven't seen a lot of solid data about that in
> the thread, some believe one way, others the other. Until we get
> consensus on the answer to that question, I think the other discussion
> is peripheral.
> 
> If we do think authors will create their own password inputs in spite of
> a lack of available semantic, then we need the password role. From
> there, the question becomes what can we do to make it most effective in
> the shortest time and with the least problems during the period of
> incomplete implementation? To me, the best choice seems we should
> negotiate an exception to the principle that ARIA does not impact UI,
> and say that because of its security implications, user agents need to
> do input masking on the password role, not just tell the AT about it. If
> that's a no-go, we could see if ATs will agree to broadly expand their
> security of passwords - but we've had difficulty with that sort of thing
> in the past, there are more ATs than mainstream UAs and they don't
> always implement quickly. Either way, I think it's also important to put
> some highlighted best practices for authors saying they should at least
> use the word "password" (language-specific of course) in the accessible
> name so even without tool support users know it's a password field and
> to be extra careful (I don't think we can meaningfully make normative
> author requirements, so has to be best practices). This won't solve
> everything, but it will be a lot better than if we do nothing. I do
> think if authors are taking the time to apply the password role, they
> will see the value in taking the additional step; it's authors who don't
> even care who will create a real problem, but there's nothing anybody in
> W3C can do about that.
> 
> Michael

Received on Thursday, 31 March 2016 15:15:47 UTC