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

> 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