- From: John Foliot <john.foliot@deque.com>
- Date: Fri, 8 Apr 2016 14:48:19 -0500
- To: "Gunderson, Jon R" <jongund@illinois.edu>
- Cc: James Nurthen <james.nurthen@oracle.com>, Richard Schwerdtfeger <richschwer@gmail.com>, "public-aria@w3.org" <public-aria@w3.org>
- Message-ID: <CAKdCpxysd47ROmgh1gBPZnCmLtYbcTEBgmNj51rHtH-osEkoQw@mail.gmail.com>
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> 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] > *Sent:* Friday, April 08, 2016 12:57 PM > *To:* John Foliot <john.foliot@deque.com>; 'Richard Schwerdtfeger' < > richschwer@gmail.com> > > *Cc:* 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 > > john.foliot@deque.com > > > > *Advancing the mission of digital accessibility and inclusion* > > > > > > > > *From:* Richard Schwerdtfeger [mailto:richschwer@gmail.com > <richschwer@gmail.com>] > *Sent:* Friday, April 8, 2016 11:44 AM > *To:* James Nurthen <james.nurthen@oracle.com> <james.nurthen@oracle.com> > *Cc:* 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> > 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 <+1%20650%20506%206781> | Mobile: +1 415 987 1918 > <+1%20415%20987%201918> | Video: 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 > > [image: 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 <+1%20650%20506%206781> | Mobile: +1 415 987 1918 > <+1%20415%20987%201918> | Video: james.nurthen@oracle.com > Oracle Corporate Architecture > 500 Oracle Parkway | Redwood Cty, CA 94065 > [image: 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 Advancing the mission of digital accessibility and inclusion
Attachments
- image/gif attachment: image002.gif
- image/gif attachment: image001.gif
Received on Friday, 8 April 2016 19:48:48 UTC