<laura> Scribe: Laura

<Sukriti> I can scribe for the 2nd hour

Chuck: Any introductions?

<Detlev> can't hear well, lots of noise

Juliet Mc Shane: provided an intro.

David Middleton: provided an intro.

Chuck: welcome. And thank you.

Training day for writing WCAG 3.0 content

<AWK> +AWK

CFC for WCAG 3.0 update

Chuck: Silver group is ramping up to provide training.
... publishing will be before the end of the year.

WCAG 2.2, Accessible authentication issues (Questions 1-7): https://www.w3.org/2002/09/wbs/35422/wcag22-accesssible-auth-updates/

MC: could be longer if we cannot remove the objections.

<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-accesssible-auth-updates/results

Question 1 - Add mechanism text #1418

Chuck: 7 questions in this survey.

Sukriti: minor editorial regarding a coma

Michael Gower: I think "must be" is a bit out of alignment with how we'd normally construct this. Why can't it just be "is", to read: "...or a mechanism is available to assist..."

DM: agree with that.
... it is the passing condition for this test.

<alastairc> any problem with that AWK?

Awk: I think that is fine.

MG: I found the note a little hard to parse
... I _think_ this is how it was meant, and recommend adding the numbering:

"Note: Examples of mechanisms include: 1) support for password entry by password managers to address the memorization cognitive function test, and 2) copy and paste to help address transcription cognitive function test.

Chuck: AC has made the changes.

<AWK> +1

<Sukriti> +`

<Sukriti> +1

<Nicaise> +1

<DavidASx> +1

Laura: +1

<sarahhorton> +1

<Raf> +1

<Francis_Storr> +1

RESOLUTION: Accept the suggested text available in PR 1505 to address issue #1418.

Question 2 - Accessible Authentication #1318

MC: There's something not quite right in the language. Should it be something like the following?
... "With the changes linked to above, and the comments in the thread, we believe the working group has resolved / answered the issues you raised."

<mbgower> +1

<Nicaise> +1

Laura: +1

<Sukriti> +1

<Francis_Storr> +1

<DavidASx> +1

<sarahhorton> +1

<david-macdonald> +1

<Detlev> +1

<kirkwood> +1

RESOLUTION: Accept Alastair's modified draft response to issue #1318

Question 3 - Clarify whether copy/paste is a cognitive function test #1359

chuck: Everyone agreed with the change

<Nicaise> +1

<DavidASx> +1

<AWK> +1

Laura +1

<Sukriti> +1

<sarahhorton> +1

<JustineP_> +1

<david-macdonald> +1

<Francis_Storr> +1

<Raf> +1

RESOLUTION: Accept the accepted change in PR 1419 to address issue #1359

<mbgower> +1

Question 4 - Far too fundamentally restrictive for a Level A #1364

Chuck: everyone agreed with the response on the survey.

AC: This has been a common theme.
... it takes a bit a bit information about accessibility as well as security.
... security teams should review.

Chuck: that is a side request.

AC: yes, that is above and beyond.

<Nicaise> +1

<DavidASx> +1

Laura +1

<Juliette> +1

<Ryladog> +1

<Detlev> +1

<kirkwood> +1

<david-macdonald> I'm not sure... I'm going to pull in some security people from some of the compaines I work wth

<david-macdonald> ok

AC: David that is great.

RESOLUTION: Accept Alastair's draft response to issue #1364

Question 5 - Concerns and clarifications #1470

Chuck: simonrjones created github issue 1470 with similar concerns as 1364.

<Ryladog> +1

<Detlev> +1

<DavidASx> +1

Laura: +1

<Juliette> +1

<sarahhorton> +1

<Raf> +1

<morr4> +1

RESOLUTION: Accept Alastair's draft response to issue #1470

Question 6 - Conflict with legal and contractual obligations #1430

Chuck: KimberleeD (on behalf of Thomson Reuters) created github issue 1364 about having current contracts which need to be fulfilled.
... no objections on the survey.

<alastairc> https://github.com/w3c/wcag/issues/1430

<ChrisLoiselle> https://www.w3.org/2002/09/wbs/35422/wcag22-accesssible-auth-updates/results#xq12 is Kim's

<Ryladog> +1

<DavidASx> +1

<Nicaise> +1

AC: It is more of a side point.

<morr4> +1

<sarahhorton> +1

Laura: +1

<Detlev> +1

<Sukriti> +1

RESOLUTION: Accept Alastair's draft response to issue #1430

<Jennie> +1

Question 7 - Feedback from Google #1452

chuck: dshoukry from Google raised a number of issues in her document linked from issue 1452.
... In response there are some updates in PR 1508, and a response in the thread.
... MG said, "I do think "federated identity" is a useful context to provide in the Understanding document. So I although I agree it shouldn't have been added in the paragraph on copy/paste, I would like to see it incorporated."

AC: document provided a lot of small points.
... think I got through to most of them. It is a first pass.

<kirkwood> +1

<Detlev> +1

<Nicaise> +1

<Ryladog> +1

<DavidASx> +1

<sarahhorton> +1

Laura: +1

RESOLUTION: Accept Alastair's draft response to issue #1452 and accept PR 1508.

WCAG 2.2, Focus-appearance (Questions 1-7): https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/

<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results

Chuck: this is a new survey.

Question 1 - Must a focus indicator always be displayed? #1387

Chuck: JAWS-test raised issue 1387 about focus indicators fading out or otherwise not being permanent.
... Alastair added an updated response,
... 11 agreed 2 wanted something else.

Jake: about: "When user interface components has keyboard focus..." and remove the unobscured bullet, OR"

This is not per se needed as we can mention the 'default' load/state in the wording, like:

scribe: "Not fully obscured: The item with focus is not entirely hidden by author-created content in the initial / default state"
... or mention an action done by a user, like: "Not fully obscured: The item with focus is not entirely hidden by author-created content unless obscuring is done by a users action"

Jake: don't think the 2 has to go together.

<Detlev> +1 to Jake's proposal

Chuck: Gundula agreed with Jake.

Gundula: I agree to Jake's suggestion to change the unobscured bullet point to "Not fully obscured: The item with focus is not entirely hidden by author-created content unless obscuring is done by a users action".
... I suggest to also change 'receive' into 'has', as this would cover a fading focus indicator (as not allowed) and other cases. Also it might ease or even end discussions about a focus indicator with initial micro animation. 'has' rather refers to the state when transferring the focus is done.

<Detlev> +1 to Gundula too

<Ryladog> +1 to Gundula

<Chuck_> "Not fully obscured: The item with focus is not entirely hidden by author-created content unless obscuring is done by a users action"

<AWK> 2.4.7 ensures that the focus will be visible, a fading focus would have problems there

AC: this comes down to how the criteria is started.

<Ryladog> Receive and maintain unless user?

AC: leaves an opening for fading but not completely.

Katie: when it receives and maintains focus unless the user changes it.

MG: original issue was satisfied.
... looking at the causes. It is there for a reason.
... this is an outlier case.

Chuck: are you saying this is a rabbit whole?

MG: yes.

<Ryladog> I rescind my comment based on Mike G explanation of other SCs covering the persistance

AC: This isn't a big issue in practice.
... consider the focus Indicator in default state.
... but when we bring in the last bullet, it gets complicate.
... It can open up a different hole.

Detlev: "unless it caused by user action" may help.
... we can separate it clearly. Don't see a big problem.

<Zakim> Chuck_, you wanted to ask fading focus would already be an issue for 2.4.7 and 1.4.11

DM: concerned about sticky header/footer. Want to insure a working model.
... does that map to this?

AC: different issue.
... concerned about "has" or "receives".
... probably need to come back to this one.

MG: If we can reword the 4th bullet, It may work.
... gets to be wordy.
... maybe take it offline and work on it.

RESOLUTION: Review and return with a modified response for the group to review.

Question 2 - Consider distance between component and indicator #1382

Chuck: Jym77 asked in Issue 1382 whether we should define how far away a focus indicator could be?
... Detlev created draft response
... Wilco wanted something else. He said, "This response is conflating "focus" with the "focus indicator". I don't have a problem with the implication that Jean-Yves points out here, that focus indicators can be in a different place than the UIC that is focused. I would suggest we acknowledge that as a limitation of the SC."

<alastairc> Suggest update to "The glossary definition of focus explains that it is the "point where the user’s input interacts with the web page". This implies that the focus indicator is near or around the element in focus."

<alastairc> Adding "indicator" to the second part.

Chuck: Michael Gower said, "I'm not sure the second sentence is necessary"
... The first sentence covers it, I believe.

AC: Suggest update to "The glossary definition of focus explains that it is the "point where the user’s input interacts with the web page". This implies that the focus indicator is near or around the element in focus."

<Detlev> We can lose the second sentence I think

<Ryladog> +1

<Detlev> +1

Laura +1

<morr4> +1

<Sukriti> +1

<sarahhorton> +1

<Sukriti> I can do it

RESOLUTION: Accept Detlev's amended draft response to issue #1382

Question 3 - Does a change of background pass Focus Appearance (Minimum) #1278

Chuck: lchandelier raised issue 1278 about borders vs backgrounds and whether they pass.
... Alastair added a couple of examples to the understanding document in PR1495

MG: What is "which has a large area" qualifying? I'm also not clear whether background is being used here as synonym for the fill of the control itself, or the adjacent page background color. Is this approaching what is being conveyed?

<Zakim> Chuck_, you wanted to ask about scribe change

<Sukriti> scribe:Sukriti

AC: Change of wording on the first part, doesn't change meaning

Suggested by Michael

gundula: would like to see examples

AC: shares visual examples

<alastairc> https://github.com/w3c/wcag/issues/1382#issuecomment-724832420

AC: response is posted on 1382 and we can come back to it

<Chuck_> proposed RESOLUTION: Accept amended PR 1495 to address issue #1278

<Ryladog> +1

<DavidASx> +1

<laura> +1

<sarahhorton> +1

<JakeAbma> +1

<JustineP_> +1

RESOLUTION: Accept amended PR 1495 to address issue #1278

Question 4 - Example 2 for G195 is too inaccurate #1305

<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results

Chuck: Gundula's comments on 1305 and PR 1496

<alastairc> https://w3c.github.io/wcag/techniques/general/G195

Gundula: Contrast on unfocused state should also be included in G195, example 2

AC: Might want to include a visual example to the technique
... Two alternatives 1. Clarify example 2. Provide visuals

Chuck: Not mutually exclusive?

AC: No

I can do it

haha

<Detlev> good stuff

RESOLUTION: Update the second example to include visuals and review later.

<Detlev> thumbs up

<scribe> ACTION: Sukriti to provide visual examples for G195

<trackbot> Created ACTION-346 - Provide visual examples for g195 [on Sukriti Chadha - due 2020-11-17].

<alastairc> https://github.com/w3c/wcag/pull/1496

Chuck: Adding the color codes for now (AC) and later adding visual examples (SC)

Question 5 - UPDATED: Exception for the default focus indicator? #1341

Chuck: David's response

David: Impact on development teams. We should allow if the browser is doing the work and if the author doesn't interfere with that
... Example of sighted keyboard user who sometimes grabs a mouse

AC: Originally came from non-text contrast and would agree if browsers were more consistent
... Lots of cases where mix of author actions + browser actions that for a user there isn't a sure way of getting a good focus indicator

<DavidASx> I agree with David that it should fall on the Browser if nobody has interfered with the indicator. It allows indicators to improve without changes required to sites to incorporate them.

Gundula: At the end, the user should be able to work with a keyboard only

<alastairc> DAvidASx - that's what we've had for years, and yet there are so many examples where default browser indicators are not (usefully) visible.

<alastairc> Lots of examples: https://adrianroselli.com/2017/02/avoid-default-browser-focus-styles.html

Mike: The scenario should pass on browsers that meet the criteria

David: 2 color - inside and outside
... That's why was looking for exception

Mike: Visual examples?

Chuck: Clarifying the requirements with an example

AC: Would need to make sure the browser defaults are visible in your scenario

Jonathan: Would an offset not solve?

Mike: Write up as a sufficient technique?

<DavidASx> I see David's point but will not object to moving forward with the majority.

<jon_avila> Example demonstration to push the default outline from the button <button style="color: white; background-color:black; outline-offset:

<Ryladog> +1 to Alastair

AC: Should allow for good browser defaults but cannot always count on it

Chuck: is the alternative technique a third option?

AC: in line with existing SC with an additional technique

<GN015> +1

<Ryladog> +1 to not having an exception

Melanie: There should be an exception for default focus indicator

<Ryladog> It would be better to be a browser requirement - but it isnt so we need to fix this - and Desingers and Devs have been successfully coding this for year - it is nit a heavy lift for them

<kirkwood> +1 to Melanie

AC: Do we agree to the normative text? If not, let's discuss the understanding document

<Chuck_> proposed RESOLUTION: do we agree to an update to the normative text?

<alastairc> adding "except where the appearance of the indicator is determined by the user agent and not modified by the author;"

<ok_> -1

<david-macdonald> This article is from 2017 before any browser default indicators. were two color https://adrianroselli.com/2017/02/avoid-default-browser-focus-styles.html

<sarahhorton> -1

<Ryladog> -1

<jon_avila> -1

<alastairc> -1

<MelanieP> +1

<DavidASx> +1

<david-macdonald> +1

<Chuck_> -1 MG

-1

<GN015> -1

<Detlev> Unsure 0

Chuck: Understanding document update

<alastairc> The default focus indicators in some browsers can be difficult to see, such as a 1 pixel dotted outline, or a blue indicator which happens to be on a blue background. It is generally best to either define a keyboard focus style which meets this criterion, or test the focus styles across browsers for your content.

<Ryladog> +1 for adding that text to Understanding Doc

<alastairc> "It is generally best to either define a keyboard focus style which meets this criterion, or test the focus styles across the browsers you rely upon for conformance."

<alastairc> It is generally best to either define a keyboard focus style which meets this criterion, or test the focus styles across the browsers that are relied upon for conformance.

<DavidASx> +1

<morr4> +1

<ok_> +1

<Chuck_> +1

<Ryladog> +1

+1

<GN015> +1

<sarahhorton> +1

<david-macdonald> +1

<Detlev> +1

<MelanieP> +1

<Jennie> +1

<StefanSchnabel> +1

RESOLUTION: Add the proposed text to the understanding document to address issue 1341.

Question 6 - Example calculations do not account for corners #1324

Chuck: Wilco's comment

AC: Inset border would not address the problem because the problem is the corners the inside/ outside

<david-macdonald> Isn't it 37 not 36?

<david-macdonald> 10+9+9+9

<david-macdonald> :()

<jon_avila> What about something like minus shared or overlapping pixels

<jon_avila> yes it does matter

Detlev: Does it matter if it's 4 pixels too many for clarity

AC: If the requirement was saying, we take off a bit from that amount, it is easier to meet

Jon: Shared pixels would account for different sizes. Could have odd shapes. Could instead subtract shared pixels that can't be counted twice

<Ryladog> +1 to Jon (due to other shapes)

<Detlev> +1 to Jon

<kirkwood> for scribing Chuck said: 10+9+9+8

Gundula: This is a rectangle and make it exact, we can make clear that shared pixels cannot count for other shapes

Chuck: Support of the existing formula?

Gundula: Yes

AC: Like suggestion of not including shared pixels

<Zakim> Chuck_, you wanted to ask can we do both?

Chuck: Can we have both 'OR'

DavidASx: Should mention shared pixels should not be counted twice

<alastairc> the continuous line forming the boundary of a shape, not including shared pixels. For example, the perimeter calculation for a rectangle is 2<em>h</em>+2<em>w</em> -4, where <em>h</em> is the height and <em>w</em> is the width and the corners are not counted twice. The perimeter of a circle is 2&Pi;<em>r</em>.

<mbgower> +1

<DavidASx> +1

<Chuck_> +1

<Nicaise> +1

<Ryladog> +1

+1

<kirkwood> +1

<sarahhorton> +1

<Detlev> +1

<david-macdonald> +1

<Jennie> +1

<GN015> +1

<jon_avila> +1

RESOLUTION: Accept amended PR 1498 to address issue #1324

Question 7 - Understanding rewording suggestions #1501

AC: large update. Might want to come back to it next week

<mbgower> https://github.com/w3c/wcag/pull/1501/files

<alastairc> Preview: https://raw.githack.com/w3c/wcag/278914dae961b4af7e9a6fa4987321720e977a8b/understanding/22/focus-appearance-minimum.html

RESOLUTION: Review Michael Gower's changes to PR 1501 next meeting

<alastairc> https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Issue_tracking_and_resolution

<Chuck_> The chairs are considering the objections that have been raised and are reviewing their potential impact on the decision and the impact to the timeline for approving and publishing the FPWD. Publishing is postponed until after Thanksgiving, and the chairs anticipate the FPWD will be published before the end of the year.

<Chuck_> The chairs are considering the objections that have been raised and are reviewing their potential impact on the decision and the impact to the timeline for approving and publishing the FPWD. Publishing is postponed until after Thanksgiving, and the chairs anticipate the FPWD will be published before the end of the year.

This is scribe.perl Revision of Date 
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/unless it it /unless it /
Succeeded: s/recieves/receives/
Succeeded: s/issue Issue /Issue /
Default Present: Laura, Francis_Storr, alastairc, MichaelC, Sukriti, Detlev, ChrisLoiselle, Matt, Orr, Jennie, JakeAbma_, Nicaise, JustineP_, AWK, sarahhorton, `, mbgower, kirkwood, MelanieP, jon_avila, Katie_Haritos-Shea, StefanSchnabel, ok, Raf, Levon, david-macdonald, GN
Present: Laura Francis_Storr alastairc MichaelC Sukriti Detlev ChrisLoiselle Matt Orr Jennie JakeAbma_ Nicaise JustineP_ AWK sarahhorton ` mbgower kirkwood MelanieP jon_avila Katie_Haritos-Shea StefanSchnabel ok Raf Levon david-macdonald GN GN015
Regrets: Bruce Bailey CharlesH
Found Scribe: Laura
Inferring ScribeNick: laura
Found Scribe: Sukriti
Inferring ScribeNick: Sukriti
Scribes: Laura, Sukriti
ScribeNicks: laura, Sukriti

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: sukriti

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)