My take on it is we either put it in or move it to 2.0. There is nothing terribly challenging on our end regarding accessibility api mapping. The AT vendor piece about speaking the rendered text (group consensus) is a SHOULD. If, however, we don’t put the password role into ARIA it is extremely unlikely that the ATVs will modify their code. What we are really waiting to hear on is security. I think if we convey to ATs that this is a custom password field that will help a great deal. Rich Rich Schwerdtfeger > On Apr 25, 2016, at 2:03 PM, White, Jason J <jjwhite@ets.org> wrote: > > > > From: Léonie Watson [mailto:tink@tink.uk <mailto:tink@tink.uk>] > Sent: Monday, April 25, 2016 12:47 PM > > We do, yes. In this case I think walking means we need to drop the password role from 1.1, and take more time to try and get buy in from implementors. > > A less drastic alternative would be to mark it as a feature at risk, but still take it to Candidate Recommendation to determine whether we can achieve correct and interoperable implementations. Before doing this, I would suggest checking with the W3C staff contact for the working group regarding the procedural details; but I think giving it a chance to be implemented in CR would be a better course of action than dropping a well specified proposal. > > > 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 Tuesday, 26 April 2016 13:40:47 UTC