Re: Accessible authentication and we need a fundamental change

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