Re: Accessible authentication and we need a fundamental change

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.

AWK: it sounds like what you are proposing is to add user needs to WCAG first, even if just as an aspirational statement, and then make sure that we have a success criteria that works as needed (e.g. Testable, etc). I don’t think that gains us much since we already have that in the form of SC proposals. When the SC proposals are vetted by the whole group and we believe that they are defensible, then they get added to the WCAG 2.1 editor’s draft.

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.

AWK: I think that your first point is more of a matter of perspective than anything. I strongly believe that everyone in the group is trying to find ways to make new SC that help people work. We do have many pragmatic people in the group though, and that is helpful even if sometimes frustrating. I don’t see how it maintains the timelines any more than the current model does.

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.

AWK: The group is working on the SC, and the process is messy. Many of the COGA proposals are as difficult as any the group has seen, so please don’t expect the process to be easy.

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.

AWK: lets put our heads together then. Please do understand that sometimes people commenting can’t offer replacement text for a concept that they view as untestable or problematic for some other reason. If an SC manager needs help or is confused about what to do when consensus isn’t emerging, Josh and I are happy to advise.

AWK



---- On Wed, 01 Feb 2017 18:17:08 +0200 Alastair Campbell<acampbell@nomensa.com<mailto: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