Re: Password role proposal: Freedom Scientific response

I think that is a MUST but it will be handled via the API mappings. I am not sure we have to put it in the actual spec. Note: I am not against making that normative text for the password role. 

I believe that if we do that that the assistive technology user will then have more information than the non-AT user. Frankly, as a sighted user I don’t notice visually whether they are using a custom password field or not. 

Rich

Rich Schwerdtfeger




> On Apr 25, 2016, at 11:58 AM, Matt King <a11ythinker@gmail.com> wrote:
> 
> Rich, Would this require a user agents  MUST statement … user agents MUST expose information that allows assistive technologies to distinguish between fields designated as a password field by using the ARIA password role and fields that have password characteristics as a result of native host language semantics … or something like that.
>   <>
> From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] 
> Sent: Monday, April 25, 2016 8:41 AM
> To: 'Rich Schwerdtfeger' <richschwer@gmail.com>
> Cc: tink@tink.uk; 'Rich Schwerdtfeger' <schwer@us.ibm.com>; public-aria@w3.org
> Subject: RE: Password role proposal: Freedom Scientific response
>  
> Even better.
>  
>  
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
> Sent: Monday, April 25, 2016 11:32 AM
> To: Birkir Gunnarsson <birkir.gunnarsson@deque.com <mailto:birkir.gunnarsson@deque.com>>
> Cc: tink@tink.uk <mailto:tink@tink.uk>; Rich Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com>>; public-aria@w3.org <mailto:public-aria@w3.org>
> Subject: Re: Password role proposal: Freedom Scientific response
>  
> We don’t necessarily need to create a new aria attribute. We simply provide a new attribute in the platform mapping that does it automatically. This way, if they forget the additional attribute and they simply put role=“password” then it just maps automatically.
>  
> Rich
>  
> Rich Schwerdtfeger
>  
>  
> 
>  
>> On Apr 25, 2016, at 9:56 AM, Birkir Gunnarsson <birkir.gunnarsson@deque.com <mailto:birkir.gunnarsson@deque.com>> wrote:
>>  
>> I am much more onboard with the idea if we add the “aria-custom-password” attribute along with the password role.
>>  
>>  
>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
>> Sent: Monday, April 25, 2016 9:35 AM
>> To: tink@tink.uk <mailto:tink@tink.uk>
>> Cc: Rich Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com>>; public-aria@w3.org <mailto:public-aria@w3.org>
>> Subject: Re: Password role proposal: Freedom Scientific response
>>  
>> I would agree with that statement. Security should be what is important. 
>>  
>> I would interpret this is that if the ARIA spec. says ATs SHOULD expose the rendered text vs. the star star star approach then we should expect them to do that in the future as they have publicly committed to supporting ARIA.
>>  
>> If it is not in the ARIA spec. we may never see it in JAWS. 
>>  
>> This is our opportunity to get them to do things correctly by putting it in the ARIA spec. One thing we might do, however, is to also expose an additional attribute at the platform layer to indicate these are custom password roles. 
>>  
>> This would address some of John’s concerns about not knowing that this is a custom password field. It will require changes in AT behavior and end-user education. 
>>  
>> Thoughts? 
>>  
>> Rich
>>  
>>  
>> Rich Schwerdtfeger
>>  
>>  
>> 
>>  
>>> On Apr 25, 2016, at 3:32 AM, Léonie Watson <tink@tink.uk <mailto:tink@tink.uk>> wrote:
>>>  
>>> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com <mailto:schwer@us.ibm.com>] 
>>> Sent: 22 April 2016 19:30
>>> “Following up on Leonie's request to contact ATVs. I contacted Freedom Scientific's CTO regarding the changes we have put in the ARIA password role regarding what ATs should do in response to speaking the actual text rendered.
>>>  
>>> Statement from Glen Gordon at FS:
>>> Freedom Scientific actively embraces ARIA. We recognize that this is an evolving standard and do our best to support newly added items in a timely fashion.”
>>>  
>>> Thanks for following up on this Rich. I understand that FS is reluctant to commit to a particular course of action, and I daresay they wouldn’t be the only ones if we were to reach out to other proprietary screen reader vendors.
>>>  
>>> “They have a policy to not commit to dates or product features publicly so this is as good as it gets.”
>>>  
>>> A commitment to implement the password role is understandably something FS might be reluctant to provide, but a general commitment to protecting consumer security would have been better than this.
>>>  
>>> As things stand we do not have a clear commitment from any screen reader vendor other than Orca, that the password role will be implemented in a secure way. This is troubling.
>>>  
>>>  
>>> Léonie.
>>>  
>>> -- 
>>> @LeonieWatson tink.uk <http://tink.uk/> Carpe diem