- From: Fred Esch <fesch@us.ibm.com>
- Date: Wed, 22 Jun 2016 10:20:35 -0400
- To: Rich Schwerdtfeger <richschwer@gmail.com>
- Cc: ARIA <public-aria@w3.org>
- Message-Id: <OF2DCBE852.F4913EC6-ON85257FDA.004D3AE9-85257FDA.004ECA02@notes.na.collabserv.c>
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.
IAAP checkout with visible password in custom password field
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
IBM Watson Watson Release Management and Quality
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/jpeg attachment: 13426391.jpg
- image/gif attachment: 13375923.gif
- image/gif attachment: graycol.gif
Received on Wednesday, 22 June 2016 14:25:53 UTC