Re: Accessible authentication and we need a fundamental change

Hi Alister and AndrewI 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