Re: Password role proposal: Freedom Scientific response

You have not stated anything new here John. You have the feedback from security you asked for.

Rich

Sent from my iPhone

> On May 2, 2016, at 8:43 AM, John Foliot <john.foliot@deque.com> wrote:
> 
> > to tell the screen reader that this is a password field that the screen reader should treat differently
> 
> ...and I believe right there is the problem. What if it's *not* a password (enhanced) field? What if, through error or malice a developer "tells" the screen reader that an input is a password, but it's a password field in name alone? What if it's just this:
> 
>      <div role="password" contenteditable>
> 
> or this:
> 
>      <input type="text" role="password" class="js_fake_blur">
> 
> Previously, when you used < input type="password">, behaviors, both visually and also programmatically where modified by the browser: for example, you cannot copy the content you've supplied into a password field and paste it elsewhere, characters are obscured on screen, etc. The current proposal addresses how a screen reader echos back what you are typing when you invoke this ARIA attribute, but none of the other expected behaviors will be present (but you won't know that).
> 
> Rich has suggested that my concern is "over the top", that no developer is going to write code to specifically target non-sighted users (nobody on the internet would be that uncaring, that mean, that evil), but I remain unconvinced of his unicorn and rainbows response - I fear that there will indeed be a bad actor out there that will look for ways to exploit this.
> 
> Matt, if we want to tell screen readers that a form input is 'different' and that it is treated differently, we need some form of assurance that it is indeed being treated differently by the browsers as well as the screen reader - I assert anything less is likely a security problem waiting to happen.
> 
> We are still waiting for a more formal review from the web security folks at the W3C.
> 
> JF
> 
>> On Sun, May 1, 2016 at 9:15 PM, Matt King <a11ythinker@gmail.com> wrote:
>> The purpose of telling a screen reader that a field is a custom password field is not to pass that info on to the user but to tell the screen reader that this is a password field that the screen reader should treat differently in order to give the user appropriate information.
>> 
>>  
>> 
>> The password role description provides screen reader developers with a recommendation for how to adjust behavior.
>> 
>>  
>> 
>> Matt
>> 
>>  
>> 
>> From: Léonie Watson [mailto:tink@tink.uk] 
>> Sent: Tuesday, April 26, 2016 7:48 AM
>> To: 'Rich Schwerdtfeger' <richschwer@gmail.com>; 'White, Jason J' <jjwhite@ets.org>
>> Cc: 'John Foliot' <john.foliot@deque.com>; 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com>; public-aria@w3.org
>> Subject: RE: Password role proposal: Freedom Scientific response
>> 
>>  
>> 
>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
>> 
>> Sent: 26 April 2016 14:40
>> “My take on it is we either put it in or move it to 2.0. There is nothing terribly challenging on our end regarding accessibility api mapping. The AT vendor piece about speaking the rendered text (group consensus) is a SHOULD. If, however, we don’t put the password role into ARIA it is extremely unlikely that the ATVs will modify their code.”
>>  
>> 
>> If we have a reasonable number of screen reader implementations by the time we move out of CR, I think that would be a good strategy. Given the seriousness of the issue, I suggest we seek at least one implementation per accessibility API, preferably from a vendor with a substantial chunk of the market.
>> 
>>  
>> 
>> “What we are really waiting to hear on is security. I think if we convey to ATs that this is a custom password field that will help a great deal.”
>> 
>>  
>> 
>> I don’t think this will help any but the most technically knowledgeable of users. For most people the notion of a custom password field is meaningless. To understand what a custom field is, you need to know what a native field is, and furthermore you need to know what the characteristics and differences between the two actually are. In this particular case you also need to know how your screen reader works with regard to text input, and how ARIA changes that behaviour (or may not, depending on whether the password role has been implemented properly).
>> 
>>  
>> 
>> Léonie.
>> 
>>  
>> 
>> --
>> 
>> @LeonieWatson tink.uk Carpe diem
>> 
> 
> 
> 
> -- 
> John Foliot
> Principal Accessibility Consultant
> Deque Systems Inc.
> john.foliot@deque.com
> 
> Advancing the mission of digital accessibility and inclusion