Re: Risks the password role does create

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.

custom curated search allowing multiple terms to be used 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       Watson Release Management and Quality       
                                                              






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