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.
>
> 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.
>
> <divclass=/'searchbar'/_ng-controller_=/"searchboxCtrl"/>
> <!-- Pill for each selected search term -->
> <divclass=/'pill'/_ng-repeat_=/"item in data | itemSelected"/>
> <buttonclass=/'noBackground'/data-ind=/"{{item.ind}}"/_ng-click_=/'deleteTerm($event)'/>{{item.name}}
> <imgalt=/"remove from 
> search"/src=/"icon/x.svg"/width=/"10"/height=/"10"/class=/'pillIcon'/>
> </button>
> </div>
> <divid=/'contactSearch'/contenteditable=/"true"/aria-haspopup=/'true'/_ng-keyup_=/'searchEvent($event)'/role=/'search'/></div>
> <!-- search button with magnifying glass ->
> <buttonclass=/'noBackground'/>
> <imgalt=/"search contacts"/src=/"icon/search_24.svg"/class=/"rightbar"/>
> </button>
> <!-- Completion list -->
> <divclass=/'popup'/id=/'searchPopup'/_visibility_=/'hidden'/>
> <ulclass=/'completionList'/>
> <liclass=/'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
>
>
>
> Inactive hide details for Michael Cooper ---06/22/2016 02:54:13 
> PM---On 22/06/2016 1:58 PM, Richard 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_ 
> <https://www.w3.org/TR/html51/sec-forms.html#password-state-typepassword>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
>
>