Re: Objection to password role

Hi Jason,

While I respect your desire to not return to "old business", I will also
state that I've previously noted that the conditions of the CfC that passed
have not yet been formally met. If you are uninterested in continuing to be
involved in this discussion I can respect that, but that alone should not
be cause to cease discussing this on this list.

Taking my name out of the discussion, we continue to have experienced and
seasoned experts (James, Leonie, Birkir, Michiel) voicing concerns here,
and I would be loathe to do the expeditious thing rather than the right
thing, whether here or elsewhere. We have an obligation to get this done
correctly, not quickly.

> defining the role improves the status quo for users of screen readers
which support it

Some of us remain unconvinced that this *does* make anything better for
screen reader users - sure, it now ensures that with screen readers that
support this, obfuscated letters would be read out as such, and
non-obfuscated letters would be echoed as such - but masking the letters in
an input is not the *only* thing that the password input affords the end
user. Yet none of those other security and privacy aspects are being
imparted on an editable widget tagged as a password input, yet you are
being told that it *is* a password input. Joanie has today surfaced the
usability issue around that, and the possibility of user-inflicted error
through impatience or inexperience (
https://lists.w3.org/Archives/Public/public-aria/2016Jun/0117.html), and
Birkir has opined that perhaps we need to rename this to be clearer in what
it is and isn't doing (
https://lists.w3.org/Archives/Public/public-aria/2016Jun/0118.html). The
bottom line here is that this is more than just how a screen reader
announces an input to the non-sighted user, and attempting to frame it as
such is (in my opinion) extremely short-sighted: there are real security
and privacy implications to be considered beyond announcing "star, star,
star".

> We already have a CFC on this which passed and I would rather avoid yet
another lengthy controversy on the subject.

As I previously stated, *I* won't continue objecting - I've said my piece,
I'm on the record with my concerns, and the Warning language I brought
forward for inclusion in the Draft Specification was accepted and added to
the Draft - but W3C process does allow for continued comment and even
Formal Object right up until such time as a Recommendation clears the CR
process, so yes, we had a CfC that passed, but that is not "The End" from
any perspective. I would strongly object if an artificial halt was imposed
on any discussion related to security and privacy at the W3C, and I suspect
that alone would also be further grounds for a Formal Objection at the
Candidate Recommendation phase should it happen. Further, should continued
discussion find us at the point where we defer this role value to ARIA 2.0,
I would quite quickly and happily support that CfC as well.

I will respectfully suggest that if you are not inclined to be involved in
this current discussion that you use the appropriate email filters to
further avoid this thread.

Sincerely,

JF


On Fri, Jun 17, 2016 at 2:52 PM, White, Jason J <jjwhite@ets.org> wrote:

>
>
>
>
> *From:* John Foliot [mailto:john.foliot@deque.com]
>
> No worries, we now have James here who *is* an Apple person. I know that
> Apple traditionally does not state if or when they plan on doing anything
> specific, although James your continued input into this discussion is I
> think valuable.
>
>
>
> It is apparent that for this to "work" as scoped we will need the screen
> reader vendors onboard, and lack of 'support' in Voiceover would be a
> significant issue going forward. We currently have indication that ORCA
> (via Joanie) will support this, and it has been stated that Freedom
> Scientific are working on supporting this in JAWs, however there are
> significantly more screen readers in the marketplace then there are
> browsers, and so that is yet another troubling scenario - without
> widespread support this will not even address the problem it alledges to be
> addressing.
>
>
>
> If a screen reader doesn’t support the password role, then it seems to me
> that the outcome can’t be worse than a situation in which the author
> chooses to implement a custom password widget and there is no password role
> with which to make it accessible using ARIA.
>
>
>
> That is, defining the role improves the status quo for users of screen
> readers which support it, without making the situation worse for others.
>
>
>
> We already have a CFC on this which passed and I would rather avoid yet
> another lengthy controversy on the subject.
>
>
>
> ------------------------------
>
> 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