From: John Foliot [mailto:john.foliot@deque.com] Sent: Monday, April 04, 2016 11:10 AM As well, it's not just the audio output: you may believe that it is a password input (because the role told you so), but unless you have 100% faith that the field is also being obscured, what then? I simply find this troubling, that an author can make a declaration about a property of a widget, declarations around security and privacy, and we do not appear to have any mechanical way of enforcing that declaration. It is my belief that it weakens any existing trust non-sighted users may already have when dealing with password inputs. There is no mechanical way of enforcing any user interface behavior of author-supplied widgets. This is true in general, not just in the particular case you’re discussing. I think Joanie has written appropriate provisions into the draft so that screen readers will report what is actually presented in the field as the user enters text; and this is the best we can do to preserve security here. ________________________________ 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. ________________________________
Received on Monday, 4 April 2016 15:27:13 UTC