Hi @alastc ,

3 headings in the Understanding Doc refer to "Focus Visible" instead of "Accessible Authentication":

1. Benefits of Focus Visible
2. Examples of Focus Visible
3. Techniques for Focus Visible

The understanding document focuses exclusively on login type scenarios

The purpose of this success criterion is to ensure there is an accessible, easy-to-use, secure method to log in and access content.

what about more general situations where a CAPTCHA is presented? for instance, posting a comment on a blog - and the form may include a CAPTCHA there? while some aspects of this scenario will be already covered by other SCs (e.g. 1.1.1 for those "type in the scrambled text you see here" type scenarios for instance), others won't. and while i agree (and i believe, discussed at length in the past) this type of thing is not "authentication" per se, it would be good to cover this more broadly as a requirement for cases other than logins.

also noting that just the email example as a technique essentially doesn't allow two-factor authentication (as emails are not generally secure enough)

Thanks for catching the headings & email typo.

what about more general situations

I remember the comments, but no one has been able to come up with a useful scope. The key scenario the TF were interested in was logging in, so that was the focus.

Widening it to any process could capture a lot of scenarios, and I don't think anyone has investigated what those would be.

just the email example as a technique essentially doesn't allow two-factor authentication (as emails are not generally secure enough)

Hmm, from a security point of view most systems allow you to change your password via email, so I wouldn't say it is "not secure enough" as a general statement.

That technique could be combined with a 2nd factor, we didn't want complicate it, but you could have a 2nd factor after the email link logs you in as a first factor.

There is another technique (to do) about combining the other techniques as part of 2 factor auth.

the current wording of the normative SC could also apply to scenarios not tied to login (and in the understanding, "a task" could be posting a blog comment). basically, that an alternative is available. might need expanding from "authentication" to something more like "authentication and verification".

separately, would be good to have a normative definition of "authentication process" perhaps?

Hmm, from a security point of view most systems allow you to change your password via email, so I wouldn't say it is "not secure enough" as a general statement.

Sensitive systems (e.g. banking) do generally require a second factor. Be it an SMS sent to you with an access code (that you then have to type in/copy ... is that allowed under the wording of this SC?), using a physical card reader where you put in your bank card, or similar.

That technique could be combined with a 2nd factor, we didn't want complicate it, but you could have a 2nd factor after the email link logs you in as a first factor

The 2nd factor would be at some point before allowing the user to change the password in the first place. The link takes you to the second challenge before letting you go an actually change the password and log in.

I just want to make sure this SC doesn't (inadvertently) try to force less secure solutions