RE: Objection to password role

My last clarification on the subject, then I shall peacefully withdraw, and celebrate Icelannd’s Independence Day.

 

ARIA is about equivalent experience.

A regular user that encounters a “custom password” field will see its label and will notice that as she starts typing something into the field, that her input is obfuscated.

The only assurance that regular user has comes from the label, and seeing that the text is obfiscated.

An aria-masked attribute would communicate that same information to the screen reader user, whereas role=”password” creates certain expectations that may or may not be met by the author.

If you see a fin in the water it might be a fish or a shark. All you see is a fin in the water. Can we, based on that, tell the screen reader user that a shark is in the vicinity when it might just be a harmless baracuda?

 

Additionally, obfuscated fields are increasingly popular for information other than passwords (i.e. personally sensitive information or payment info). And there is a need to be able to notify screen reader users of this. The password role would be misleading if applied to a social security number field, but aria-masked would be an accurate description.

 

With that, I rest my case and wish you all a good weekend.

 

 

 

From: John Foliot [mailto:john.foliot@deque.com] 
Sent: Friday, June 17, 2016 4:41 PM
To: White, Jason J <jjwhite@ets.org>
Cc: Joanmarie Diggs <jdiggs@igalia.com>; James Craig <jcraig@apple.com>; ARIA Working Group <public-aria@w3.org>; Michiel Bijl <michiel@agosto.nl>
Subject: 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 <mailto:jjwhite@ets.org> > wrote:

 

 

From: John Foliot [mailto:john.foliot@deque.com <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.

 <mailto:john.foliot@deque.com> john.foliot@deque.com

 

Advancing the mission of digital accessibility and inclusion