From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] Sent: 26 April 2016 14:40 “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.” If we have a reasonable number of screen reader implementations by the time we move out of CR, I think that would be a good strategy. Given the seriousness of the issue, I suggest we seek at least one implementation per accessibility API, preferably from a vendor with a substantial chunk of the market. “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.” I don’t think this will help any but the most technically knowledgeable of users. For most people the notion of a custom password field is meaningless. To understand what a custom field is, you need to know what a native field is, and furthermore you need to know what the characteristics and differences between the two actually are. In this particular case you also need to know how your screen reader works with regard to text input, and how ARIA changes that behaviour (or may not, depending on whether the password role has been implemented properly). Léonie. -- @LeonieWatson tink.uk Carpe diem
Received on Tuesday, 26 April 2016 14:49:03 UTC