Steps to reproduce: 1. Open the (to be) attached test case. 2. Examine the accessible associated with the password field in Accerciser. Expected results: The accessible's role would be PASSWORD_TEXT. Actual results: The accessible's role is ENTRY. Usage/Need: Screen readers such as Orca have an option to echo the keys being typed (i.e. to confirm to a user less familiar with the keyboard layout that each keypress is for the expected key). If this were to take place in a password field, the user would be announcing his/her password character by character each time he/she entered it. Therefore, it is necessary for screen readers to be able to distinguish traditional entries from password fields.
Created attachment 30170 [details] aforementioned test case
Created attachment 30504 [details] return PASSWORD_TEXT for password fields
Comment on attachment 30504 [details] return PASSWORD_TEXT for password fields Looks good to me. One thing to consider is why there's no equivalent role in WebCore, and whether it might sense to add one.
(In reply to comment #3) > (From update of attachment 30504 [details] [review]) > Looks good to me. One thing to consider is why there's no equivalent role in > WebCore, and whether it might sense to add one. > Landed in r43899
Thanks Jan. Marking as VERIFIED.