- From: Rich Schwerdtfeger <richschwer@gmail.com>
- Date: Mon, 25 Apr 2016 10:32:00 -0500
- To: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Cc: tink@tink.uk, Rich Schwerdtfeger <schwer@us.ibm.com>, public-aria@w3.org
- Message-Id: <D29B2BA9-C0E9-4C98-B4E5-65401F917FF3@gmail.com>
We don’t necessarily need to create a new aria attribute. We simply provide a new attribute in the platform mapping that does it automatically. This way, if they forget the additional attribute and they simply put role=“password” then it just maps automatically. Rich Rich Schwerdtfeger > On Apr 25, 2016, at 9:56 AM, Birkir Gunnarsson <birkir.gunnarsson@deque.com> wrote: > > I am much more onboard with the idea if we add the “aria-custom-password” attribute along with the password role. > > > From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] > Sent: Monday, April 25, 2016 9:35 AM > To: tink@tink.uk > Cc: Rich Schwerdtfeger <schwer@us.ibm.com>; public-aria@w3.org > Subject: Re: Password role proposal: Freedom Scientific response > > I would agree with that statement. Security should be what is important. > > I would interpret this is that if the ARIA spec. says ATs SHOULD expose the rendered text vs. the star star star approach then we should expect them to do that in the future as they have publicly committed to supporting ARIA. > > If it is not in the ARIA spec. we may never see it in JAWS. > > This is our opportunity to get them to do things correctly by putting it in the ARIA spec. One thing we might do, however, is to also expose an additional attribute at the platform layer to indicate these are custom password roles. > > This would address some of John’s concerns about not knowing that this is a custom password field. It will require changes in AT behavior and end-user education. > > Thoughts? > > Rich > > > Rich Schwerdtfeger > > > > >> On Apr 25, 2016, at 3:32 AM, Léonie Watson <tink@tink.uk <mailto:tink@tink.uk>> wrote: >> >> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com <mailto:schwer@us.ibm.com>] >> Sent: 22 April 2016 19:30 >> “Following up on Leonie's request to contact ATVs. I contacted Freedom Scientific's CTO regarding the changes we have put in the ARIA password role regarding what ATs should do in response to speaking the actual text rendered. >> >> Statement from Glen Gordon at FS: >> Freedom Scientific actively embraces ARIA. We recognize that this is an evolving standard and do our best to support newly added items in a timely fashion.” >> >> Thanks for following up on this Rich. I understand that FS is reluctant to commit to a particular course of action, and I daresay they wouldn’t be the only ones if we were to reach out to other proprietary screen reader vendors. >> >> “They have a policy to not commit to dates or product features publicly so this is as good as it gets.” >> >> A commitment to implement the password role is understandably something FS might be reluctant to provide, but a general commitment to protecting consumer security would have been better than this. >> >> As things stand we do not have a clear commitment from any screen reader vendor other than Orca, that the password role will be implemented in a secure way. This is troubling. >> >> >> Léonie. >> >> -- >> @LeonieWatson tink.uk <http://tink.uk/> Carpe diem
Received on Monday, 25 April 2016 15:32:28 UTC