- From: Fred Esch <fesch@us.ibm.com>
- Date: Wed, 22 Jun 2016 11:06:16 -0400
- To: Michiel Bijl <michiel@agosto.nl>
- Cc: ARIA <public-aria@w3.org>
- Message-Id: <OF51CB971C.A5CED634-ON85257FDA.0052B856-85257FDA.0052F8EE@notes.na.collabserv.c>
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
IBM Watson Watson Release Management and Quality
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: 15927898.gif
- image/gif attachment: graycol.gif
Received on Wednesday, 22 June 2016 15:14:35 UTC