Re: Accessible authentication and we need a fundamental change

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