<AWK> +AWK

<AWK> Scribe:Mike_Gower

TPAC

<laura> +Laura

AWK sent email this morning that contains links to TPAC

Look into flights. Our days are Monday and Tuesday. Wednesday session is useful for newcomers. Thursday ACT and LV TFs meeting.

Accessible Authentication: https://www.w3.org/2002/09/wbs/35422/COGA_Auth/results

Lisa: Two-step authentication is inaccessible.

LS: Sites can conform using w3c specification.
... A lot of sites won't confirm because the processes they use aren't accessible. They need to create an alternative

<lisa> https://www.w3.org/TR/webauthn/

John Foliot: Concern raised in issue thread about 2-step authentication for banking organizations. This is a requirement. Not addressed

<lisa> https://w3c.github.io/coga/issue-papers/privacy-security.html

JF: Difference between high-security authentication (for medical/legal/financial transactions, e.g.) versus simple authentication. If addressed, it would mitigate concerns

LS: DIdn't know there was a mandate for two-step authentication. Need an exception for that.
... What's wrong with finger prints?

JF: There is a group that would not meet any specific biometric requirement.

<alastairc> Email is one of the key services that should have two step authentication, reseting your password every time is not possible there.

JF: The language does not address these nuances. I agree with the need, but it is prescriptive as is.

LS: We can clarify in the write-up. All we're asking for is an alternative.

Jason: Has list of issues. Won't summarize now. All in survey.

<lisa> alister they can be 2 set, there just al;so should be something e;se that we can use or at east that we can reset

Jason: Everyone agrees we need to move past password authentication. We need to maintain security. W3C is seeking to standardize APIs in this area. This is a problem of timing. When are all these accessible authentication mechanisms that offer high security going to be available?
... comments about ambiguities and lack of clarity. Suggested changes. OVerall view is that security implications need to be very understood.
... creating situations that would create vulnerabilities puts large numbers of people at risk.

<AWK> gowerm: wanted to raise that there are a lot of things raised in issues that are not addressed in this version

<AWK> ... would like to see things like "minimal levels" addressed

<Zakim> AWK, you wanted to ask about "recalling" and "copying"

<alastairc> So if passwords and copying numbers are not used, what would the two factors be?

Mike Gower: Address all the issues flagged in the comments.

<JF_> but is it as secure?

<alastairc> SMS is being phased out, it is too easy to take over someone's phone line.

AWK: The SC seems to cover a lot of ground. There is no exception for copying information.

LS: If you have an employee ID number, that might be fine. Or a social security number.

<alastairc> SMS not secure: https://www.theregister.co.uk/2016/12/06/2fa_missed_warning/

AWK: There's no expectation that anyone is going to remember their password?

LS: Correct.Many people just write it on a piece of paper.

<alastairc> Lisa: what would two valid methods be for two factor that any website can use?

AWK: If sent to email, you're going to have to log in to your email. If sent to your phone, you may have to authenticate to your phone.

LS: Mike's point is a good one. Maybe we can have a minimum string length. She will get back to the group.
... To Jason's point, places with secure envrionments use smart cards. They've been around a long time. So there are technology solutions out there.

<alastairc> They are given the laptops by work, how does a random website do this for any person??

LS: Our job is to say 'you have to use some of the solutions out there'
... Discussed with security people. SC wasn't written in a vacuum.

<Zakim> JF_, you wanted to ask if we have consulted with the w3c security WG?

JF: I would like to see a review from the W3C security team. We need their input and guidance.
... Splitting into low risk and high risk seems like a good approach.

Jason: The standardization is well-behind the actual technology. There's a timing issue to be looked at, as well as other issues in my comments.

LS: I'm not the SC manager.

<alastairc> there needs to be a common / possible method though!

RESOLUTION: Leave open

User interface Component Contrast: https://www.w3.org/2002/09/wbs/35422/Top3_18Apr2017/results#xlvt

<Glenda> https://www.w3.org/2002/09/wbs/35422/Top3_18Apr2017/results

Alastair: Doesn't object to 3:1, but wants an editorial note saying this needs research to support.

<Glenda> +1 to adding an editorial note about considering 3:1 or keep 4.5 :1

Jason: Are there contrast requirements around the state of the control, not just the boundaries of the control?

Glenda: You need to be able to do more than just see the control. You also need to see state. Does it have focus? Is it unselected? That is an essential understanding of that control.

Jason: I read the proposal as not covering that. You need to be clearer.

<steverep_> Needs to be changed to simply: "Essential visual identifiers of user interface components have..."

Glenda: That is a really good point.

<Glenda> essential visual identifiers of a user interface component have a contrast ratio

<JF_> +1 to adding or incorporating role and state, suggest also adding focus

Jason: Needs to be clear in a definition or glossary.

Glenda: Do we do it in the SC or the glossary term?

<Zakim> AWK, you wanted to ask about the relationship to the "do not rely on color alone" SC 1.4.1

AWK: What does the LVTF see as the connection between Use of Color and this SC?
... Need to address the difference and potential conflict between these.

Glenda: Don't use color alone is valid AND you also have to have a certain level of contrast to be able to see it.

<alastairc> Taking example of a highlighted tab, it would fail 1.4.1 if there was no semantic info behind it. It would fail contrast because people couldn't perceive it.

<AWK> Gower: bringing in other things like selection and states makes it much more complicated

Mike Gower: Differences in state also have contrast requirements, not addressed in this SC

<Zakim> JF_, you wanted to also confirm that this SC covers the use of "icons" (graphical indications that aren't text) - i.e. the light-gray "printer icon"

Glenda: Correct. Imagine that a selection state of a buton is light gray, but the non-selected is white. Is the contrast difference between the two states unsufficient.

<alastairc> JF - I think that would be the general graphics contrast SC unless it's a link. Hmm, and if it is it might be under both!

<Zakim> steverep_, you wanted to answe Andrew's question

Steve: Agree that 1.4.1 use of color versus Contrast minimum has same relationship.

<JF_> @alastair - ya... this is complex. There is both seeing the control in any state, and also seeing *which* state it is in

Steve: Bringing in talking about states is making it more complicated than it needs to get. It's just about seeing it.

<AWK> Or would checkboxes and radio buttons be covered by the "graphical objects" language?

<Zakim> Greg, you wanted to say If we keep this, I like Steve’s (?) proposal of addressing visual indication of role and state, but add label (e.g. text or icon identifyiing the purpose

Steve: This isn't about recognizing differences in state. It is about seeing it in any state.

<Greg> Role and State are not enough, as you need label (e.g. text on a button).

<steverep_> That's already part of the component

AWK: Text is already covered by another SC.

<Greg> You believe that everything labeling/identifying a control is already covered, by which SC?

<Greg> Apologies that my phone is misbehaving.

Glenda: Difference between Alastair's SC and mine is that the author created the object from scratch, whereas user interface component is either created by the browser or monkeyed with using CSS.

AWK: So user agent default is exempted as long as author is not overriding.

<steverep_> Note we've also filed bugs with all browsers

Glenda: Let's fix user agent contrast issues with UI components with the vendor.

<Greg> I agree; I proposed the exception for presentation that's fixed by the UA (e.g. standard controls) for another SC, and it would apply equally here. We want a properly-designed, vanilla HTML form to conform by default.

<Greg> I prefer "does not" rather than "cannot" be modified by the content, because the content cannot be programmed to account for bugs in every different UA. Otherwise we'd be forcing every page to use custom controls instead of standard ones, and that is obviously counter-productive.

<steverep_> We can say "are not OR cannot" but I think the existing language is enough

All essential visual identifiers that indicate that a user...

<JF_> +1 to "indicate" - I had added that to my comments as well

<Greg> Also, the user is assumed to have the ability to choose their UA to one that is most accessible for their needs.

Jason: graphic contrast proposal needs to be looked at carefullly. Consider combining

<Glenda> essential visual identifiers of a user interface component have a contrast ratio

<alastairc> But this one applies to HTML elements, the other is for graphics.

Jason: Interactive versus non-interactive or whether made or stock don't really bear on contrast requirements

<lisa> need to drop now

<Zakim> steverep_, you wanted to say it would be better to have browsers do it

Glenda: I agree, but the time to combine isn't now. Intricate enough that they should be addressed separately. For clarity and accuracy keep separate to make sure not losing anything. Consider combining after making it through public review.

Steve: If we require authors to do it, they all do it differently. If require UAs, it is done uniformly.

AWK: Some risk the user agents will do nothing.

<JF_> bye all

trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/high-security authentication versus/high-security authentication (for medical/legal/financial transactions, e.g.) versus/
Succeeded: s/mitigatte/mitigate/
Succeeded: s/eitehr/either/
Default Present: AWK, JF, ChrisLoiselle, Detlev, Rachael, Greg_Lowney, Joshue108, Glenda, MikeGower, steverep, Laura, jasonjgw, alastairc, allanj, Kathy, shadi, lisa
Present: AWK JF ChrisLoiselle Detlev Rachael Greg_Lowney Joshue108 Glenda MikeGower steverep Laura jasonjgw alastairc allanj Kathy shadi lisa
No ScribeNick specified.  Guessing ScribeNick: gowerm
Found Scribe: Mike_Gower
Found Date: 15 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/15-ag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.