AGWG-2022-03-08 -- 08 Mar 2022

<Jennie> scribe: Jennie

<Chuck> we will take you up on that!

Chuck: We are waiting until 2 minutes after to start
... Welcome everybody
... We have our scribes lined up for both hours
... Thank you to volunteer scribes
... Pre-sign up for scribing

<Chuck> https://www.w3.org/WAI/GL/wiki/Scribe_List

Chuck: Any introductions - if you are new or have a new role?
... Any new topics?
... We keep a list of topics
... 2 announcements
... next week's instance of this meeting will not occur due to axe-con and CSUN
... we will resume the following week
... no call next week
... Today is international women's day
... This year's theme is Break the bias

<Jaunita_George> Happy International Women's Day!!

Gundala: Is there a daylight time switch?

Chuck: Yes. There is a bit of overlap between the US and other parts of the world
... It is this weekend in the US

AlastairC: For those of us in Europe, be aware that the last meeting of this series will be likely an hour earlier for you

Chuck: Anything else?

<Rachael> We will also send out a reminder of the meeting cancelation and time change later this week.

ACT Update (Wilco)

Chuck: There has been a change in the agenda
... Reviewing decisions and evolution of decisions Silver has taken up are not yet ready
... Wilco will talk about the ACT update
... We will bring up Silver decisions in another call

<Chuck> Original: https://www.w3.org/TR/act-rules-aspects/

<Chuck> Change: https://github.com/w3c/wcag-act/pull/526/files

(Wilco shares screen)

Wilco: The ACT task force has been working on an update to our input aspect
... On my screen is an ACT rule
... Button has non-empty accessible name
... This rule has Input Aspects - summarize the data you need to run a rule
... to use that rule
... For this one, the button rule needs 3
... If 1 is not available in your testing environment, you won't be able to use this test correctly

<Wilco> https://www.w3.org/WAI/standards-guidelines/act/rules/button-non-empty-accessible-name-97a4e1/#inputaspects

Wilco: When moving this over into the redesign of the W3C website
... some of the input aspects we were using were not actually defined
... Thos changes can be seen
... we have created defintions for 3
... We would like to have approval from the working group to publish them
... We will present them here, and then put them into a CFC
... It has been reviewed by the community group

Chuck: I have a question
... We are announcing it will go to CFC
... We will poll the group

AlastairC: Because we have just put this in front of people
... we can send the links around afterwards
... If there are questions we can deal with those
... If no one has any particular questions, we can go to CFC because this is just a small update

Chuck: Are you suggesting a day or 2 to review?
... I am crafting a resolution

<Chuck> proposed RESOLUTION: Approve the ACT update to go to CFC if there are no objections via email

<Rachael> +1

<Chuck> +1

<kirkwood> +1

<shadi> +1

<Wilco> +1

<mbgower> +1

<Detlev> +1

<alastairc> +1

<bruce_bailey> +1

<sarahhorton> +1

<Lauriat> +1

<MelanieP> +1

<laura> +1

<Jaunita_George> +1

<Francis_Storr> +1

Chuck: Any objections?

<Raf> +1

RESOLUTION: Approve the ACT update to go to CFC if there are no objections via email

WCAG 3 Requirements Survey https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/

<AWK> +AWK

Chuck: We will go through questions in here, and go to through the results
... It will be the usual format
... Reads the question

* Chuck: please see comment from AWK

<Jaunita_George> +1 to requiring backwards compatibility

Chuck: (reads Detlev's response)
... (reads Gundula's response)

Gundula: I meant unavoidably

<Jaunita_George> I agree with Gundula as well.

MichaelC: Outcomes, or units of conformance like that should not have backwards compatability breaking things
... but WCAG 3 as a whole could
... It would deprecate or remove the old outcome
... The integrity of outcomes does need to be retained

Chuck: (reads Bruce's comment)

<Lauriat> +1 to Bruce's comment (I missed the survey)

Bruce: Others wrote this in as well. Why are we making this call now about backwards compatibility

Mbgower: I think we put ourselves into twisting around with backwards compatibility - but I echo Bruce

Chuck: (reads Andrew's comment)

AWK: Yes, I think that we have to be willing to have some incompabilities
... There are additional things we are trying to do with 3.0
... My expectation and understanding of the group's is that it is going to be different
... I agree we should strive not to have it differ, we should not be hemmed in as a requirement

Chuck: I will move to the "something elses"
... (reads Sarah's comment)

<bruce_bailey> Just want to note my appreciation for MC long nuanced response to this backwards compatibility question.

Sarah: Nothing to add

Shadi: Same as Sarah essentially

<Lauriat> +1 to the appreciation of MC's comment

Rachael: I think there is value in having this conversation
... There is a difference when we say backwards compatible
... And I have had conversations with Gregg around harmonization
... I think getting us all on the same page would be helpful
... I don't want to be locked into not fixing mistakes

GreggVan: Gundula and Bruce - I think they hit it well
... A this is something I think we should really focus on trying to do, but we shouldn't decide we will fail in advance
... Does that mean same numbering scheme? No
... If that is what we need, then we need to change what we mean by that term
... I think it means, if you met 2.0, will 3.0 be easier?
... That's what I thought backwards compatibility meant
... If we find out there is something we did wrong, we fix it, and note it
... I am not sure we can decide this in advance

Chuck: Laura C says it seems premature to decide this

<alastairc> I think the starting point of the question was changes to WCAG 3.x.

Chuck: And Kim D said (reads her response)
... Anybody else before we go through cue who has a comment they would have added to the survey but didn't have a chance?

<Detlev> @gregg but this is about 3.n vs e.n+1 rather than 2.x backwards compatibility

<Rachael> Just a note that this is about backwards compatibility between versions of WCAG 3 not between 3 and 2.

<AWK> I was just realizing that also

Mbgower: Can you clarify the versions?

<Rachael> That is correct

<Zakim> MichaelC, you wanted to suggest that answering backwards compatibility informs forward compatibility efforts

Chuck: I will address when I come up in cue

<jon_avila> I thought that as well - the question was around versions of WCAG 3.0 not being backwards compatible with each other.

<alastairc> As the question raiser, that is correct, it is only for WCAG 3.x versions

Chuck: Yes, Rachael confirms that is correct

MichaelC: In 2.0 we spent a lot on forward compatibility and it may not have paid off
... I think we should address the details later
... I think we should have a direction on backwards compatibility

<Zakim> AWK, you wanted to disagree that we can't fix mistakes in WCAG 2.0. There is value in stability though

MichaelC: I don't want us to get lost in forward compatibility that won't work
... Allowing backward compatibility
... Design for forwards compatibility
... We should be ok that there will be backwards compatibility issues

AWK: I was answering that this is about 3.x line
... We are talking about between versions
... Talking to Rachael's comment - we haven't been able to fix all mistakes, but we have fixed some

<bruce_bailey> +1 to MC point that strict backwards compatibility in 2x has not worked as smoothly as we would have liked

AWK: There has been great value in stability in the 2.x standard

<shadi> +1 to AWK

AWK: Right now we have Section 508 in the US, EN in Europe

<Wilco> +1, stability is critical

AWK: We have Canada looking to adopt a new standard
... If they were incompatible, what would we do to serve all needs as a vendor with one product
... Creating different products to serve needs of different companies would be a huge ask
... If we do that I am concerned

<Fazio> +1 AWK

AWK: You will end up with lots of engagement by companies that need to make sure that we are not building different things
... We should be proposing that earlier versions with problems can be deprecated

<bruce_bailey> +1 for AWK point that backward compatibility with 2x has been valuable with regulators in different countries

AWK: I think this is a challenging topic
... And I don't want to rule it out

<Zakim> Chuck, you wanted to ask about continuing the conversation with the possibility of no resolution ...Example: colour contrast - we have something better; but it is hard

<jon_avila> I was thinking the same thing with contrast that we pass things that are hard to see but we can't fix them in 2.x

Chuck: I have gathered a sense from some people that this is premature
... But then a couple of individuals have suggested that maybe we don't come to a resolution today, but we still talk it through
... Did I understand your proposals?

<Rachael> +1 to talking through this today knowing we will not make a final decision but also knowing there is value in the conversation

Jaunita_George: I have some questions. Why is it so difficult to make changes in the 2x series? What would change in 3.0 to make this easier
... If we didn't have backwards compatibility

<Zakim> alastairc, you wanted to try a couple of examples

AlastairC: I raised the question because we already had in the requirements that we were dropping backwards compatibility to 2.x
... But I was looking ahead that we had nothing in the requirements that WCAG 3
... If you passed 2.2, you should pass both of the previous 2 versions
... You can't do something like adjust the colour contrast metric
... You can pass 2.2 with a color that would not pass 2.1
... If we had updated it
... Because of changes in how browsers have become more inter browser compatible, this would not have passed

<Zakim> Chuck, you wanted to ask if Alastair was refering to 4.1.1?

AlastairC: I was referring to 4.1.1 parsing
... we will try to maintain 3.x compatibility, or have some system of saying when we have major updates
... "These things are not backwards compatible"

Fazio: To address Andrew's point
... The amended Section 508

(apologies from Scribe - missed that part)

<alastairc> Sorry, I was talking about deprecating 4.1.1 "parsing", then talked about "passing" things!

scribe: They updated the ADA
... They put in a clause
... That says those making updates after 2010, they need to match the later version
... For those of us that work with regulators, this is a conversation to be having
... I think it is important for digital standards to be able to continuously improve because technology advances so fast
... A technical guideline that is correct 5 years, may need to be update

<Zakim> mbgower, you wanted to say has there been a summary of the pros/cons already created?

Mbgower: I think we have had this discussion a few times

<bruce_bailey> s/4.1 passing/4.1.1 parsing/

Mbgower: I am not sure that anyway specifically captures the pros and cons on backwards compatibility
... Should these be listed clearly?
... This might give clarification
... And then have a vote

<Rachael> +1 to documenting this

Mbgower: Which I suspect will not be consensus

Shadi: Responding to David

<kirkwood> +1 Mike Gower suggestion

Shadi: I think the scenario you were talking about was the same - future versions of the technical standard for the same law
... I heard Andrew talking about across jurisdictions
... I think one of the big enables was the backwards compatibility
... I think the cautions that Andrew is saying are really important
... It does make a difference
... At the same time locking us in too much will constrain us
... I am unsure about why we are having discussions about future versions
... I do appreciate Mike and Rachael's suggestion of a definition of backwards compatibility
... Lack of backwards compatibility - we would need to document what we mean, and have pros and cons
... I don't feel that this is a good use of our time

Rachael: I think having this conversation now, even though we won't spend tons of time, I think it helps with building 3.0
... It balances flexibility
... I like the documentation
... It is an issue, we have to work through out Github issues responsibly
... We can write back and say it is not a final comment, and add a note that we talked about it, and lists our next steps

<Wilco> +1 to Rachael, if we need options to change normative language in WCAG 3 we should account for it

<bruce_bailey> Just an FYI, here is a page describing how the 2010 ADA standards replaced the previous version: https://www.ada.gov/2010ADAstandards_index.htm

Rachael: There is value in setting our mindframe and our approach to this comment in mind

AWK: The previous resolution says the group agrees to go to CFC unless there are any objections
... I think we should say that we are agreeing to send something to CFC

Chuck: I don't have any problems updating the resolution
... I can't craft it out - I think we have some conversation on the current thread

<Zakim> alastairc, you wanted to say that we can be cognisant of backwards compatibility when creating the structure, e.g. what's normative/informative.

Chuck: We will try to resolve before the next resolution

AlastairC: I realize it is quite early to try to determine this, and I am not trying to determine it
... Would it be relatively easy to document?
... It was more about: are we going to try to stick to our current way of doing things, or are we allowing some flexibility there?
... We will send the links, to ensure people can review, then we will go to CFC

Rachael: I can correct it while you keep going

Chuck: Thank you Rachael
... There are 2 threads we can go to in terms of backwards compatibility
... There was a proposed response, and an alternate
... to address the response that was logged by Alastair

<Chuck> proposed new response: Thank you for your response. The working group discussed this and decided to revisit this question when WCAG 3.0 is more mature. We will leave the issue open until then.

Chuck: I would like to focus our conversations on this at the moment.
... Are there any concerns with providing this response at this time - deferring a formal response to a later date

AlastairC: I was looking for - a decision to commit to backwards compatibility, or determine a way to mitigate being backwards compatible
... I see those branches
... Currently the requirements doesn't ask for backwards compatibility between major versions
... It also doesn't have any requirements for updates about backwards compatible things
... We are assuming we will be backwards comptaible

<kirkwood> first, we need to clearly define “backward compatibility” no?

Chuck: or, we don't know yet which of the 2 we want to go to, and the group may not be comfortable committing to a response at this time
... That's what I am sensing at this time
... That the group is not ready to make a written committment

Wilco: What would get us to that point?
... Somewhere along the line, we will need to get to that place

Chuck: (Chair hat off) until we have a use case that we can touch and feel, and work through we won't be able to get there
... We need a scenario.

<alastairc> kirkwood - The definition would be: Passing WCAG 3.x passes all previous versions of WCAG 3.x

Chuck: When working on 3.0 we encounter a challenge, what would be best?
... Alastair - were you hoping in this conversation we would come to a more directed response and decision?

AlastairC: I was hoping...
... I think a requirement saying we are not committing to backwards compatibility but will make every effort to propersly document

<Rachael> S/RESOLUTION: Approve the ACT update to go to CFC if there are no objections via email/RESOLUTION: Approve next steps as mailing the ACT update out and then going to CFC if there are no objections via email by Friday.

Shadi: Alastair - would you be willing to take an action to draft a very brief - what backwards compatibility means and the pros and cons?

AlastairC: The definition is: passing 3.x would pass all previous versions of 3.x
... I can try to put together a better question

Gregg: Are you just talking about 3 and 3 or 3 and 2

AlastairC: 3 and 3

Gregg: I would add unless there are technical errors or fixes that need to be made
... We are trying to find - we had one with color gamut
... The way we have done color has changed
... The guidelines have to change to match
... Meeting the new ones will meet the old ones unless there are technical adjustments
... I think that every time we make a new one it should meet the old one
... Unless it was a technical error

<Chuck> proposed RESOLUTION: AGWG acknowledges that there is presently no requirement for compatibility with prior versions of WCAG 3, and the working group will craft and propose such a requirement.

Chuck: I am trying to work on something that satisfies Alastair's points, but is flexible enough
... (reads proposed resolution)

<bruce_bailey> +1 to Chuck's proposed resolution

Shadi: To Alastair - the way you were phrasing it - full backwards compatibility or none at all
... I think these 2 extremes might get more discussion, rather than if it is more nuanced

<Chuck> proposed RESOLUTION: Alastair will refine the question and pose the updated question to the group for later review.

Shadi: Certain types of changes may be allowed - not sure how you want to approach that

Chuck: I have an alternate resolution (read proposed resolution)

AlastairC: Yes, we can come back to this at a later time

<Zakim> Rachael, you wanted to ask if we lost the idea of documenting this more

Rachael: We had some discussion around documenting our understanding this. Did we lose that?

Chuck: I may have lost it
... but I am not sure why it was lost
... I was concerned that the documenting might be viewed as premature
... But if you don't want to lose it we can figure out how to proceed

Rachael: That was me personally

Chuck: I did think it was a good idea, but didn't think it worked well as a response to Alastair's issue

AlastairC: I can put that as part of my action for this

<Chuck> proposed RESOLUTION: Alastair will refine the question and pose the updated question to the group for later review.

<mbgower> +1

<Chuck> +1

<AWK> +1

<shadi> +1

<bruce_bailey> +1

<sarahhorton> +1

<Rachael> 0

<alastairc> +0.5

<KimD> 0

<Detlev> 0

<Lauriat> 0

<Wilco> +1

<laura> +1

Chuck: there are more than a few zeros.

<jon_avila> +1

Rachael: I would like to see the group make more progress on this (personal opinion)

<AWK> 0=neutral?

KimD: My zero is a matter of process. I don't like the precedent of making someone resubmit their question so it is easier for us to answer

Detlev: The shape of 3 is still so vague, it doesn't make sense to discuss this now
... I think spending more time on the structure, the new conformance model, then once the new version takes shape we discuss what happens when there are additions
... and changes

<shadi> +1 to Detlev

Detlev: I like Gregg's suggestion about changes

Chuck: Assigning an issue to the person who raised it - this is not typical, but the person is here, and they suggested that course of action
... This is not a precedent
... In regards to more progress - I am not sure in the confines of this call, we will have an ongoing opportunity to make progress

RESOLUTION: Alastair will refine the question and pose the updated question to the group for later review.

<bruce_bailey> scribe: bruce_bailey

Question two, revising WCAG3 true false statements

https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/results#xq16

Chuck reads...

Question 2 - Revising true/false statement

8 votes, 2 keep current wording, 4 change..., 2 something else

Support keeping the current wording

Chuck read Gundala response in survey for keeping current wording.

GreggV: other choices are vague -- need clarity. and MORE always says More than what?

Chuck: going through 5 changing the wording responses.
... mostly no new comments

chuck reads bbailey response

Chuck continues with SH and MG, no comments, just vote.

Chuck asks Shadi to reply to his something else vote

<Detlev> q

Shadi: Both response seem rather vague, concern that binary versus subjective not well defined
... basically anything could qualify, so it is not a strong proposal imho

Rachael: I think this needs some rework and is not well worded and may even be incorrect.

<Zakim> Lauriat, you wanted to ask whether this differs materially from the question we looked at February 8th with work in the TF resulting in a PR after then

<Lauriat> Minutes from February 8th https://www.w3.org/2022/02/08-ag-minutes.html#t04

Shawn Lauriat asks for clarification from early feb 8 survey

Chuck asks if we have resolved?

<Lauriat> I accidentally muted myself and kept talking

Detlev: I think there is value between Likert scales and thresholds...

but as soon as one start aggregating scores the consideration is different...

for example an image missing alt is a fail, but in the context of a 1000 pages with one missing alt is that a fail?

<Zakim> Lauriat, you wanted to get back in and see where the group heard up to, as I think we should avoid repeating the whole conversation

Chuck: Coming back to Feb 8 call, yes this survey is meant to be a further refinement of that decision.

Shawn Lauriat: thanks, the task force has an action item to come back with a proposal and we have not done that yet.

Shadi: I am confused by text in survey since I think it is more than a bit different than our last pull request and earlier discussion.

Chuck acknowledges and clarifies that there is a Pull Request not included in this survey which was meant to address earlier discussion.

<Chuck> proposed RESOLUTION: Review existing PR and review proposed response later.

Shawn: Thanks, yes I think Silver task forces are working on this as directed by AG WG.

<Chuck> +1

<Lauriat> +1

<Jaunita_George> +1

<Detlev> can someone post a link to the PR?

<Regina> +1

<laura> +1

<Raf> +1

<AWK> +1

<Jennie> +1

<Detlev> +1

<sarahhorton> +1

<Ryladog> +1

<Lauriat> Pull request from the previous question https://github.com/w3c/silver/pull/614

RESOLUTION: Review existing PR and review proposed response later.

WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Question 1 - Focus appearance Updates

https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

Chuck: Just one question, but it is a long one.

Alastair: I have responses to most of comments recieved.

https://docs.google.com/document/d/1TI_DsJjfg9RW_A9C1XfqgtfYqNMfnxeCz6lxjpOQ9rk

<alastairc> The doc with proposal and test cases: https://docs.google.com/document/d/1TI_DsJjfg9RW_A9C1XfqgtfYqNMfnxeCz6lxjpOQ9rk/edit#

Chuck reads survey question.

https://github.com/w3c/wcag/issues/2222

https://github.com/w3c/wcag/issues/2237

8 replies, 1 agree, 4 with adjustment, 1 something else

Chuck reads comment on Agree with the proposed SC updates

Chuck asks Jonathan Avila to clarify his survey answer on adjustment.

JA: A few points, not the least is background color is not clear.

Chuck reads bbailey reply.

Chuck reads OliverK reply in survey.

Chuck reads AWK reply for agree with adjustment from survey.

AWK: I would like to avoid tracking failures against multiple SC...
... if can't fix that here, consider removing 1.4.11

Chuck: Wilco voted something else.

Wilco Fiers: I am finding a lot of edge cases that are not addressed...

scribe: seems like a very large edit for going into CR. I am worried that puts us at risk for another CR...
... I don't think what we have here reflects recent conversation about persistence of focus indicators.

<alastairc> Topics:

<alastairc> Background of indicator for exception,

<alastairc> Adding a note about descendants,

<alastairc> The AAA exception,

<alastairc> Is the adjacent colors removable?

<alastairc> Does encompasses allow for non-solid lines?

<alastairc> Using UIC,

<alastairc> Persistence,

<alastairc> How do decorative effects pass the exception?

Gundula (GN015): I have concerns that this is not addressing some of the other concerns and for decoration of focus indicator. ...

scribe: The shift from 1px to 2px is also different...

<Wilco> +1 to all of that

<Zakim> alastairc, you wanted to talk to indicator's background color

scribe: Another concern is that there could be variation of focus indicators which are not addressed. For example, marching ants or dashes, both common, do those count?

Alastair: There is explicit language about foreground and background color. ...

The rewrite does address browser default. So those two concerns are addressed.

Chuck ask Alastair to address concern about descendants.

<alastairc> NOTE: Where a component has sub-components (e.g. a drop-down menu), the focused item is the scope of this success criterion.

Alastair: With menu drop-downs it had not matter if descendants were separate UI elements or not. With rewrite, this is an issue.

[AC pastes new proposed phrase]

AC: The other option is focus on whichever component has the keyboard.

<Zakim> alastairc, you wanted to say we can't / shouldn't use the DOM version of focus

Wilco: I agree that active descendants needs to be addressed, but I am not in favor of this approach.
... this definition of focus is new and different. Approach needs more consideration.

AC: Agree that this definition of focus is a little different than browser definition of focus, but I cannot think how to resolve because keyboard focus is so important.

Chuck: Not hearing a consensus, but lets go on.

AC: Bruce raised question about AAA having excemption for user agent.

bruce is fine keeping

<alastairc> https://w3c.github.io/wcag/understanding/non-text-contrast.html#figure-focus-outer-green

AC: Question about adjacent colors removable. We do have overlap. Might be better addressed by WCAG3 approach, but have some prose in understanding

Alastair describes Understanding [see link] so that will help address.

Chuck asks AWK if that Understanding edit is on point?

Chuck will have to follow up, AWK appears offline.

AC: There was also a question about new definition for encompasses, and if that meant border needed to be solid.

Chuck: chair hat off, shares experience seeing dotted lines as bounding area, so that seems reasonable use case.

Detlev: Agree that dotted lines can have good use cases. Could be easier to see under some circumstances.

<SuzanneTaylor> +1 to dotted/dashed possibly being preferred

AC: We did some usability testing, and single-pixel solid line are not sufficient...
... thicker dotted dash can have good usability, and that is allowed by one of the exceptions.

<Detlev> agree with Alastair!

Chuck: Hearing two threads, that non-solid lines can be sufficient. Also need more testing.

AC: One approach is a simple metric with a solid border, so we need to clarify that if that is not clear...

<Detlev> fair enough to pass thick dotted line via exception

AC: but we have thick (4px) exception, so a thick dotted line can clear.

Chuck: moving on to next concern, definition of UIC

AC: In previous conversations we asked about alternative terms like UI and element rather than UIC.

<alastairc> When an item has keyboard focus, the focus indicator:

AC: My main concern was to be clear that active descenders are a UIC...
... If we don't use UIC we need to define a new term which also will have conflicts with focus and other well recognized terms.

Wilco: It is not clear exactly which problem we are trying to work out and solve here.

AC: "using UIC leaves too much room for interpretation"

Wilco: We need a way to measure the size of the thing.
... Deciding which pixels on the screen are part of the UIC is too ambiguous and will not be tested consistently.

AC: We do include some confounding examples (in the Google doc) which were problematic before and are addressed now.
... We gathered difficult example, and a couple of when through and determined consistent pass/fall for these examples.
... We are looking for examples where the revised SC does not work.

Chuck: So can we use UIC?

AC: Yes.

Wilco: Agree that UIC as term is fine. Problem is measuring size.

AC: Size is the perceived control.

Wilco: I do not agree that "that button right there" is unambiguous.

Chuck asks for others to weight in.

AC: Example includes box shadow, which was problematic before. Now we take that apparently increased size. Example a bottom of page 2.
... Box shadows fails main requirement but meets the exception, so it passes.

Detlev: Still have concern where button is same color as background color.
... so if light contrast, less than 3:1, then background of button counts?

AC: It should not matter if meets requirement for nontext contrast.

Detlev: Its a concern for a potential algorithm, how would the sized be calculated?

<Zakim> Chuck, you wanted to say Wilco has given his support to letting it pass if it's just him

AC: I can see this a decision tree, and it might be manual check, that when UIC gets focus, an outline reveals the size.

Chuck: Summarizing, Wilco has some reservations and asks for others feedback.

<Zakim> mbgower, you wanted to say can clarify the examples that are a problem?

Wilco: Not having an explicit way to determine the size is cause for objection.

AC: Can you go through example?

Mike Gower also askes Wilco to go through examples and provide notes.

Wilco: I need examples to be more detailed. I cannot tell just from images if illustrations are meant to be 1 px or 2 px.

AC: Links are in code.

Wilco agreed to delve in and provide more feedback.

Chuck: Next item was persistance.

AC: We had concern for people looking away and coming back, not being able to spot focus.

<Chuck> +1 to Alastair's understanding.

AC: We moved not obscured in to new SC to help address that.

Wilco: My recollection was for wording "while focus indicator visible"?

<Zakim> mbgower, you wanted to say there is no wording about persistence here, just like there is nothing explicit about it in Focus Visible.

<jon_avila> We had said while it had focus

MG: No wording about persistence, same that Focus Visible does not specify that.
... Nothing in SC to hang on that.

AC: last item is about decorative effects.
... Size metric addresses this, so yes it would be a pass.

different approach.

<mbgower> To clarify, the wording here says 'When a user interface has keyboard focus". So I guess there is time-based, but no specific wording about persistence

<jon_avila> Bye

- DRAFT -

AGWG-2022-03-08

08 Mar 2022

Attendees

Contents

ACT Update (Wilco)

WCAG 3 Requirements Survey https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/

Question 2 - Revising true/false statement

WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Question 1 - Focus appearance Updates

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output