Re: Objection to password role

JF wrote:

> I asked for, and got, strong warning language around the use of this role
value, and I accept the use-cases that have been brought forward in support
of this role value (despite the fact we've *still* not seen an actual
example of one) *and I will not impede progress of the ARIA spec over
this. *

No no no no no... don't try and pin this on me - this time it was Michiel
and James Craig ("This is a fairly damning amount of evidence.
<https://lists.w3.org/Archives/Public/public-aria/2016Jun/0115.html>") that
returned to the list with comments.  Rich, my concerns for the most part
have been heard, and addressed with the warning language. Whether you think
Marco Zehe's and Sina Bahrm's opinion (via twitter) have value or not is up
to you - we are trying to get to CR and then Rec according to a timeline,
and you want to meet that timeline. I respect that, and have stated as much
multiple times now.

What however, are you going to do if you start getting a lot of public
comments over this during CR? What are you going to say and do if Marco and
Sina both file comments as part of the CR process? Get mad and say that
we've already answered these questions? And while you state we've already
addressed all the issues, as late as last week's ARIA call there were 2
open Action items against this topic that have not been closed, and so I
will respectfully submit that stating this is "finished" is a bit premature
today.

You have stated that IBM is assisting Freedom Scientific to get this
implemented, and Joanie is working on this for ORCA, but that still leaves
at least 3 Operating Systems (not User Agents; *Operating Systems*) with *no
implementation* (Android, iOS, MacOS) which still concerns me, and should
concern you too given that this means zero coverage for mobile devices, and
I've not seen any evidence or indication that this Working Group has taken
a single step in engaging with other SR vendors to communicate what will be
expected of them (which as I recall was a condition of the CfC - "...include
the password role in the ARIA 1.1 editor’s draft, *subject to security and
AT feedback*." -
https://lists.w3.org/Archives/Public/public-aria-admin/2016Apr/0030.html -
those were your exact words, which I took at face value then, and now).

I have already agreed to keep working on this, and to take it out for wider
review in the CR - I voted positively on your CfC that stated this was what
we were going to do; I stand by that indication today, and I have already
noted with appreciation that the Warning text was added. My hope and
expectation is that during that wider review we *will* get feedback from
other Screen Reader vendors, as well as a more formal review from Security
Experts as part of the W3C Process - but be very clear, I have given this
over to W3C Process and I am not fighting you on this.

> I made a suggestion about the mapping to indicate that it was a custom
password. I would like to hear a response. That is equivalent to exposing a
different role so the user knows it is not a standard HTML password which I
add again is not entirely secure.

I would support that going forward, as an improvement over the status quo.

JF

On Tue, Jun 21, 2016 at 4:34 PM, Richard Schwerdtfeger <richschwer@gmail.com
> wrote:

> We are still discussing the issue because the same people keep bringing up
> what has already been discussed. This is what happened with longdesc. I
> don’t want to rehash old issues that have been addressed.
>
> Marco’s tweet has no substance that anyone can action on.
>
> What I am becoming increasingly concerned about is that no matter how much
> this group invests in addressing the issues that the same group of people
> will just throw in another roadblock to try to not see it in even if there
> is not additional information provided. We are trying to work with you John
> but that will not fly here. Mozilla is a member of this working group and
> they have had more than ample opportunity to come to this group and raise
> technical concerns. This has been discussed for once.
>
> I made a suggestion about the mapping to indicate that it was a custom
> password. I would like to hear a response. That is equivalent to exposing a
> different role so the user knows it is not a standard HTML password which I
> add again is not entirely secure.  The fact that it claims to be secure is
> a fallacy as Jason indicates. Perhaps I should raise a formal objection to
> HTML 5.1 as password is still not totally secure in browsers. I could add
> that there should be HTML 5.1 text that says that browsers, like Firefox,
> should not expose a mean for a user to get access to the value. One thing
> the custom password field has is that it is not as easily retrieved.
>
> Rich
>
> On Jun 21, 2016, at 3:49 PM, John Foliot <john.foliot@deque.com> wrote:
>
> Hi Jason,
>
> > *a screen reader user can distinguish <input type=”password”> by how
> the assistive technology handles it*
>
> Actually, it was Joanie who indicated the difference in behavior, not I.
> My concern is as much around human behavior, and learned assumptions over
> time.
>
> > *to the extent that they make these assumptions now, [users] will have
> to learn not to make them.*
>
> Problem statement right there.
>
> Jason, while I respect that this may not seem to be a serious issue to
> you, and how you use the web today, I will also note in passing that there
> is an increasingly long list of known daily screen reader users who are all
> chiming in with their concerns over this as well. (Here's one:
> https://twitter.com/MarcoInEnglish/status/743680877444497408)
>
> I asked for, and got, strong warning language around the use of this role
> value, and I accept the use-cases that have been brought forward in support
> of this role value (despite the fact we've *still* not seen an actual
> example of one) and I will not impede progress of the ARIA spec over this.
>
> None-the-less, the fact that we are still discussing this issue, and that
> others are now starting to also express concerns, tells me that there still
> may be some work to be done here - and that is an observational statement
> and nothing more.
>
> JF
>
> On Tue, Jun 21, 2016 at 2:10 PM, White, Jason J <jjwhite@ets.org> wrote:
>
>>
>>
>>
>>
>> *From:* John Foliot [mailto:john.foliot@deque.com <john.foliot@deque.com>]
>>
>> *Sent:* Tuesday, June 21, 2016 2:34 PM
>>
>> The problem with "password" is that for over 20+ years of the internet,
>> the idea of a password field has earned some presumed security and privacy
>> features that you often don't think about - certainly not actively. For
>> example, if you type a character string into an input type="password", you
>> cannot then highlight and copy what is rendered on screen, and paste it
>> into a text editor to see the string - it will copy and paste as "stars".
>> That's just one example, there are others (for example "...browsers are
>> likely to save the value for autocomplete  unless they explicitly recognise
>> the role as defining a real password  field.” - Chaals McCathieNevile
>> (Yandex) -
>> https://lists.w3.org/Archives/Public/public-aria/2016Apr/0054.html.)
>>
>>
>>
>> *[Jason] So the argument is supposed to be that a screen reader user can
>> distinguish <input type=”password”> by how the assistive technology handles
>> it, from custom password widgets, thus having an advantage that the non-AT
>> user lacks. Then we’re supposed to believe that such screen reader users go
>> on to make certain assumptions that may or may not hold. I appreciate
>> John’s setting out this position. I don’t find it convincing since I think
>> such users, to the extent that they make these assumptions now, will have
>> to learn not to make them.*
>>
>>
>>
>> *The situation is no different from that of a password field in a desktop
>> or mobile application, which for all the user knows could be a widget
>> provided by the platform or a custom widget supplied by the application
>> that behaves in subtly different ways. Thus the ARIA proposal simply brings
>> the Web use case into line with desktop and mobile applications (where, to
>> the best of my knowledge, it’s possible to write a custom password widget
>> and to make it accessible to screen reader users by declaring it in the
>> accessibility API).*
>>
>>
>>
>> *If it’s a choice between this group’s declining to make custom password
>> widgets accessible, and not alerting the user to the possibility that the
>> application author may have violated certain assumptions, then my vote is
>> strongly in support of making the custom fields accessible – and more
>> secure by suppressing keyboard echo. That is, while I think John has well
>> articulated an objection, I’m not persuaded that it’s a good case for
>> changing this group’s position regarding the password role, namely, that it
>> should be included in ARIA.*
>>
>>
>>
>> *Note also that the very act of deciding to enter sensitive information
>> into a field requires a certain elvel of trust in the security of the
>> application. If I knew I were confronted with a custom widget rather than
>> an <input type=password” would I have an additional, substantial reason not
>> to enter sensitive password text into it? My answer is: “probably not”, or
>> at best, “not much”. The decision would be dominated by my other reasons to
>> entrust (or not to entrust) the application with sensitive information. I
>> don’t think knowing whether a password field is custom or not is
>> significantly going to affect anybody’s decision about whether to enter
>> password text into it; and that’s the important choice to be made by the
>> user in this context.*
>>
>>
>>
>> ------------------------------
>>
>> This e-mail and any files transmitted with it may contain privileged or
>> confidential information. It is solely for use by the individual for whom
>> it is intended, even if addressed incorrectly. If you received this e-mail
>> in error, please notify the sender; do not disclose, copy, distribute, or
>> take any action in reliance on the contents of this information; and delete
>> it from your system. Any other use of this e-mail is prohibited.
>>
>> Thank you for your compliance.
>> ------------------------------
>>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion