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

Hi Rich,

Yes, I have seen events transpire on this topic. You will note I wrote the
following on my previous post:

> 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),
and that Orca will also support this model, <strong>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.</strong>

Question: have we heard from any other screen reader vendors? Has there
been a concerted effort to seek that feedback? While this seems like a
workable plan, the devil as they say is in the details. For example,
without support from VoiceOver here I think it would be a dead-on-delivery
solution.

I will wait to see and hear the response from these vendors and the crucial
role they will play on this proposal.

JF

On Fri, Apr 1, 2016 at 2:18 PM, White, Jason J <jjwhite@ets.org> wrote:

> +1 from me for the revised CFC.
>
>
>
>
>
> *From:* Rich Schwerdtfeger [mailto:richschwer@gmail.com]
> *Sent:* Friday, April 01, 2016 3:11 PM
> *To:* John Foliot
> *Cc:* Joseph Scheuhammer; Cynthia Shelly; Matt King; Léonie Watson; ARIA
> Working Group; David Bolter; Dominic Mazzoni; Chaals from Yandex; James
> Craig; jamie@nvaccess.org
> *Subject:* Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group
> Resolutions
>
>
>
> 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
>
>
>
> 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> 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)
> "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)
> "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)
>
>
>
> > 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),
> 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)
> 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>
> 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>
> 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
>
>
>
> Advancing the mission of digital accessibility and inclusion
>
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>



-- 
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion