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> 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>
> Date: Monday, March 28, 2016 at 5:24 PM
> To: John Foliot <john.foliot@deque.com>
> Cc: Léonie Watson <tink@tink.uk>, ARIA Working Group <
> 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>
> 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> 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
> <richschwer@gmail.com>]
> *Sent:* Monday, March 28, 2016 5:37 PM
> *To:* Léonie Watson <tink@tink.uk>
> *Cc:* ARIA Working Group <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>
> *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
> *Cc: *ARIA Working Group <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> wrote:
>
> *From:* Rich Schwerdtfeger [mailto:richschwer@gmail.com
> <richschwer@gmail.com>]
> *Sent:* 17 March 2016 19:12
> *To:* ARIA Working Group <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.
>
>
>