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

> I don’t know for sure yet but if VoiceOver is using the HTML password
input type to decide if the characters are masked and echo a sound then
this is a problem for custom password fields. So, let’s say you don’t put a
role=“password” on the field VoiceOver will echo the characters even if
they were not obscured. If you do put a role=“password” and it speaks the
semantic sounds vs. the characters and the author has not obscured the text
then the user does not know that the text he is typing is in the clear.

Hi Rich,

Therein lies the root of the problem.

Creating a newly abstracted role that suggests or implies any form of
Privacy or Security has to have a mechanism whereby the end user can trust
what their system is telling them is in fact true. I recognize getting
browser vendors on board here may be problematic, perhaps even not
possible, but - have we even asked? Getting 5 or 6 browsers on-board may
ultimately be easier (effort wise) than chasing after 20 or more different
screen reader vendors (The AFB lists 18 possible tools on their website at:
http://www.afb.org/ProdBrowseCatResults.asp?CatID=49)

> I have a to-do to reach out to other vendors - previous post. Dolphin and
GW Micro were on my list to reach out to. However, it is impractical to ask
the working group to reach out to every vendor possible. For example, their
are screen reader vendors in Japan. As chair I am going to draw a line
there. We need to prove 2 implementations and although this is not a MUST
statement I think for security we should try to get 2 implementations
regardless. More than that is beyond what is required by the working group.

Without committed support from more than just 2 AT Vendors, I think I would
have to push back on the CfC and this proposed ARIA attribute fairly
strenuously. As this thread has shown, this is more of a concern than you
may want to admit, and in the case of Security and Privacy, I personally
would tend to err on the side of caution.

So far, I have tentatively agreed with Joanie's proposed fix for this
problem as being a pragmatic compromise, but with caveats.
Getting implemented support from Freedom, GW-Micro, Dolphin, Orca and NVDA
would be a great start, but absent in your list is Voiceover, and failing
to get Apple on board would be a huge gap in coverage - I would suggest a
game-changer. As well, what of newer entrants into this field (Amazon's
latest entry, which Peter Korn was showing at CSUN, Android TalkBack, etc.)?

Finally, I am also somewhat concerned that you seem quite prepared to
abandon the needs and expectations of non-North American screen reader
users so blithely (ref: Japanese screen readers), simply in the interest of
expediency. I fail to see how that benefits anyone, and have concerns
around messaging that position going forward.

JF

On Sat, Apr 2, 2016 at 7:34 AM, Richard Schwerdtfeger <richschwer@gmail.com>
wrote:

>
> > On Apr 2, 2016, at 6:37 AM, Léonie Watson <tink@tink.uk> wrote:
> >
> >> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
> >> Sent: 02 April 2016 12:22
> >>
> >> No. We spoke to Microsoft browser people. They did not believe we made
> >> the problem worse.
> >
> > We also heard from Wendy Seltzer, who agreed that the proposed role
> > definition represented a risk because of the possible discrepancy between
> > the visual and aural representations.
> >
>
> Our revised text says the AT should read the actual rendered text. If the
> AT reads the actual rendered text how is that a discrepancy between the
> visual and aural rendering?
>
> Currently, without a password role the potential exists for a discrepancy
> between the spoken text and obscured text with custom password fields.
>
> Backward compatibility issues will exist unless AT vendors can patch old
> code or we create a custom password role in the AAPI mappings that allows
> for a fallback to a text field which would be as insecure as the situation
> is now where the user may or may not determine that they have a password
> field and the text typed is spoken.
>
> >>
> >> Our solution thus far actually narrows it for screen reader users.
> >>
> > No, I'm sorry, it doesn't. It changes the security risk, it doesn't
> narrow
> > it down. If anything the uncertainty factor makes it a much more serious
> > problem.
> >
> > The updated role definition is a step in the right direction, but Jamie
> Teh
> > raises some valid points.
> >
> > We need to hear from other SR vendors including Apple, Dolphin and
> > GWMicro/AISquared, and it would be helpful if we could point to wherever
> > Freedom Scientific and others have expressed their commitment to
> > implementing the role as described.
> Apple has been copied but has not weighed in. They are a part of the ARIA
> WG.
>
> I will ask Freedom to give you their response on the list.
>
> I have a to-do to reach out to other vendors - previous post. Dolphin and
> GW Micro were on my list to reach out to. However, it is impractical to ask
> the working group to reach out to every vendor possible. For example, their
> are screen reader vendors in Japan. As chair I am going to draw a line
> there. We need to prove 2 implementations and although this is not a MUST
> statement I think for security we should try to get 2 implementations
> regardless. More than that is beyond what is required by the working group.
>
> The
>
>
> >
> >> I asked Cynthia to reach out to Microsoft as I felt their browser team
> > would
> >> be more experienced in dealing with browser security issues than an
> > interest
> >> group. That said, who do you recommend I ask in the security ig? Are
> they
> >> active?
> >
> > Wendy offered a review by WebAppsSec. Perhaps we could take her up on
> that
> > offer?
> >
> > Léonie.
> >
> > --
> > @LeonieWatson tink.uk Carpe diem.
> >
> >
> >
> >
>
>


-- 
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion