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

Rich Schwerdtfeger




> On Apr 2, 2016, at 10:55 AM, John Foliot <john.foliot@deque.com> wrote:
> 
> > 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 <http://www.afb.org/ProdBrowseCatResults.asp?CatID=49>)
I am not sure what you are asking for the browser to get board with. Do you mean mapping the role? Do you mean obscuring text when author claims it is a custom password field?


> > 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.
> 

We have heard your input. I will ask to get support from 3 vendors. What we are asking for we already implemented in Screen Reader/2 and Screen Reader for Java - these products only spoke what was rendered and that includes for non password text fields. I am not using those for the example ATs but I already know this is doable. 

Joanie has committed to do it for Orca. I told Leonie I would work to get commitment from Freedom Scientific. 

What I am concerned about and not a single person complaining has failed to address is text fields which are password fields but which the ATs always echo the characters typed which creates a security hole. I need the people who have issues to come up with a solution for that. This is one issue we are trying to resolve. I feel the group has adequately addressed the issue providing we get more than 2 AT vendors to agree to support it. This goes above and beyond what W3C requires especially given that these are SHOULDs. 

> 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.
> 

John,  My point is that we don’t have enough bandwidth to canvas all the the possible screen reader vendors in the world. Leonie had given quite a long list of screen reader vendors. Also, some of these may require people to pay them to implement it. I have gone through that process. It is expensive. Since you want more than 2 implementations would you be willing to help us get them like working with Apple and NVDA? 

I will be reaching out to Freedom Scientific and AI Squared. Joanie has said she would implement it in Orca. Microsoft has found no security issues with the role so I see no reason why Narrator will not support it as part of their ARIA 1.1 support. If they agree that makes 4. You had asked for more than 2. 

Rich


> JF
> 
> On Sat, Apr 2, 2016 at 7:34 AM, Richard Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com>> wrote:
> 
> > On Apr 2, 2016, at 6:37 AM, Léonie Watson <tink@tink.uk <mailto:tink@tink.uk>> wrote:
> >
> >> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com <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 <http://tink.uk/> Carpe diem.
> >
> >
> >
> >
> 
> 
> 
> 
> -- 
> John Foliot
> Principal Accessibility Consultant
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
> 
> Advancing the mission of digital accessibility and inclusion