- From: Fred Esch <fesch@us.ibm.com>
- Date: Wed, 22 Jun 2016 13:52:16 -0400
- To: Richard Schwerdtfeger <richschwer@gmail.com>
- Cc: ARIA <public-aria@w3.org>
- Message-Id: <OF2DF8D9C2.7ABD28E3-ON85257FDA.0061E312-85257FDA.00622B8F@notes.na.collabserv.c>
Sorry, I ran across the example this morning and didn't notice the toggling
of behavior before I sent it. It doesn't obscure text when not using a
type password.
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: Richard Schwerdtfeger <richschwer@gmail.com>
To: Michiel Bijl <michiel@agosto.nl>
Cc: Fred Esch/Arlington/IBM@IBMUS, ARIA <public-aria@w3.org>
Date: 06/22/2016 12:52 PM
Subject: Re: Objection to password role --- example thread
It is a custom password filed in that it uses a standard input field for a
password when you don’t want it obscured. It does not reflect the
autocomplete use case.
It is hokey.
Rich
On Jun 22, 2016, at 10:30 AM, Michiel Bijl <michiel@agosto.nl> wrote:
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: 14229696.gif
- image/gif attachment: graycol.gif
Received on Wednesday, 22 June 2016 18:04:00 UTC