Re: Objection to password role --- example thread

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

Received on Wednesday, 22 June 2016 15:51:00 UTC