Re: ARIA password role

I'm not sure that even #1 is necessary.  There is no such notification for
without AT for users interacting with fields that "behave like" password
fields but aren't <input type=password>.  A meaningful trust decision can
only be made by examining the address bar to verify the identity of the
resource and that it was delivered securely.

On Mon, May 2, 2016 at 8:59 AM Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

> Brad,
>
> Thank you for responding to us so quickly. I gather that you don’t see it
> is necessary to have a joint meeting on the security issues related to an
> ARIA password role.
>
> Let me try and summarize what you deem to the best course of action:
>
> 1. Ensure that the assistive technology is conveyed that this is a custom
> password role versus the standard HTML password role and this should be
> conveyed in our specification.
> 2. With this addition the password role text is acceptable:
> https://rawgit.com/w3c/aria/password-role/aria/aria.html#password
> 3. Although this is separate from ARIA, work with AT vendors to ensure
> that they notify the AT user of the state of security indicators in
> browsers:
> https://developer.mozilla.org/en-US/docs/Web/Security/Insecure_passwords
>
> If you agree with this summary the ARIA Working Group will  proceed on
> this advice.
>
> Rich
>
> Rich Schwerdtfeger
> Chair, ARIA Working Group
>
>
>
>