- From: Gunderson, Jon R <jongund@illinois.edu>
- Date: Fri, 8 Apr 2016 21:07:13 +0000
- To: John Foliot <john.foliot@deque.com>
- CC: James Nurthen <james.nurthen@oracle.com>, Richard Schwerdtfeger <richschwer@gmail.com>, "public-aria@w3.org" <public-aria@w3.org>
- Message-ID: <46739F12637CC94E82F75FF874E4A1473BA0C303@CITESMBX6.ad.uillinois.edu>
John, It seems most forms that I fill out that require a social security number do not obfuscate the characters I enter. Are there some able bodied people who would stop filling out a form if controls with certain labels (e.g. social security number) are not obfuscating their input? Jon From: John Foliot [mailto:john.foliot@deque.com] Sent: Friday, April 08, 2016 2:48 PM To: Gunderson, Jon R <jongund@illinois.edu> Cc: James Nurthen <james.nurthen@oracle.com>; Richard Schwerdtfeger <richschwer@gmail.com>; public-aria@w3.org Subject: Re: Security Evaluation Request Hi Jon, That appears to be a somewhat simplistic view. I have seen previously the use of <input type="password"> to collect other sensitive data, for example social security numbers, and in those instances the <label> (or equivalent) would NOT be "Password", and so I think it would be reasonable to conclude that a custom input widget would likely also be used for similar "sensitive data" collection, above and beyond just a password. Ya? JF On Fri, Apr 8, 2016 at 1:23 PM, Gunderson, Jon R <jongund@illinois.edu<mailto:jongund@illinois.edu>> wrote: I assume these custom password controls will have a label (e.g. using the LABEL element or other labeling technique) of “Password”, so people will know the control is a password control without using the role=password. Isn’t having a role=password at least providing a means to identify the custom password control in a way that supports internationalization, and reducing any ambiguity of the purpose and caution an assistive technology user should take when interacting with the control? Jon From: James Nurthen [mailto:james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>] Sent: Friday, April 08, 2016 12:57 PM To: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>; 'Richard Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>> Cc: public-aria@w3.org<mailto:public-aria@w3.org> Subject: Re: Security Evaluation Request John, My issue with this whole "evil author" thing is that an "evil author" can do exactly what you are talking about today without the need for a password role. Why are we getting hung up on this? Regards, James On 4/8/2016 10:54 AM, John Foliot wrote: Hi all, Outside of SVG, are there any other W3C mark-up languages where this is a problem? Is the lack of ability to create a password field in SVG the primary driver of this request/need today? Could the “native semantic” issue (and related security/privacy concerns) be dealt with inside of the SVG spec instead? One of my ongoing concerns is with giving an author (any author, from IBM or Oracle to Dr. Evil and his Merry Band of Tricksters) a carte-blanche ability to imply some sense of security and privacy on a custom, author-supplied widget. Saying we can't impose behavior on a custom control via ARIA is one thing, turning around and giving authors the ability to be untruthful about it is a whole other kettle of fish, and I am troubled that we may not be looking at how this proposed attribute might be used maliciously, with the express attempt to deceive. It is my hope that this question also be contemplated in a security review. JF -- John Foliot Principal Accessibility Strategist Austin, TX Deque Systems Inc. 2121 Cooperative Way, Suite 210, Herndon, VA 20171-5344 Office: 703-225-0380<tel:703-225-0380> john.foliot@deque.com<mailto:john.foliot@deque.com> Advancing the mission of digital accessibility and inclusion From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] Sent: Friday, April 8, 2016 11:44 AM To: James Nurthen <james.nurthen@oracle.com><mailto:james.nurthen@oracle.com> Cc: public-aria@w3.org<mailto:public-aria@w3.org> Subject: Re: Security Evaluation Request You cannot make an accessible password field in SVG without it. On Apr 8, 2016, at 11:40 AM, James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>> wrote: On 4/8/2016 9:37 AM, Gervase Markham wrote: On 08/04/16 17:22, Richard Schwerdtfeger wrote: Companies do not use standard HTML markup when they feel it does not meet their needs. It really does not have anything to do with whether the markup is semantically correct. This is happening now and we don’t even have a password role. Companies that must do this for business reasons need a way to make it accessible. They have a way to make it accessible - use a proper password field. So what you are asking for is actually a second way to make it accessible. What happens if some company then comes forward and says they can't use your solution because for security reasons they aren't allowed to label the field "password" in any way. What do you do then? Invent an alias and call it "type='mrblobby'"? There is only a certain distance one should go to accommodate ridiculous corporate requests. "We want to do passwords but don't want to use password fields" is a user-hostile request (both for users requiring accessibility technology and other users) and should be treated as such. How can someone create a password field in SVG without this? Regards, James The bigger issue is that passwords as a technology have long outlived their usefulness. The growing world aging population has issues remembering passwords for all the sites they have to gain access to so they often use a simple, short, easy to remember password across all the sites creating a security issue. To this end even HTML’s password is a security risk as it is much easier to hack. This can result in identity theft and a whole litany of issues. Captchas are also a huge problem for aging users. This may be so; but encouraging people to use non-password fields for passwords and so avoiding all the software people are using to help them manage the password problem (which does make things better) doesn't help. Gerv -- Regards, James <oracle_sig_logo.gif><https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com_&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=qR1G-AqvG7bBAGsi8MrDKDeU6g3O3BCZ1J3nZtEbzbA&e=> James Nurthen | Principal Engineer, Accessibility Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com> Oracle Corporate Architecture 500 Oracle Parkway | Redwood Cty, CA 94065 <green-for-email-sig_0.gif><https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com_commitment&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=x-IS-XAc3vrKpeTTukDTHutjPgkPg5WJZKOaitYVHbM&e=> Oracle is committed to developing practices and products that help protect the environment -- Regards, James [Oracle]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=I5TNORjxknLRRVIrziQprUfKJHO0exksHZbqkPxv0UE&e=> James Nurthen | Principal Engineer, Accessibility Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com> Oracle Corporate Architecture 500 Oracle Parkway | Redwood Cty, CA 94065 [Green Oracle]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com_commitment&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=x-IS-XAc3vrKpeTTukDTHutjPgkPg5WJZKOaitYVHbM&e=>Oracle is committed to developing practices and products that help protect the environment -- John Foliot Principal Accessibility Consultant Deque Systems Inc. john.foliot@deque.com<mailto:john.foliot@deque.com> Advancing the mission of digital accessibility and inclusion
Attachments
- image/gif attachment: image001.gif
- image/gif attachment: image002.gif
Received on Friday, 8 April 2016 21:08:16 UTC