<Rachael> Focus appearance (Questions 1-4 only) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results

<Jennie> scribe: Jennie

<stevelee> eek

Rachael: We are looking for a scribe for the 2nd half

Introductions

Rachael: We have some new members

Katie: I would like to introduce you to Matt Or (not sure of spelling)

Matt: Thank you

Rachael: Are there others here who have joined in the last month?

Dragging Movements (1st question only) https://www.w3.org/2002/09/wbs/35422/wcag22-dragging-issues/results

Rachael: We are focusing on WCAG 2.2
... 3 surveys went out

<AWK> +AWK ...#1: Dragging

Alastair: Detlev put in a pull request to clarify between dragging and gestures
... pointer gestures and dragging
... This one is about the understanding document

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

Alastair: It adds a paragraph to the new understanding document

<david-macdonald> prestn+

Rachael: Any concerns or further conversation?

<Rachael> Proposed RESOLUTION: Approve the changes for issue #1316

<Sukriti> +1

<alastairc> +1

<AWK> +1

<Rachael> +1

<laura> +1

<GN015> +1

<david-macdonald> +1

<MelanieP> +1

<Wilco> +1

<morr4> +1

RESOLUTION: Approve the changes for issue #1316

Pointer Target Size (1st question only) https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results

Alastair: a label can form part of the target

<alastairc> https://github.com/w3c/wcag/issues/1432#issuecomment-714574736

Alastair: I put in a slightly updated version

<Rachael> The definition of target is: "region of the display that will accept a pointer action, such as the interactive area of a user interface component". Therefore if they form one target and if the known user-agents do support making the label clickable, then the label can contribute to the target size.

Alastair: The comments we have had are around the use of "known user-agents"

Rachael: Patrick commented around if it is conventional, but not fully supported, who is responsible

Alastair: I think the comments down to Sarah's are from last week
... These are in the response
... Detlev's is the 1st new comment

Rachael: (Read's Detlev's comment)
... Are there others that agree with Detlev's position?

David M: I understand it is not a perfect measure, but the advantage of using a label is using native HTML

scribe: And the exceptions for checkboxes and radio buttons: then it is 1 more thing to remember
... I think it increases the size significantly
... I think the idea of using labels is a good idea

Andrew K: I agree with David.

<AWK> https://www.w3.org/WAI/tutorials/forms/grouping/#checkboxes

scribe: I was looking at the tutorials - the checkboxes make it hard to meet the criteria without labels
... The text would be bunched up against the checkboxes
... Using the for id or association strategies
... I think it should satisfy it.

Rachael: Anyone want to argue against?

Sukriti: I agree with David and Andrew

Rachael: Andrew also spoke about the known user agent being confusing

<alastairc> AWK's suggested response: The definition of target is: "region of the display that will accept a pointer action, such as the interactive area of a user interface component". If a label and the input form one target and if user-agents support making the label clickable as a mechanism to take an action on a user interface component, then the label's area can contribute to the target size.

Andrew: In the suggested response it talks about known user agents

<jon_avila> I agree with Andrew on all points including user agents, use of label, etc.

Andrew: We know about different user agents - this doesn't indicate if you can do something or not. Supported or not

Rachael: Is there an example of similar language used?

Andrew: I think it is sprinkled through the conformance concepts

<AWK> https://www.w3.org/TR/WCAG22/#conformance

Alastair: I think it was an alternative phrase. And Andrew proposed an update, and I am ok with that as the response

Rachael: Any other conversations around this?
... At this time I'm hearing going with Andrew's suggested revision

<Rachael> Proposed RESOLUTION: Use Andrew's suggested response: The definition of target is: "region of the display that will accept a pointer action, such as the interactive area of a user interface component". If a label and the input form one target and if user-agents support making the label clickable as a mechanism to take an action on a user interface component, then the label's area can contribute to the target size.

<laura> +1

<david-macdonald> +1

<alastairc> +!

<Sukriti> +1

<AWK> +1

<Rachael> +1

<jon_avila> +1

<Wilco> +1

<GN015> +1

<Ryladog_> +1

<mbgower> +1

<morr4> +1

<Raf> 0

RESOLUTION: Use Andrew's suggested response: The definition of target is: "region of the display that will accept a pointer action, such as the interactive area of a user interface component". If a label and the input form one target and if user-agents support making the label clickable as a mechanism to take an action on a user interface component, then the label's area can contribute to the target size.

Focus appearance (Questions 1-4 only) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results

Rachael: Question 1 is about #1341

#1341

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

Alastair: There was a question which started a big discussion. Michael G made an update with things like around user interface components rather than the indicator
... It rewords 3 out of the 4 bullets
... There were various changes to help clarity

Michael G: We were running into problems around when you assessed the focus indicator

<Rachael> Pull request of changes: https://github.com/w3c/wcag/pull/1403/files

scribe: If it scrolls off the viewport
... We want to test before the user could be changing it

Rachael: We had 2 agrees with updates, 3 with adjustments, and something else
... I had the something else
... The rewording focuses on the area itself
... I have a pull request
... The newer wording I found more ambigous

<Rachael> suggested rewording ""The focus indicator is at least as large as the perimeter of the focused control and indicated by a 1 or more <a>CSS pixel</a> border..."

<Rachael> current wording: "The area of the focus indicator is at least as large as the perimeter of the focused control, as measured by a 1 <a>CSS pixel</a> border..."

Michael G: what will be the defined term?

<Rachael> original: The <a>focus indication area</a> is greater than or equal to a 1 <a>CSS pixel</a> border of the focused control..."

scribe: The original one was focus indication area - a defined term
... Do we have issues defining the focus indicator itself?

Andrew: I have a similar concern
... I was suggesting if we keep the area of the focus indicator, and compare it with the 1 CSS pixel thick, then we are comparing area to area

<Rachael> AWK suggested rewording: The area of the focus indicator is at least as large as area of a 1CSS pixel thick perimeter of the focused control, or has a width of at least 8 CSS pixels along the shortest side of the element.

<Zakim> alastairc, you wanted to say that area is a key concept to have, otherwise it's only borders

Alastair: Rachael's rewording, area is a key concept to have
... I think Andrew's rewording does include area

<AWK> The area of the focus indicator is at least as large as the area of a 1 CSS pixel thick perimeter of the focused control, or has a width of at least 8 CSS pixels along the shortest side of the element.

Wilco: It seems that perimeter is a measurement of length, is that correct?

Alastair: yes

Michael G: Which is why it is followed by the 1 CSS

scribe: The way Andrew has reworded it helps

Rachael: Sounds like we are gaining concensus for Andrew's wording

<Levon> perimeter vs border?

Jonathan: We are not talking about the area, we are saying you have to have a indicator of a size

Andrew: That is the 2nd part of my comment

Rachael: Before we move to that section of the conversation, do we feel like Andrew's is a decent place to start?

Michael G: I think you could indicate Jonathan's by saying "the focus indicator"

Rachael: Can someone pull together the changes?

Jake: You had spoken about the 8 CSS pixels
... I thought it was that thickness was changed to width. It could also be the height
... Or the surface area?
... The word "width" may be interpreted the wrong way

<GN015> I have to leave early, sorry.

Jake: It depends on which angle you are looking at "width"

Rachael: You also said we used thickness in a different bullet
... Bruce agrees with the change in principal.
... He's not sure what the fix should be exactly

Andrew: Comment #1 - the way it is read.
... If 40 px tall and 15 wide
... Someone may be able to say they have a focus indicator that covers only a portion of the shorter side
... I think width and height are significant
... I think that is where "thickness" is useful here
... I think what we want to say is that the focus indicator is atleast 8 px on the shortest side, but I think we can handle some of this in understanding

<Zakim> alastairc, you wanted to wonder if it matters whether it is width/height

Alastair: Thickness works better, because it could be a tall thin control

<AWK> The area of the focus indicator is at least as large as the area of a 1 CSS pixel thick perimeter of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the User Interface Component.

Alastair: For internationalization, if Mike is still editing

Andrew: Can we say user interface component?
... We do get confusion between this and control, as well as if we add element

Wilco: Should we say something about the placement of the indicator?
... An assumption of near or on top of?

Andrew: There was that question
... Is this additive to the area of the component?

<alastairc> That's coming up in question 3, #1383

Andrew: Is it inside the current bounds?

Michael G: I think it will change based on the situation?

Rachael: I think we will come back to that

Michael G: I have pushed the commit to the pull request

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

Andrew: You didn't add "area"
... to the 2nd half of the initial part

<alastairc> 1st bullet drafted to: "The area of the focus indicator is at least as large as as a 1 <a>CSS pixel</a> thick perimeter of the focused control, or the focus indicator has a thickness of at least 8 CSS pixels along the shortest side of the user interface component."

Alastair: We have defined a minimum. I think we should add the pixels making up the focus indicator

<Ryladog_> +1 to Alastair

Alastair: So that if someone meets it with a solid dark border, the adds a yellow halo that is different, doesn't meet contrast, that is extra
... According to the 2nd bullet it would fail it

<Rachael> The pixels making up the minimum focus indicator area achieve at least a 3:1 contrast between their colors in the focused and unfocused states.

Alastair: yes

Andrew: Alastair just spoke about my next one
... My concern is that unless the indicator is a solid focus color, it will never pass
... And, we have the same problem with the adjacent contrast
... (reads from the text)

<Rachael> current text: The focus indicator contrasts at least 3:1 against all adjacent colors, or has a thickness of at least 2 CSS pixels.

Andrew: If you have a screen with a white background
... and a focus indicator that is orange, just over the contrast minimum
... And, you then have a darker yellow halo
... You might be saying ok this actually fails because the yellow is not enough contrast with the white
... But if you have the sufficient area you can ignore the yellow
... This gets into the complicated interpretations
... It might be needed to have minimum area

<Rachael> The minimum focus indicator area contrasts at least 3:1 against all adjacent colors, or has a thickness of at least 2 CSS pixels.

<alastairc> "The minimum focus indicator area contrasts at least 3:1 against all adjacent colors of the @@unfocused state@@, or has a thickness of at least 2 CSS pixels."

Rachael: I'm not sure this addresses it

<Ryladog_> Majority?

Alastair: if you add "adjacent colors of the unfocused state

Andrew: this is not comparing focused and unfocused. It is comparing straight adjacency when focused

David M: We have had trouble in the past with double contrast, left and right

scribe: It sounds like we are recommending create a 2 px border
... Otherwise you get into crazy calculations
... Do I understand that right?

Katie: I would say the same thing
... We have to decide if we want to exclude completely a changing contrast color that is not exactly what Andrew said, but something else
... Where some areas would be contrast, others would nt
... Or we just say only 2 px of a solid color
... We have to be clear

<Zakim> alastairc, you wanted to talk about solutions

Alastair: The reason we have this - white background with a dark button. Adding a dark border has contrast for change
... But if you suddenly have it on a dark button, it is not clear due to adjaceny
... We need it in some form
... It is not simple

Andrew: I agree with David, but yes, mostly in a place where the focus is over different colors.

<alastairc> oh, also solutions - you can separate the focus indicator from the conponent, e.g. 1px away from the control

Andrew: If there is a more consistent design it would be easier

Rachael: Alastair has noted subtleties
... Do we have a suggested wording?

Alastair: or having the focus indicator within the component?
... there are various other solutions, beyond just an outline
... But we have had a couple of issues where if you have a dark button on a white background
... They subtlety changed
... We have weird and wonderful solutions people are trying
... The change and the adjacency
... Andrew's example of dark orange border, and yellow around it...

<Zakim> mbgower, you wanted to say we have to be careful between guiding good design and trying to prevent poor design decisions

Rachael: Should we create an exception? Or would others fail that we think should pass?

Michael G: There are 2 things to balance: 1 - trying to provide good guidance, 2 - trying to prevent a person from making bad design decisions

scribe: My preference would be to try to provide guidance
... There will always be ways to game the system
... We should try to help people to make good designs

David M: If you have a yellow outline, then a lighter yellow. Is there any way to get 2 colors in 1 px?

Alastair: If you have 1 px strong orange that passes on a white background, and the 2nd px away from the component is yellow

David M: But it is 2 px?

Alastair: It doesn't meet contrast against the white (for the yellow)
... and because of the yellow, the orange fails for adjacent
... It isn't a bad design, it is reasonable, but is a niche false positive at the moment

Andrew: With non text contrast, talking about gradients
... The blue circle with the i on it for information
... You have to evaluate it where the gradient doesn't contrast - assume it is gone
... The i part of the graphical object - is it understandable or not?

<alastairc> We have a similar example for that in focus appearance: https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#focus-indicator-box-shadow

Andrew: We know people will make focus outlines that have that type of border, to give it shape or a gradient edge, and I don't think we want to prohibit that

<Ryladog_> The majority

Andrew: I'm asking if you have a focus indication area, that has well in excess of the minimum, and then there is this additional, lighter row of border px around it to make it look different
... If it is faint, do you have enough contrast?
... I understand Mike's comment, but know that we will have people that will ask these nitty gritty questions

<Zakim> Rachael, you wanted to ask if something like "the highest contrast portion of the indicator is at least 3:1..."

<jon_avila> Andrew we have that concept in 1.4.11 that some colors are ignored by the eye and you can skip them for calculation

Andrew: I think we should have something in the Understanding document to address it

Rachael: Somehow, portioning that out
... Katie talks about the majority

Katie: If we allow it, we have to talk about it being most of it
... I think what Andrew is saying is true
... Just like if there is an image behind

Wilco: Does this also apply to the fading outlines?

<jon_avila> from 1.4.11 "The input also has a dark grey border which is considered to be subsumed into the dark background. "

Rachael: What I am hearing is about multiple colors

David M: I have been recommending the 2 color focus indicator - it is pretty visible

scribe: with the 2nd bullet, I don't think it will pass
... If the inside is dark, and the outside is light? What will happen in that case?

<jon_avila> would it pass because it's 2px?

scribe: It is a pretty good way to solve it

<Zakim> alastairc, you wanted to say we have an example of the gradient before, but we hadn't considered the adjacent aspect.

Alastair: The new Edge focus indicator is white and black
... That is good in most situations
... But they acknowledged if it is 1px dark, and around that 1px white, if that is around a dark button, that is only a 1px and is not very visiblwe
... On the other hand, if it was reversed and you have a dark background the white is a separator
... It would be like the focus is away from the component
... This fits Andrew's comment about testing it
... We do have an example I put into IRC earlier

<alastairc> https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#focus-indicator-box-shadow

<Rachael> Jennie: A few years ago there was a presentation at CSUN by the target team that had an experience online that panned around in 3D. They made it accessible by providing a keyboard interaction. The background was ever changing as you panned around. How would you be able to ensure that no matter what the background was, that the consistency could be maintained? I like the idea that the colors have to stay consistent. That maybe tricky and an

<Rachael> outlier.

Jonathan: In 1.4.11 we have colors that can be (missed the word)
... To David's point, if you had 2 alternating white and black double border, I assume it would be the 2px wide
... Ultimately I think the best thing that could be done here is some sort of heuristics around the calculation of the area

<david-macdonald> You'ld fail first bullet with a 2 colour focus ring

Jonathan: I wish there was some overall hack that could ensure the visibility of it

<Rachael> 1.4.11: The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

Rachael: We do not make the adjustments in the SC for 1.4.11, just in the understanding document

David M: If we have this requirement, I don't see how we can have the 2 color focus indicator

scribe: the px that change have to have contrast as to what it was before

Michael G: If you assume 1 is white, 1 is black.

scribe: They will both be minimum

Andrew: You guys are talking about different 1st bullets

*Scribe change?

<Wilco> scribe: Wilco

<jon_avila> So what you are saying contrast change doesn't have to be for all parts of the indicator?

Alastair: If you have a dual color focus indicator, it should pass the minimal area, it could fail the adjacent color bullet.

Mike: but it would be 2 pixels think, so it would be fine.

Alastair: possibly?

<jon_avila> 3rd bullet assume homogenous indicator

Mike: it is the same scenario as the fade, it adds additional thickness, but still needs the minimal

Rachael: I'm hearing the third bullet is the problem

<jon_avila> I like the direction you are going Wilco

<Rachael> wilco: Did we consider instead of defining this instead of the entire area of the focus indicator, defining it as the minimum area of the focus indicator that needs to meet the contrast ratio

<mbgower> That is the first and second bullets, IMO

<Rachael> AWK: That is the question at hand.

<alastairc> Suggestion, too complex, but for argument: "The pixels making up the minimum focus indicator area achieve at least a 3:1 against all adjacent colors of the unfocused control, or have a thickness of at least 2 CSS pixels."

AWK: Third bullet, do we need that?

<Rachael> third bullet: Adjacent contrast:</strong> The focus indicator contrasts at least 3:1 against all adjacent colors, or has a thickness of at least 2 CSS pixels.

AWK: it seems like the only thing it does that is add the 2 pixel option, but otherwise it requires the same thing 1.4.11 does.

Alastair: We need it. It tackles the problem of if you put a 1px dark border around a dark control, that doesn't have the adjacent contrast.
... 1.4.11 is ineffective in working out this problem because it doesn't deal with focused / unfocused state
... I would rather this SC was focused on focus indicator and back out of 1.4.11 applying to focus in the way we've tried.

AWK: But 1.4.11 does apply to focus state. What we didn't get was the contrast against the non-focused state.
... With this new one we're saying it has to have a minimum area, it has to have a contrast to the unfocused state. But with the adjacent contrast, that is what 1.4.11 does apply to.
... I was just wondering if the easiest way was to delete the bullet.

<Zakim> mbgower, you wanted to say it covers the contrast against the exterior edge

Mike: The adjacent contrast bullet is trying to cover real-world problems, especially the edge.

AWK: But that is covered by 1.4.11

<jon_avila> 1.4.11 only really address adjacent colors on one side.

AWK: So a dark component on a white background, with a 1px dark border. So it would meet the contrast against the background, but wouldn't against the adjacent component?

Alastair: yes

<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-2.html

<jon_avila> 1px bigger is not enough for low vision users to detect.

Alastair: 2 pixels is OK, could be better, but seems like a good minimum.

David: If I understand, an objective is to make WCAG a little simpler. It seems this third bullet creates a lot of additional confusion. That's not a good indication for people coming new to this. I think the this new SC plus the 1.4.11, i had a company ask me which was getting really confusing.

<Zakim> alastairc, you wanted to make suggestion "The pixels making up the minimum focus indicator area achieve at least a 3:1 against all adjacent colors of the unfocused control, or

David: I would support dropping the third bullet. I know that drops an edge case where something could be not as visible as you'd like it to be. I think we're going to get 2-color focus indicators across the board to meet this otherwise.

Alastair: The simple way is have a 2 pixel thick border, one style for light, one for back, and if it is 2 pixels it will work. If you have a site with a dark background and light control, the dual focus indicator on Edge is not necessarily very visible.

<Zakim> Rachael, you wanted to ask how that doesn't faile 1.4.11?

<Zakim> AWK, you wanted to ask if passing this new SC's adjacent contrast bullet with 2px will still mean failing 1.4.11?

<jon_avila> If we adjust 1.4.11 to both adjacent colors then we still need the 2px exception somewhere.

Rachael: Wanted to ask on 1.4.11. If both adjacent colors are required, I struggle to see how a dark border against a dark control would pass. Lean towards removing the third bullet and reference 1.4.11 in Understanding.

<AWK> Adjacent contrast: The focus indicator has a 2 CSS Pixel thickness unless it meets 1.4.11 Non-text contrast.

AWK: If we have something with a 2 pixel thickness unless it meets 1.4.11? Although that has the problem you're still failing a different SC.

<Zakim> mbgower, you wanted to say we haven't covered the user agent exception

Mike: We don't have language on user agent exception. I included two options in the draft response.

<jon_avila> proposal by Andrew and Rachel doesn't address halo effect situation with gradients.

Mike: We need to add an exception or some language that user agents should fail.
... As for to what degree 1.4.11 addresses the third bullet; the way adjacent color was meant it's not talk about the object itself, only about the "outside color".
... When analyzing the state in 1.4.11, if the state changes, it is only measured against the adjacent color of the control. A black border around a black control does not fail 1.4.11.
... With that in mind, I think maybe we don't need the third bullet.

Alastair: Depends where it is, the indicator can be inside.

Jon: Not sure if 1.4.11 only applies to the outside. Maybe if you had an icon, you could say the graphic if the icon falls the the graphical side of the SC?
... But if we say 1.4.11 covers it, we still need to cover the 2-pixel scenario in 1.4.11. It also does not cover the halo/gradient scenario.
... We would need an exception for that.

<Zakim> alastairc, you wanted to say we have several issues on 1.4.11, which I don't think can be solved without the new SC

Alastair: We have a few issues on 1.4.11, including around contrast. It has been hard to work out how to solve those without moving the problem to the new SC. 1.4.11 doesn't cover the dynamic aspect very well.
... Doesn't cover about outside or inside the component. That is where the new SC came from.

Rachael: So we would adjust 1.4.11 to say it does not apply?

Alastair: Yeah, 1.4.11 is better for states like if something is open / closed, and not for focus indicator.
... The issue with the third bullet I think it covers more than we would like in a specific situation. Put a suggestion in to try to tackle this.

<alastairc> "The pixels making up the minimum focus indicator area achieve at least a 3:1 against all adjacent colors of the unfocused control, or have a thickness of at least 2 CSS pixels."

<jon_avila> As discussed in github any changes to understanding of 1.4.11 for 2.4.11 should only affect WCAG 2.2 branch as some org may stick with WCAG 2.1 and we don't want to lose focus from that situation.

Alastair: Making it similar to the previous bullet, but making it to the adjacent colors of the unfocused control.

<AWK> -1

Alastair: So in the case of a halo, you're taking contrast on the background and not the gradient.

Rachael: So how to specify that not all the colors meet the minimum contrast?

<Zakim> AWK, you wanted to disagree with Mike on whether it considers the control color

Alastair: You'd have an the minimum area meet the contrast.

<jon_avila> but a halo would have 2 colors - so do those have to contrast against each other?

AWK: I think 1.4.11 includes contrast against whatever is relevant.
... For example pill shaped buttons, there are crescent moon shaped indicators on the buttons.
... I think part of the benefit of 1.4.11 is there is some interpretation on whether you've met it or not

<alastairc> I'd also be happy to 'wave away' that scenario, cover in understanding

AWK: In this adjacent contrast, the adjacent is compared to what's there, not to what's not there anymore. I do think 1.4.11 applies to the color of the control itself in some cases.

Detlev: Wonder why it's not easier to say the contrast has to be above 3:1 to either the background or the control itself, so why not allow both?

Rachael: It needs contrast against both or be wide enough to see the difference.

<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-2.html

Alastair: It doesn't work consistently with either color. I don't see how we can use 1.4.11 for that. There are cases where things you wouldn't want to pass do, and things you wouldn't want to fail do. I don't see how that helps with the new one. It doesn't specify either way.

AWK: Which examples are you saying it is problematic for.

Alastair: Talking about 1.4.11, if it's either colors pass, you can have a light border on a light background so the change doesn't pass. If you have both, you have a narrow range.
... This is getting back to if 1.4.11 helps with focus indicator. We have quite a few issues there to deal with, that would be easier to deal with if we separated it from 1.4.11.

AWK: For the example page, the issue is on how thin the focus is with regard to 1.4.11.

<Zakim> mbgower, you wanted to say the "adjacent colors" section of 1.4.11 makes this claer

<mbgower> Adjacent colors For user interface components 'adjacent colors' means the colors adjacent to the component. For example, if an input has a white internal background, dark border, and white external background the 'adjacent color' to the component would be the white external background.

Mike: 1.4.11 there is an adjacent color in the understanding document.
... It is pretty clear from that wording that adjacent color is on background, except if the indicator is inside the component itself

<Rachael> Option 1: Create an exception or add to understanding in 1.4.11 for focus indicators and change the 3rd bullet to something like: "The pixels making up the minimum focus indicator area achieve at least a 3:1 against all adjacent colors of the unfocused control, or have a thickness of at least 2 CSS pixels."

Rachael: I see we have three options.

<Rachael> Option 2: 1.4.11 applies to focus indicators and the third bullet should be removed or adjusted 3rd bullet to point to 1.4.11

<Rachael> Option 3: Cover complexity in understanding

<alastairc> Worth reviewing these issues before relying on 1.4.11 https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%221.4.11+Non-text+contrast%22+focus

Rachael: Would like a straw poll to see where people are.

<alastairc> Option 3

<AWK> Option 2

option 2

<david-macdonald> 1

<MelanieP> Option 1

<david-macdonald> 2

<Ryladog_> Option 2

<mbgower> Sorta all of the above LOL

<Detlev> lacking enough context to say

<Levon> option 1

<laura_> Option 2

<Francis_Storr> option 2

<Sukriti> 2

Rachael: Strong direction for option 2.

<AWK> Would be good to know what issues remain if option 2 was selected

<mbgower> I agree we have to examine more clearly.

Alastair: We'll have to come back to it. I think connecting it would add complexity rather than reduce. Can't talk off hand, would have to come back to it next time.
... Seeing if people agree with other changes in the PR?

<Rachael> https://github.com/w3c/wcag/pull/1403/files

<AWK> one last comment

<Rachael> Do you agree to the changes in the pull request?

<Fazio> +1 AWK

AWK: One last thing in my comment. I just don't think we need to define perimeter. It is well understood.
... In the pull request there is a definition for perimeter.

<Zakim> mbgower, you wanted to say that was included because it clarified how to do a calculation

Mike: The reason why i did that is because people asked how you test that.

Alastair: There's an issue that if you do it how you think you should, you get one answer. The mathematical issue is actually 4 pixels larter.

Alastair, so definition is there to establish that is inside the control rather than around?

Rachael: Other comments?

<AWK> OK, I get the perimeter definition now and am good with it.

David: My understanding of 1.4.11 was that as soon as the indicator is on the button, it becomes part of the button, so it is about what's outside if it, rather than what's inside.

<Rachael> proposed RESOLUTION: Accept changes in #1403 and come back to changes for the 3rd bullet adn 1.4.11

<alastairc> So based on David's comment, 1.4.11 doesn't cover adjacent contrast with the component.

<david-macdonald> right

<Ryladog_> +1

<mbgower> +1

<alastairc> +1

<Sukriti> +1

<david-macdonald> +1

<AWK> +1

<Francis_Storr> +1

<morr4> +1

-0 would like more time to think

<Rachael> +1

Rachael: Going to suggest we pass the resolution. We'll see this again.

<alastairc> I'll create a new issue if there isn't one already

Alastair: Once the focus indicator is on the control it is part of the control, so the adjacent color of the indicator doesn't have to be with the control. We'll come back to that.

Exception for the default focus indicator? #1341

Rachael: Five answers, all say there should not be an exception.

Melanie: Didn't answer the survey, but I lean towards an exception. I want to make sure I understand that given browsers have different indicators, we're forcing all designers / assessors to go through this.
... It seems overwhelming, given we're having a hard time understanding this ourselves.

<david-macdonald> +1

Melanie: We're forcing all focus indicators to be styled.

<Ryladog_> -1

<AWK> Yes, that is the implication. But it is super important and default indicators have not been good enough so that's why we have it.

Alastair: This is something we wanted to cover in 1.4.11. The focus aspect was put to one side. It is one of the more consistent issues we hear back. People using keyboard, not able to tell where the focus is.

<Ryladog_> AWK said it

Alastair: It's something that authors can effect. The way I used to think about it, as a user if focus indicator is important, you would use a browser or plugin to think about that. But people don't necessarily know about those or know how to use them.

<Ryladog_> do tell Mike

Melanie: This feels like an incredibly high burden to put on designers and developers on something that should be more easily addressed by user agents.

Alastair: But it has been many years and it hasn't happened.

<Zakim> mbgower, you wanted to say there is an elegant way to answer this in an ACR response

Mike: There can be wording in the understanding document that says the default can be sufficient. If you're going to report this, if you're actually going to meet the minimum, I think it will be partially supports. Comment would the the user agent indicator is used. It would be reported as likely not fully supported.
... Someone assessing that can understand what that means.

Melanie: If you're doing 508 you can say partial conformant, but WCAG is all or nothing, right?

Mike: Depends on how you report.

David: Agree with Melanie for different reasons. This is a big SC right now. There are a lot of concerns about browser defaults.

Katie: This issue has gone on for years. When we had UAAG the browsers decided to push back. People have worked for some time to make enhanced focus indicators. In the end we can make changes to bullet 3. I don't think this needs to be as big as we're making it to be.
... WCAG is why Chrome changed, but they don't want user agent requirements on this. We have to leave it with the content authors.

<Zakim> Rachael, you wanted to say that we should allow browsers to make it easier

<alastairc> It's easy to meet if you want to do it easily: 2px outline that contrasts with the background

Rachael: As we write this in the understanding, we want to make it apparent that if this does get fixed in all browsers, authors have less work to do.

<laura> Situation reminds me of brower support for the title attibute.

<david-macdonald> "a mechanism is available..."

<Rachael> Wilco: Suprised that 5 people do not think this should be an exception because in Silver we lean towards the browsers doing the standards.

<Rachael> Alaistar: I think that is the long history of this requirement.

<Ryladog_> +1 to Alastair

<Rachael> ...the lack of browsers changing has led here.

<Rachael> Proposed RESOLUTION: There should NOT be an exception for default browser focus styles.

<Ryladog_> +1

<mbgower> 0

<MelanieP> -1

+1

<Rachael> +1

<alastairc> +1 (whilst allowing browsers to meet it in future)

<david-macdonald> 0

<laura> +1

<Detlev> -1 in light of the view that we should push UA to support it better

Alastair: Next step would be to make an addition to the understanding document.
... Put the question in to have the discussion and get a resolution.

<Detlev> we have fairly solid UA focus in Chrome and Edge now...

Alastair: Alastair, we need someone to write an exception. What I would suggest is to allow browser to meet it.

<Ryladog_> especially important in mobile devices

<Rachael> Wilco: I think that is the reason I'm voting +1. I think this creates pressure for browers to do it. Hopefully they open issues and start conversations.

Rachael: Someone willing to write this up?

<mbgower> I can take on a draft

Rachael: Mike, thank you for taking this on.

Melanie: I can help write an exception.

Alastair: Would point people to see the e-mail I sent on target size.

<alastairc> Target spacing/sizing: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0041.html

Rachael: Just a reminder that the CFC for WCAG 3 is out there.

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)

Default Present: Laura, sajkaj, Chuck_, Francis_Storr, MelanieP, Raf, alastairc, MichaelC, AWK, Wilco, Levon, JakeAbma, kirkwood, StefanSchnabel, sarahhorton, Sukriti, Katie_Haritos-Shea, Glenda, Fazio, david-macdonald, Caryn-Pagel, bruce_bailey, mbgower, !, PeterKorn, jon_avila, GN, Matt_Orr, Jennie, Rachael, stevelee, JustineP, CharlesHall_, (sorry, another, meeting, ran, longer, than, planned)
Present: Laura sajkaj Chuck_ Francis_Storr MelanieP Raf alastairc MichaelC AWK Wilco Levon JakeAbma kirkwood StefanSchnabel sarahhorton Sukriti Katie_Haritos-Shea Glenda Fazio david-macdonald Caryn-Pagel bruce_bailey mbgower ! PeterKorn jon_avila GN Matt_Orr Jennie Rachael stevelee JustineP CharlesHall_ (sorry another meeting ran longer than planned) another_meeting_ran_longer_than_planned)
Regrets: i have to drop off call
Found Scribe: Jennie
Inferring ScribeNick: Jennie
Found Scribe: Wilco
Inferring ScribeNick: Wilco
Scribes: Jennie, Wilco
ScribeNicks: Jennie, Wilco

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


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: 

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.)