Re: Use cases for password

Michael,

That is the right interpretation. I am not responding specifically for a
password role, just pointing out that with the declining use of HTML forms
and form related controls that there are gaps in what authors can tell AT.

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From: Michael Cooper <cooper@w3.org>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: ARIA <public-aria@w3.org>
Date: 06/22/2016 04:44 PM
Subject: Use cases for password



Hi Fred - if I understand your message you're not responding specifically
on the risks of the password role, but suggesting a use case for the role.
Is that correct?


In that case, I think it will help the discussion if we keep the threads
separate, so I'm replying with a new subject line to start a thread on use
cases.


If I've got your intent wrong, let me know, and perhaps you could clarify
how the example you provided relates to the risks of the role thread.


Michel



On 22/06/2016 4:28 PM, Fred Esch wrote:


      Michael,

      A trend I see is developers moving away from using forms. With
      libraries like angularJS, it easy to bind your data model to UI so
      there is no benefit to the application to use a form/input elements
      over a div with contenteditable true. And without roles to support
      what the custom controls replace it will be hard to convey the
      control to AT. Sorry I couldn't find a password example but the
      comments apply there as well.

      A custom search on curated terms might look like this.

      customsed in
      a search
      HTML for the mulitsearch below. Note as you type, the completion list
      appears and if you select from the list is adds the selected term the
      set of pills. The outermost div in the HTML below has a blue border
      around it in the picture.

      <div class='searchbar' ng-controller="searchboxCtrl" >
      <!-- Pill for each selected search term -->
      <div class='pill' ng-repeat="item in data | itemSelected">
      <button class='noBackground' data-ind="{{item.ind}}" ng-click=
      'deleteTerm($event)'>{{item.name}}
      <img alt="remove from search" src="icon/x.svg" width="10" height="10"
      class='pillIcon'>
      </button>
      </div>
      <div id='contactSearch' contenteditable="true" aria-haspopup='true'
      ng-keyup='searchEvent($event)' role='search'></div>
      <!-- search button with magnifying glass ->
      <button class='noBackground'>
      <img alt="search contacts" src="icon/search_24.svg" class="rightbar">
      </button>
      <!-- Completion list -->
      <div class='popup' id='searchPopup' visibility='hidden'>
      <ul class='completionList'>
      <li class='completion' ng-repeat="item in matchedList" data-ind=
      "{{item.ind}}" ng-blur='liBlur' ng-keydown='liEvent($event)'>
      {{item.name}}</li>
      </ul>
      </div>
      </div>

                                                     
     Regards,                                        
                                                     
    Fred Esch                                        
 Watson, IBM, W3C                                    
  Accessibility                                      
                                                     
 IBM              Watson Release Management and      
 Watson           Quality                            
                                                     




      Inactive hide16
      02:54:13 PM---OnRichard Schwerdtfeger
      wrote: > WellMichael Cooper ---06/22/2016 02:54:13 PM---On 22/06/2016
      1:58 PM, Richard Schwerdtfeger wrote: > Well,

      From: Michael Cooper <cooper@w3.org>
      To: Richard Schwerdtfeger <richschwer@gmail.com>
      Cc: ARIA <public-aria@w3.org>
      Date: 06/22/2016 02:54 PM
      Subject: Re: Risks the password role does create





      On 22/06/2016 1:58 PM, Richard Schwerdtfeger wrote:
                  Well,

                  Michael, as it turns out input type=“password” is not
                  secure either. I will be filing an APA issue.
      This does bring up some concerns about the bar we should meet. One
      argument in the WG against the password role (though properly I think
      that is an argument against custom passwords, not the role per se) is
      that HTML passwords are more secure. But the HTML 5.1 password spec
      doesn't say much about the security protections user agents provide,
      aside from "The user agent should obscure the value so that people
      other than the user cannot see it." For custom password fields, that
      would be an author responsibility, regardless of whether they use the
      password role.

      I can't find any other guidance in the HTML spec about protecting
      password fields, and this has likely been true for several versions.
      Maybe there is some de facto security implemented long ago by most
      browsers so there wasn't seen a need to address it in the spec,
      though since a main goal of HTML 5 was to document existing browser
      behavior, it's a surprise this didn't come up. I don't have
      information about what proportion of user agents do provide that
      security, and wonder if interoperability testing data exists on this.
      If Rich has found implementations that don't meet the level of
      security we assume, then it brings further questions about whether
      comparing to HTML should be a reason for decisions we make on the
      ARIA feature.

      At the moment I think the draft ARIA password role text has more
      security guidance for AT and authors than the HTML spec.

      Michael