Re: Accessible authentication and we need a fundamental change

>>As someone that has over 15 years experience in the UX/UI space but not
much experience in the authoring of Success Criteria I would like to be
part of a collaborative effort that brings more diversity to this
initiative.

I wrote up an article that I thought might help some of us with less
experience with writing Success Criteria... of course it is from my
perspective, not anything official, of having written, worked on, and
taught about SCs over the years...

It also has advice from Loretta and Gregg, previous chairs of WCAG 2.0, and
is updated for unity with our current consensus acceptance criteria.

http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html




Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Wed, Feb 1, 2017 at 3:30 PM, Thaddeus . <inclusivethinking@gmail.com>
wrote:

> I support Lisa's sentiment here. I joined the COGA Task Force specifically
> to give more visibility to the Cognitive Disability space. While I
> understand that the process of creating a standard of this magnitude has
> significant challenges and requires significant work I am also aware that
> the industry of digital accessibility, which I am a part of, does not
> represent in a robust way the disability that has impacted my life the
> most. As someone that has over 15 years experience in the UX/UI space but
> not much experience in the authoring of Success Criteria I would like to be
> part of a collaborative effort that brings more diversity to this
> initiative.
>
> Best,
> Thaddeus
>
> On Feb 1, 2017 10:53 AM, "lisa.seeman" <lisa.seeman@zoho.com> wrote:
> >
> > Hi Alister and Andrew
> > I am not saying we appropriate should add things that are not feasible.
> That would be daft. We agree that things need to be clear, testable etc.
> >
> > With the proposed change to the survey, we are effectively saying "we
> need to include this user need, AND we also have to solve these issues with
> it"
> > That should be the approach of a first working draft. Removing or
> rejecting SC that address a real user need must be the last option after we
> have tried our very best to find a way to  include it within WCAG's
> criteria.
> >
> > It is much better then labeling things at risk, and will change the
> focus from vetting SC's to finding ways to make them work within the
> constraints of WCAG. It also maintains our timelines.
> >
> > The context here is important. Most of the coga task force are experts
> in the disability, not in drafting success criteria. We assumed we would
> feed our expertise into the wider group who who then try and make it  for
> the standard. We did not build the taskforce with the understanding that we
> would need to churn out ready to go SC with three month warning.   With two
> notable exceptions (thank you Andrew and Rachel) the SC managers for the
> coga SC are from the task force and are not used to making SC's. The
> attitude of vet and throw out does not work and we will get a standard that
> does not include people were we could include them within our constraints
> with thought, and a bit of flexibility.  We need to put our heads together
> on these user needs and SC's and make them work.
> >
> >
> > All the best
> >
> > Lisa Seeman
> >
> > LinkedIn, Twitter
> >
> >
> >
> >
> > ---- On Wed, 01 Feb 2017 18:17:08 +0200 Alastair Campbell<
> acampbell@nomensa.com> wrote ----
> >>
> >> Lisa wrote:
> >>
> >> > My 2 cents is if these  COGA SC (Such as Accessible authentication)
> do not go in, then WCAG 2.1 cannot be the recommended specification for
> inclusion,
> >>
> >>
> >>
> >> There is another side though: Creating requirements that organisations
> cannot fulfil means the guidelines are rejected as infeasible. I’ve seen
> this happen for things like media alternatives already. “Ach, we can’t
> fulfil those criteria, so we’ll take our chances.” and once that happens,
> they don’t worry about the other requirements either.
> >>
> >>
> >>
> >> It is a difficult (sometimes impossible) balance that your next point
> is key to:
> >>
> >>
> >>
> >> > we need to change the focus from saying no to finding solutions to
> make this work and include them.
> >>
> >>
> >>
> >> Absolutely, the key to a feasible requirement is being able to say:
> “and here is how you fulfil it.”
> >>
> >>
> >>
> >> So for the authentication one I was really struggling. I follow
> security issues quite closely, not enough to write an encryption algorithm,
> but enough to know that trying to do so would be a bad idea.
> >>
> >>
> >>
> >> I really struggled to work out what a ‘standard’ solution would look
> like for many websites. The username/password (for all its problems) is the
> default, and it appears to say that shouldn’t be the default. I’ll read
> more, including the spec you linked to, but it is difficult to justify a
> requirement without there being  “Accessibility Supported” solutions, i.e.
> having user-agent and server-side support.
> >>
> >>
> >>
> >> NB: It is different to the inclusion of ARIA in 2.0: That was one
> possible way of doing certain widgets on a page, you didn’t have to use it.
> Logins are on many sites now, so making the standard login non-conforming
> is a big deal.
> >>
> >>
> >>
> >> Regarding the ‘to-do’ actions you suggested, that’s fine, we just need
> to establish now that it is possible to create them. If there isn’t a
> widely used technology to create a technique with, that’s a problem.
> >>
> >>
> >>
> >> That isn’t necessarily a barrier for FPWD, but it would make it an
> at-risk SC.
> >>
> >>
> >>
> >> Cheers,
> >>
> >>
> >>
> >> -Alastair
> >
> >
> >
>