Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

Hi James,

Good to hear from you again. 

1. Backward compatibility

I understand. Is there a way for you to patch other versions?   

2. Performance
I am aware of the performance issue having helped built a couple screen readers myself. In our Java screen reader we actually echo’d the rendered text but that was some time ago. Screen Reader/2 but I believe we read the rendered text there too. Both are slower than echoing text but they worked very reliably. The performance issue is why screen readers went to key echo and announcing stars for password characters. It takes more overhead to go back and access the text. I think you could limit that to only echoing rendered text with password fields. Matt King pointed out that on most screen readers key echo is only on by default so when you get to a password field the user may not even being be listening to the typed text. I think in this case you might want to always echo the text so that the user knows what is actually being rendered for passwords. 


Rich
 
Rich Schwerdtfeger




> On Apr 1, 2016, at 3:56 PM, James Teh <jamie@nvaccess.org> wrote:
> 
> Echoing the inserted text makes sense, but I have two concerns:
> 1. Backwards compatibility: Normally, we'd expose something like this using existing mapping so it works without change in the AT. However, in this case, doing that presents a security concern. If a user was using an older AT (even for a few months), the standard maping would result in the potential for false masking described.
> '2. Performance: Fetching the last inserted character every time a character is typed is quite expensive, especially with a fast typist. There are probably ways to work around this, but IMO, this needs intense testing before it could be declared a viable solution.
> 
> Sent from a mobile device
> 
> On 2 Apr 2016, at 5:11 AM, Rich Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com>> wrote:
> 
>> John, 
>> 
>> Did you read the updated CFC that was sent out prior to this email? Please read the revised text referenced in the CFC yesterday:
>> 
>> https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0063.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0063.html>
>> 
>> What you will see is that we are asking that the AT vendors modify the way the access password text. 
>> 
>> Matt, Joseph, myself, Joanie, and many of the others weighed in on this to address yours and others concerns. 
>> 
>> Nobody ignored your concerns. In fact, we all spent a lot of time on the call trying to address them. What is key to this proposal is a design change for screen reader vendors in how they handle passwords. This will effect how they handle both HTML5 password as well as a custom element with role=“password”. 
>> 
>> This will correct the issue. The problem needs to be addressed at the AT. If the AT speaks the actual rendered characters vs. either the echo’d text or the star star star issue then the user will immediately know whether the author has NOT obscured the text. There is nothing “sloppy” about that. 
>> 
>> It has been told to us numerous times that ARIA must not define how the browser renders content. This came to us from ALL the browser vendors. So, if that is not possible then we must deal with the custom passwords. The solution has to be two fold:
>> 
>> 1. First tell the AT that it is password field
>> 2. If it is the password field tell the user what is really being rendered on the screen. If the text is obscured the person will know immediately. If it is not they will know immediately and they can stop typing. 
>> 
>> It was also determined that screen readers who echo star star star vs. what is currently rendered for both HTML5 passwords and custom ARIA enabled passwords that it is a bug in all screen readers as it does not accurately represent what is being placed on the screen. 
>> 
>> I went to Freedom Scientific yesterday morning before the ARIA call and confirmed that this change was doable and that they supported the approach. 
>> 
>> We did work extremely hard to find a solution to the issues. What we do need is implementable solutions and going back to the browsers to change their UI is a non-starter. This is part of why you received so much pushback on longdesc by browser vendors. 
>> Correctly informing the user what is going on when they enter the customer password field is and it has no adverse effect on browser vendors. Browser vendors are not going to go in and programmatically obscure what the user is typing on the screen. There is a high risk of getting it wrong and messing with the UI the user was trying to create. This is one of the main reasons why browser vendors don’t want ARIA driving the UI.  
>> 
>> Now you asked us to talk to browser vendors. Cynthia went to the Microsoft Edge team on the security issue and they stated that the approach we were taking did not impact security. They were also not that concerned about the over the shoulder approach for someone looking at you type the password. We were and the solution was to go to the screen reader vendors to work out a solution. We plan on doing that with other AT vendors. I encourage you to speak with Cynthia on the browser team’s perspective on the security issues if you are not satisfied with my accounting of it or the minutes of the meeting. 
>> 
>> If this does not explain things adequately please reach out to me on Skype. 
>> 
>> Rich
>> 
>> Rich Schwerdtfeger
>> 
>> 
>> 
>> 
>>> On Apr 1, 2016, at 11:17 AM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>> wrote:
>>> 
>>> > What you are advocating is not providing the role and leaving it open because you think we are creating another hole which I do not agree that we are.
>>> 
>>> First Rich, I've politely asked that you to not make this personal. This is my second, and hopefully last request for that respect (please).
>>> 
>>> For the record, it's not just *ME* who has expressed concerns over this; people like Matt King, Leonie Watson and Wendy Seltzer (W3C Legal counsel) have also spoken up with their concerns:
>>> 
>>>    "For example, if the screen-reader were told to obscure characters but the visible password field did not, a person using a screen-reader could be mis-led about how the interface functioned (or vice versa)." - Wendy Seltzer 
>>> (https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0023.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0023.html>)
>>> 
>>>    "Introducing a different security hole to fix another doesn’t seem like a good solution." -  Leonie Watson
>>> (https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0028.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0028.html>)
>>> 
>>>    "Note that without the password role, the user is in control. All screen readers have a key for turning off key echo. So, no password role is the safer course if we can not resolve the conflict." - Matt King
>>> (https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0035.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0035.html>)
>>> 
>>> > I don’t like that you want to leave it open because we can’t tell the browser how to enforce password with an ARIA attribute. The fact that people are already not using the HTML5 password exists. 
>>> 
>>> Right, and so, for the non-sighted user today, a custom widget input field that doesn't have a special role of "password" defaults to a role of text-input, which, as Matt notes, is still a safer alternative. As I read the proposal today, the role="password" attribute is nothing more than a fancy accessible-name for an input that may, or may not, have the implied security associated to that input as well. Failing to address that problem is both sloppy and irresponsible in my opinion.
>>> 
>>> > So, you are telling me that we should either leave password and if we put it in give the author no guidance on what they should do because it might create a greater security issue. Sorry, but I am not following your logic.
>>> 
>>> My ongoing concern is this: A malicious actor can tell a blind user that the input field is a password field using the proposed role attribute, but, in fact, it isn't - that they would, in effect, use the role="password" attribute to LIE to the end user, who cannot visually verify that want the screen reader is saying ("star, star, star") is actually what is rendering on screen. You have not addressed that concern in all of your responses and put-downs of my position. For that level of trust to exist, the end user needs to rely on trusting more than just the page author, they have to trust their software tools as well.
>>> ​​
>>> Moving forward however, yes, if the screen reader vendors agree with a MUST requirement on their software tools, then that may very likely be a solution: it is, as I noted previously, a question of trust. It is useful that Freedom Scientific has indicated agreement with Joanie's proposal (https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0052.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0052.html>), and that Orca will also support this model, but I would love to hear feedback from both Apple and NVDA on this (as well as Dolphin Software/SuperNova, Serotek/System Access, and other screen reader vendors) before we assume this as a final decision. Partial support will be a scary scenario as well for affected users.
>>> 
>>> Perhaps better still (as I have also previously proposed), the ARIA WG approach the browser vendors with our security concern, and see if they too will provide a level of "enforcement" around the newly proposed role attribute:
>>> 
>>>      "So unless browsers commit to treating role=”password” with the same security approach as input type=”password” we leave open a door for a security/privacy breach." - JF
>>> (https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0042.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0042.html>)
>>> 
>>> This approach, while untested today, may meet with resistance from the browser vendors - or maybe not. At a minimum, we should be asking them for their thoughts and input on this issue as well, as they *DO* have a horse in this race.
>>> 
>>> JF
>>> 
>>> 
>>> On Thu, Mar 31, 2016 at 11:20 AM, Rich Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com>> wrote:
>>> I spoke with Brett Lewis at Freedom Scientific and he agreed with the solution that if a password role were applied that rather that echoing they keys typed or speaking stars for each character typed that they need to echo the character *rendered*. He also had no issues with making this an author MUST for ATs because of the security issues. Users will also need to be made aware that if they run across a password field and the characters spoken, while typing, match their password that there are exposed to a security risk. 
>>> 
>>> So, the net, net of this is that if we can get the ATVs to agree to this then this would solve all the issues related to a role=“password”. 
>>> 
>>> 
>>> Rich
>>> 
>>> Rich Schwerdtfeger
>>> 
>>> 
>>> 
>>> 
>>>> On Mar 29, 2016, at 4:01 PM, Joseph Scheuhammer <clown@alum.mit.edu <mailto:clown@alum.mit.edu>> wrote:
>>>> 
>>>> On 2016-03-29 1:10 PM, Cynthia Shelly wrote:
>>>>> The password role does not prevent accessing the content of the
>>>>> password field from script.
>>>> 
>>>> Somewhat tangential, but the same is true for an html5 password
>>>> <input>.  Its @value attribute contains the password in plain text.
>>>> 
>>>> -- 
>>>> ;;;;joseph.
>>>> 
>>>> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>>>>                 - C. Carter -
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> John Foliot
>>> Principal Accessibility Consultant
>>> Deque Systems Inc.
>>> john.foliot@deque.com <mailto:john.foliot@deque.com>
>>> 
>>> Advancing the mission of digital accessibility and inclusion
>>