- From: Fred Esch <fesch@us.ibm.com>
- Date: Wed, 22 Jun 2016 11:48:50 -0400
- To: Michiel Bijl <michiel@agosto.nl>
- Cc: ARIA <public-aria@w3.org>
- Message-Id: <OF4262E9F9.AA665FDB-ON85257FDA.005651A5-85257FDA.0056DE98@notes.na.collabserv.c>
Hi Michiel,
It is a custom password field because you enter your password in it. If you
put the right password in it you advance to the next step. If not you
don't. Do you think the password is sent to the server in a different form
or via a different protocol if it came from the input text vs input
password? If you mask an input for a SSN does that make it password?
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: Michiel Bijl <michiel@agosto.nl>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: ARIA <public-aria@w3.org>
Date: 06/22/2016 11:31 AM
Subject: Re: Objection to password role --- example thread
So how is it a custom password field? A role of password as proposed would
add nothing in the situation shown in the IAAP example.
—Michiel
On 22 Jun 2016, at 17:06, Fred Esch <fesch@us.ibm.com> wrote:
Hi Michiel,
In this example, it does switch to input type="password" when you
want the text obscured.
Regards,
Fred Esch
Watson, IBM,
W3C
Accessibility
<15927898.gif> Watson Release Management and
Quality
<graycol.gif>Michiel Bijl ---06/22/2016 10:31:01 AM---What happens if
you uncheck the “show password” checkbox? Is it still type=text? Or
does it return t
From: Michiel Bijl <michiel@agosto.nl>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: Rich Schwerdtfeger <richschwer@gmail.com>, ARIA <
public-aria@w3.org>
Date: 06/22/2016 10:31 AM
Subject: Re: Objection to password role
What happens if you uncheck the “show password” checkbox? Is it still
type=text? Or does it return to type=password?
—Michiel
On 22 Jun 2016, at 16:20, Fred Esch <fesch@us.ibm.com>
wrote:
Rich,
Here is an screen shot of a custom password (very bottom
of screen shot). This on the checkout for International
Association of Accessibility Professionals (IAAP) when
signing up for a webinar. You can choose to not mask the
password. Using inspector to look at the HTML, the field
is input type="text". Unfortunately, since this is part
of a checkout system, I can't share a usable URL.
<13426391.jpg>
I hope this satisfies folks desire to see an instance of
a custom password. You may have to sign up for an IAAP
webinar or event to see it yourself.
Regards,
Fred Esch
Watson, IBM,
W3C
Accessibility
<13375923.gif> Watson Release Management
and Quality
<graycol.gif>Rich Schwerdtfeger ---06/22/2016 06:33:34
AM---What I am going to do: - ask the group that we mark
password at risk
From: Rich Schwerdtfeger <richschwer@gmail.com>
To: John Foliot <john.foliot@deque.com>
Cc: "White, Jason J" <jjwhite@ets.org>, Michiel Bijl <
michiel@agosto.nl>, ARIA Working Group <
public-aria@w3.org>
Date: 06/22/2016 06:33 AM
Subject: Re: Objection to password role
What I am going to do:
- ask the group that we mark password at risk
- work with browser and ATVs during CR.
- ask James Nurthen to have Oracle point to actual
examples if they can. I think that is fair.
- address the issue of some browser vendors consistently
weighing in late despite the additional time allotted to
review resolutions on the list. This is unacceptable and
disrespectful of other working group members. Seriously,
a tiny tweet from Mozilla is the best they can do? We
have worked for years with Mozilla. That is totally out
of character for them. They have done so much for
accessibility.
Net. We don't have to hold up entering CR if we do these
things. Either it gets implementation or it doesn't.
We need to get to Aria 2 and get SVG on a level playing
field with html to stop people from being left behind.
Far too much time has been spent on a feature that I
think is needed but in the grand scheme of things is
noise.
We need to get to the other things in our charter and we
need some of the limited technical skills we have to
boost that CSS task force effort which, to me, is a huge
issue.
Rich
Sent from my iPhone
On Jun 21, 2016, at 6:31 PM, John Foliot <
john.foliot@deque.com> wrote:
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.") 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]
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
Attachments
- image/gif attachment: 0F607129.gif
- image/gif attachment: graycol.gif
Received on Wednesday, 22 June 2016 15:51:00 UTC