Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

Hi John, all.

Regarding this:

On 03/29/2016 11:23 PM, John Foliot wrote:

> But is it? The non-sighted user cannot visually verify that the
> characters are actually being obfuscated, they have to rely solely on
> audio feedback, and by simply slapping an attribute on the custom
> control it will "announce" that the field is being obfuscated, whether
> true or not.

If the screen reader's behavior in a password field is, as I suggested
in my earlier response to this thread:

1. Do not echo keypresses for fields which claim to be password inputs
2. DO echo inserted characters (if key echo is enabled by the user)

Then the screen reader will present whatever the characters in the input
field happen to be. Those rendered characters would be what gets exposed
to the screen reader by the user agent. Thus as long as the user agent
exposes the rendered/displayed text, then I think the screen reader will
present the obfuscated -- or not -- input seen by sighted users.

These characters could similarly be examined non-visually by using caret
navigation within the input and/or refreshable braille. In both cases of
those cases, ATs present what's actually rendered, as reported to the
ATs by the user agent.

--joanie

Received on Wednesday, 30 March 2016 13:13:29 UTC