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

Hi Joanie, Matt

This is in actual response to Matt King but I see his post on the list and not in my email. 

https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0035.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0035.html>

I like your solution. It is a simpler solution to the problem. 

The problem is we have never told AT what they MUST do before. Perhaps for security reasons it is warranted here. However, if this is a MUST it would need to be in the exit criteria for ARIA 1.1 and we have never done that before. … that said it is easy to get two implementations. 

I don’t want to open Pandora’s box however and start dictating how ATs render everything. That will be a non-starter I can assure you.


Rich


Rich Schwerdtfeger




> On Mar 30, 2016, at 8:12 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote:
> 
> 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
> 
>