RE: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

John,

Verification of whether an ARIA role is being used properly by an author, whether it is for “Password”s or other ARIA roles, seems beyond the scope of the specification.  The specification and authoring practices guide should define where the role should be used and if “password” is a special case where it should not be used.

People who want to “fool” screen reader users into giving up their passwords will find ways to do it with or without role=password.

The main question I believe the working group needs to determine is if there is a compelling use case for role=password that will be beneficial to assistive technology users.

Jon




From: John Foliot [mailto:john.foliot@deque.com]
Sent: Tuesday, March 29, 2016 2:49 PM
To: Gunderson, Jon R <jongund@illinois.edu>
Cc: Rich Schwerdtfeger <richschwer@gmail.com>; ARIA Working Group <public-aria-admin@w3.org>; Léonie Watson <tink@tink.uk>
Subject: Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions


Hi Jon,

I agree. The concern though is one of trust: non-sighted users are trusting their browser and AT to be accurate here.

Allowing authors to add a role that suggests some form of security, without that security being implemented at the browser/AT level, means those users have to trust the page author when they 'wisper' to the non-sighted user "ya, this is secure", when, in fact, it may not be. Simply having a special role that does nothing more than suggest it's secure does nobody any favors. You could just as easily use aria-label="password field" and be equally secure (or non-secure, as the case may be).

In other words, if we are looking to establish a generic password labelling mechanism, we need to ensure it also meets ALL of the expected security & privacy requirements already know to be associated with that input type; we must ensure it is indeed a password field in more than name alone.

JF
On Mar 29, 2016 9:46 AM, "Gunderson, Jon R" <jongund@illinois.edu<mailto:jongund@illinois.edu>> wrote:
+1

I think we need to remember that ARIA describes the user interface, it does not define the user interface.

If there are user interface components that are not being defined by native semantics of the markup language, we need to make sure we have the vocabulary in ARIA to accurately describe them to assistive technologies.

Jon


From: Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>
Date: Monday, March 28, 2016 at 5:24 PM
To: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>
Cc: Léonie Watson <tink@tink.uk<mailto:tink@tink.uk>>, ARIA Working Group <public-aria-admin@w3.org<mailto:public-aria-admin@w3.org>>
Subject: Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions
Resent-From: <public-aria-admin@w3.org<mailto:public-aria-admin@w3.org>>
Resent-Date: Monday, March 28, 2016 at 5:25 PM

John,

First, authors are already creating these custom password fields to say that they must behave exactly like an HTML5 password field does not make any sense. The Microsoft security people stated that people were doing this already and adding a password role does absolutely nothing to stop them from doing so.

The far bigger security issue is that despite the fact that they are creating one of these custom fields we give the author zero vehicle to tell the screen reader to not ECHO the keyboard keys being type for all to hear in the room. They don’t echo the keys you actually see which are obscured. they echo the text typed coming in from the keyboard.

What is your solution to prevent this? Yelling at them to use HTML5 passwords is like our shouting at the moon.

I want to see a real solution here.

Where are we asking a browser to change their UI? Browser vendors have been very clear to tell us that we cannot require them to change their UI based on ARIA. On this I see no win although I agree with you that it would be could here.

So, the net of this if we don’t include the role we continue to leave users exposed with a security hole where everyone can hear the password they are typing unless they happen to have a headset on. Is that what you both want?


Rich Schwerdtfeger



On Mar 28, 2016, at 5:02 PM, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:

Hi Rich,

After chatting with some folks at CSUN, I share Leonie’s concerns. Unless all of the browser vendors and screen readers are going to programmatically treat the role=”password” *EXACTLY* like input type=”password” I too see a serious security/privacy concern.

For example, what should we expect with this piece of code: <input type=”text” role=”password”>?

Will screen readers announce “star, star, star” while displaying “Secret PIN #” in the text field, in the clear and open?  (Saying they shouldn’t do that  isn’t enough, I just did it and so others will as well)

Likewise for a scripted input, perhaps something like <div class=”Input_Field” role=”password”>: how do we guarantee end users that the scripted input *is* being treated like an actual password input, and isn’t a fishing spoof on non-sighted users? Companies like IBM would likely never do that, but IBM isn’t the only folks writing code out there :D
I also understand that this is needed for SVG, so my concern is not that we need a “something”, but rather, again, we’re asking browser vendors to change their UI based upon an ARIA attribute, something that they have refused to do in the past, as for example here: https://lists.w3.org/Archives/Public/public-pfwg/2015Sep/0172.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.w3.org_Archives_Public_public-2Dpfwg_2015Sep_0172.html&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=1w9fKJ90Q72BfJcicRnjut5eLAWlU_yn59jGkmN5Shw&s=kBYiYBeEhlFLJMBKysR-3pNeallXtF0f9bf022wr6oA&e=>

JF

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Monday, March 28, 2016 5:37 PM
To: Léonie Watson <tink@tink.uk<mailto:tink@tink.uk>>
Cc: ARIA Working Group <public-aria-admin@w3.org<mailto:public-aria-admin@w3.org>>
Subject: Fwd: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

Leonie,

Did my response address your concern? Microsoft confirmed that people were creating their own custom passwords in the wild and there is no ARIA role to indicate to the AT that this is a password and to tell the AT to NOT echo the password text as you type it. This would facilitate that.

Rich


Rich Schwerdtfeger



Begin forwarded message:

From: Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>
Subject: Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions
Date: March 20, 2016 at 3:59:23 PM CDT
To: tink@tink.uk<mailto:tink@tink.uk>
Cc: ARIA Working Group <public-aria-admin@w3.org<mailto:public-aria-admin@w3.org>>

Leonie,

On the other hand, a screen reader could announce the characters being typed and not know to not do that. Furthermore, people are creating these things today and there is no way to know that the textfield is a password field. Would you prefer to not know?

I don’t understand how your statement supports your argument. Incidentally,we did vet this with the Microsoft browser security people before agreeing to add it to the spec. Microsoft stated that people were creating their own password textbooks in the wild and there is no way for you to know that is what the textfield is.

Rich

Rich Schwerdtfeger



On Mar 17, 2016, at 3:06 PM, Léonie Watson <tink@tink.uk<mailto:tink@tink.uk>> wrote:

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: 17 March 2016 19:12
To: ARIA Working Group <public-aria-admin@w3.org<mailto:public-aria-admin@w3.org>>
Subject: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

This is a Call for Consensus (CfC) to the Accessible Rich Internet Applications (ARIA) Working Group on the following resolution:

1. Accept Joanie’s addition of a new password addressing Action 2004:

https://rawgit.com/w3c/aria/password-role/aria/aria.html#password<https://urldefense.proofpoint.com/v2/url?u=https-3A__rawgit.com_w3c_aria_password-2Drole_aria_aria.html-23password&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=1w9fKJ90Q72BfJcicRnjut5eLAWlU_yn59jGkmN5Shw&s=WUvBIW67n83zMbAdjWRXpN1HmzrlpdHfFokjNRUOW2E&e=>

I object to the password role. Unless I’m missing something, it leaves open the possibility that an AT will behave as though the characters input into the field are obscured, when visually they may not be. A screen reader user cannot be certain that their password is adequately protected from being observed.


Léonie.

--
@LeonieWatson tink.uk<https://urldefense.proofpoint.com/v2/url?u=http-3A__tink.uk_&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=1w9fKJ90Q72BfJcicRnjut5eLAWlU_yn59jGkmN5Shw&s=MZjteGW30Rcig74Q0Hkl33BCUrxgvMUIpPOZXqHqsAM&e=> Carpe diem.