Re: Password role proposal: Freedom Scientific response

> 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
> <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