<Chuck> meeting: AGWG-2023-04-18

<scribe> scribe: ChrisLoiselle

<jon_avila> Hi, could we get an update on WCAG 2.2 timeline and also whether we will be going back to CR or not. Thanks.

Chuck: Asks for scribing for second hour ahead of time.
... Anyone new ? Or anyone with new role?

Lori: I am new. I'm Lori O. and I work in CX within Oracle. Greetings!

Chuck: Any new topics? We can add to backlog
... Any announcements?

WCAG 3 Updated Editors Draft https://www.w3.org/2002/09/wbs/35422/updateEditorDraft23/

<Chuck> https://www.w3.org/2002/09/wbs/35422/updateEditorDraft23/results

<Chuck> https://github.com/w3c/silver/pull/681/files

Chuck: Editor's draft survey is first agenda item. We won't go through first question on editor's draft editorial changes. All are reflected in Pull Request https://github.com/w3c/silver/pull/681/files

Question 2 - Updating Editor Draft - Substantive Changes

Chuck: Moves on to second question Updating Editor Draft - Substantive Changes

<Chuck> https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0023.html

Few comments on WCAG3 requirements doc. We won't address today but can talk to that in future. Just not in scope today.

scribe: Chuck places URL https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0023.html related to topic.

<Zakim> jeanne, you wanted to note an editorial comment that we are still working on - 404 javascript links

Jeanne: We are removing or resolving the 404 error links when we can.

Chuck: I won't read off comments on call. I'll talk to themes.

Andrew S.'s comments around alphabetical order vs. other structured way of displaying.

<Zakim> jeanne, you wanted to say

Jeanne: I added editor's note , leaving in alphabetical order for now, then determine how they go together.

<Zakim> Rachael, you wanted to say we discussed and agreed on alphabetical order at a prev meeting

Jeanne: we don't intend that to persist.

<jeanne> "The list is currently in alphabetical order, but we do not expect that to persist."

Rachael: We noted alphabetical for now to group somehow.

Mary Jo: Mine were edits, they are all set.

<Zakim> jeanne, you wanted to recommend that we remove the section on normative and informative

Chuck: Talks to tests are not normative vs. informative topic that Gregg commented on. On comment 3 of Gregg's.

Jeanne: We don't intend for test to be informative, but we need to explain test as a whole. It may not be a permanent home for this, however logical at moment to read it in one place.
... Recommendation is to remove section of what is informative vs. normative for now and the issue goes away for now.

Gregg: We'd be releasing it but not being able to track entirely. If reading guidelines , comments would need to be made on informative vs. formative. I.e. what conforms vs. what doesn't.
... Alternate suggestion , document but linked or put in appendix and this will be here for now but will be located elsewhere in future. For review, in appendix.

?

Rachael: I am hesitant to break things apart . Adds burden to reviewers. We are publishing and would simply review process.

<Zakim> jeanne, you wanted to say that the actual tests are in a different document.

Gregg: Is putting in appendix or embedding in middle the point? Tests being normative vs. informative is confusing part of this. Methods are in separate document that is not normative , overall organization matters.

Jeanne: The conformance section is the general information, which may be normative. The test themselves are not and are in a separate document. The explanation of how it works with the outcomes makes more sense. If all feel appendix is right move, then that is an option. Having the information about testing in one section and then tests in informative section in another section is point.

Chuck: There may be confusing as to what is informative vs. formative. To Gregg's point. Propose to write informative vs. what is formative is still in process and which are which is under way.

Gregg: If it is a standard, it is pre-defined what is and what is not . Normative is have to do to conform.
... I am concerned we are confusing people.

<jeanne> +1 to Lori and usability of the document

<Luis> +1 to Lori0

Lori: As a user of WCAG Guideline , appendix move would not be a good idea. General info then all in same place is useful from end user. If breaking up in to appendix , may not be read.

Chuck: One of goals is better and understandable set of guidelines.

<Ryladog> me/wonders if the history of a country making "Techniques required" fiasco has already been brought up earlier in this discussion?

Gregg: Tests in a separate document already, so information in two places . Methods and tests in separate document. Methods and techniques. What is part of guideline vs. what is not. Suggestion on appendix was to not have separate documents mapping outside of document we are talking to, to capture it one document.
... It is supposed working draft of document vs. overview document of how these documents work.

<alastairc> That's what the "explainer" was for

<Zakim> jeanne, you wanted to suggest that we put a comment on the Testing section that it is informative

<Chuck> +1

Jeanne: I would suggest we put a note on section 4.1.1 Testing ...that this is informative

<jeanne> 4.1.1 and 4.2.5

<Rachael> +1 to adding qualifying information as this is information about the content and not the content itself

<Luis> +1 to labeling as informative for 4.1.1 and 4.2.5

Gregg: I would place a note that these are informative. As well as what is in a separate document vs. what is included here (more information on how to understand how future document is potentially to be showcased).

Chuck: Support of labeling as informative to make it clear.

+1 to make it clear what is and what is not informative, to Gregg's point

<Lauriat> +1, sounds good

Chuck: To 4th point of Gregg's: Implies Guidelines are formative.

<Zakim> jeanne, you wanted to say we should not lrestrict ourselves to to informative guidelines

4)The guidelines section header reads: "Guidelines This section (with its subsections) provides requirements which must be followed to conform to the specification, meaning it is normative."

PROBLEM: This seems to imply that guidelines are normative. They are informative. Only outcomes and definitions are normative per previous discussions.

SUGGESTION: same as previous point

Jeanne: I disagree with what Gregg is mentioning. Talks to guideline level and scoring and normative guidelines and testing proposals for viability and validation . Guidelines may not be informative.

<Cyborg> +1 to avoiding premature limitations

<Lauriat> +1 to Jeanne, getting a bit ahead of ourselves if we stake that out now

Jeanne: I'd be very hesitant to do this.

<Luis> +1

Rachael: This is an outstanding topic off of TPAC and is outstanding.

Gregg: We'd have to tag all of these for whether they are normative vs. informative. We need to work on outcomes, but the guidelines wouldn't qualify as normative. They have to be testable statements. Can't require if you can't state if you've met it.

Organizing scores by guideline is another topic.

<Lauriat> +1, all placeholder

<Chuck> +1 placeholder

Rachael: I would believe we'd be marking these as placeholder prior to exploratory at this point, so no way final.

<Rachael> Confirming the guideline section is marked placeholder

Detlev: Pass / Fail vs. conforms, I think language wise we still need to work through all this. Aggregates of , number of tests. If something passes vs. not , uses car emissions example (MoT)

Gregg: Conformance section vs. guidelines . Car must be safe. We can't tell you what safe is.

<Cyborg> +1 to risks referenced by Gregg.

Gregg: We are going to have outcomes . A general guideline , i.e. things should be readable and understanding. If this is normative, if we have 10 things someone needs to meet, then if someone does 10 things, then it would be accessible. We want people to do more than what required to test. We want to have people go above what is testable.
... The discussion on guidelines normative vs. informative needs to be defined. We don't want to cut off groups due to how we are phrasing things.

Cyborg: I appreciate Gregg clarifying risk. I wanted to add another dimension. On CSUN meeting. On proactive approach. Engaging authors to be more proactive vs. reactive.

<Zakim> Chuck, you wanted to say I want to honor our past decision and not make that decision today, can we emphasize "placeholder"?

Guideline level dimension that could be considered that are informative .

Chuck: CSUN's discussion will be out scope today.

<Zakim> jeanne, you wanted to say this is speculation

Jeanne: This is placeholder. Early to have this conversation. Speculation on equity is too early. Actual guidelines built need to be in place then talk to what proposal actually does.

<Chuck> +1 to note

<Wilco> +1

<Lauriat> +1

<Chuck> +1

<GreggVan> whether Guidelines should also be normative or not"

<Zakim> Rachael, you wanted to address risks

Cyborg: I agree on premature topic. I wanted to note lists of risks to fall back into. I wasn't bringing CSUN in to this discussion , rather than just stating that is where it started. Goal would be expectation to have proactivity , early and often in development of guidelines . Early adoption needs to be considered.

Rachael: That would be against master list of questions we are tracking, email master list to add that to the list.

<Cyborg> Will email chairs re need to list identified risks (e.g. the normative vs informative question) as well as the need to address the proactive adoption issue at the guideline level (not only as part of the conformance model)

<jeanne> +1 to Detlev analysis

<Chuck> +1

Detlev: Conforming vs. not conforming discussion. We need to have complete list of outcomes for guidelines. Some may not be easy pass or fail. Need to measure to understand what we have for sufficient for outcome. Uses tire inflation example.

<Zakim> GreggVan, you wanted to say "This section contains the Guidelines as well as the Outcomes which will be grouped under the guidelines. The conformance and definitions are the

The pass fail and grey area is what I was mentioning.

<Chuck> +1

Gregg: talks to his post within Zakim . This would invite comment on this topic without pre decision.

Chuck: on 7th topic. Outcomes and Tests. Any additional points?

Gregg: This makes it sound like Tests are part of conformance -- and they are not.

Mentions *Learn how to meet guideline*

Chuck: We should make a document on how to ?

Gregg: Talks to need for architecture of WCAG 3. I.e. the how to , methods etc. Simple picture would help people how each go together. We have pre assessment checks, Education and Outreach should be involved. What tools, what should you do prior to test?

Chuck: Are you willing to take a shot of phrasing this?

Gregg: Sure.

Topic 10 - user generated content , third party, small business . All things on whether or something like this should happen. I.e. policy and accountable, etc.

<Laura> +1 to Gregg regarding 3rd party content.

Gregg: We should be weary of policy statements, have to phrase it correctly. Should be in some type of document on how it should be applied.

<Lauriat> The pull request doesn't seem to add that, already in there and we've just updated a word in the paragraphs?

Gregg: Recommendation would be removed from here and put in to another area.

<Lauriat> I see https://github.com/w3c/silver/pull/681/files"site" to "website"

Chuck: Not understanding SL's question.

<alastairc> I.e. this PR doesn't change that aspect, so the comment would lead to a separate change.

Shawn: The section already exists, seems off topic as it is only a word change.

Gregg: Request was to review doc before releasing it. I was reviewing it on that context, before we released it.

Rachael: We are looking at entire document. We re-opened topic on what we agreed on prior. I think it is already in editor's draft so a bit of both.

Gregg: My comment stands that it shouldn't be in guidelines.

<jeanne> jeanne notes that the User Generated Content section was published in a Working Draft of 7 December 2021

Chuck: If you are able to leave it here and we visit in future, I feel that is best path forward.

Gregg: I agree to move along.

<Laura> +1 to revisit

<Chuck> propose RESOLUTION: Accept amended substantive changes to editors draft, and craft notes for further review by the group.

<Rachael> +1

+1

<Chuck> +1

<Luis> +1

<Lauriat> +1

<ShawnT> +1

<bruce_bailey> +1

<GreggVan> +1

<Laura> +1

<jeanne> +1

<Detlev> +1

<Jaunita_George> +1

<kirkwood> +1

<LoriO> +1

RESOLUTION: Accept amended substantive changes to editors draft, and craft notes for further review by the group.

RESOLUTION: Accept amended substantive changes to editors draft, and craft notes for further review by the group.

WCAG 3 Review the Alternative Text Guideline Work from TPAC

Chuck: Rachael and Alastair , is there priority to WCAG 2 prior to WCAG 3?
... Hands off to Jeanne.

Rachael: To spend time WCAG 3 and TPAC Alternative Text Guideline Work and results of that conversation.
... exploratory alt text discussion.

Jeanne: I apologies, please postpone alt text discussion.

Chuck: More about process itself.

WCAG 2 Wrap up all outstanding normative issues on WCAG 2.2

Chuck: Hands off to Alastair.

<jon_avila> Could we please get an update on WCAG 2.2 timing? If we will need to go to CR again?

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

Alastair: This is end of WCAG 3 discussion.
... We are going to CR on WCAG 2.2 .

We will send call for consensus out , possibly soon.

<jon_avila> thanks

Focus appearance to AAA and attempted to simply it. Two bullet points about what qualifies.

strengthened requirements .

<scribe> dropped last bullet about 2 pixel parameter.

Yes.

<AWK> +AWK

Gregg: On focus appearance , nobody is going to notice if it is separated by a pixel. If it wider but not butting up against, the corner of their eye won't be able to tell them. I'd add the 2 pixel, but add a 1 pixel gap.

If it doesn't contrast with background, it wouldn't be noticed.

the change in contrast doesn't matter unless you notice it.

<Rachael> scribe+

it needs to contrast with background.

<Zakim> mbgower, you wanted to say the existing SC also allowed that

Thanks, Rachael.

<Rachael> mbgower: Gregg, for context, I'm not disagreeing with you, especially in the scenario when there is no other button to compare it.

<Rachael> ...it was allowed to exist as it was at the AA. We could require it at the AAA but I think we've run out of runway. It can certainly be in the understanding...

<Rachael> I think it is in the understanding document. But unless everyone agrees and we can work out the ramificaitons, we need to skip this.

<Rachael> LoriO: I disagree with Gregg. Coming from someone who works every day with the guidelines, adding a offset, makes much more work for the developers. We already have the second list item on contrast ratio.

<Rachael> ...I don't think we should add extra work for developers.

<Rachael> GreggVan: I have a black button on a white background. My accent is a black ring. The ring has a sufficient contrast ratio. I have no way to tell the button has focus unless I was looking at the button when it changed.

<AWK> Wouldn't gregg's example fail 1.4.11 Non-text Contrast?

<Zakim> alastairc, you wanted to discuss the compliucations

<Rachael> jon_avila: It is absolutely an issue that was raised before. I agree with Gregg but I also think we are out of time. Is there still benefit in this at AAA as it is? Given the time, I don't think we can make that modification.

<Rachael> alastairc: AWK points out that Gregg's example would fail 1.4.11 because there is not contrast between the button and the focus indicator. We were moving this to AAA because of the more complicated situations of overlapping. Easy to think of the simple examples but there is a lot of complexity. I would hesitate to make this change without going through the various examples.

<AWK> SImilar to figure 9 on https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

<Rachael> GreggVan: First of all, can you explain how the other one solves the problem. If that solves the problem, then I am happy. If not, then this is the 5th time I've raised this. Its like if we ignore something long enough then we can claim the clock runs out.

<Detlev> @Lori Oakley: adding a gap between element and focus outline is literally just on line of CSS so hardly a big ask on developers - but I agree there is too little time to rework it now

<Rachael> alastairc: AWK linked to figure 9. I am aware that it has been raised many times before. We were not ignoring it. We were analysing the cost/benefit of the change.

<Rachael> GreggVan: I am reading it and it does say the highlight is an element. Is the highlight considered a component? I

<LoriO> me/ mbgower's idea is good

<Rachael> alastairc: I think the example maybe figure 10.

<Rachael> AWK: Figure 9 fails. Figure 10 passes.

<Rachael> GreggVan: Figure 10 passes but if I showed it to hundreds of people with low vision, they would say they couldn't see focus.

<Rachael> jon_avila: I think that Gregg's example would pass 1.4.11. What is outside compares with outside. What is inside compares with inside. I think we are not recommending this example. I think there are many ways developers could pass this. I think there is still benefit in the SC. I think the other option is that it be removed completely.

<LoriO> @DetLev thank you for your explanation

<Rachael> Wilco: I feel like this is a non-argument. If a button stands by itself and the user has never seen the button, how are they ever going to recognize the focused state. If they don't know the unfocused component, they won't know the focused component.

<Rachael> ...I don't know that there is any kind fo design we can write to ensure that.

<Rachael> GreggVan: I don't think its constructive to say, it may be broken but its either keep it as is or pull it.

<Rachael> alastairc: that is the situation.

<Rachael> GreggVan: This is at AAA. The way to fix it is that at AAA, it needs to have contrast with both sides. or it needs to have an outline on both sides that contrast with it.

<Rachael> ...its AAA. Nobody has to follow this. We all know it would make it better.

<Rachael> AWK: Gregg, to your point, I'm in agreement with Wilco that if the button is viewed by itself you wouldn't know if it is focused or not.

<Zakim> mbgower, you wanted to say the first example in the Understanding document lists an offset as an example https://w3c.github.io/wcag/understanding/focus-appearance.html

<Rachael> ...the only way you know is that you see the others. In others, the thin black line could be the focus. I understand the point you are making but also, that we understand focus by point of comparison. If that is the basis of concern, then I don't think we can address that.

<Rachael> mbgower: The very first example we give is offset. There is an advocacy for offset but its difficult to argue that everything without an offset will fail.

<Zakim> alastairc, you wanted to say that adjacent contrast will exclude some good indicators

<Rachael> ...its difficult to come up with that language.

<Rachael> alastairc: Because this is a less complex version than we had previously, you could have an indicator which doubled the button's size and would still fail the text. The simplicity/bluntness would mean that the visible indicators were failing unless we go back down the route of measuring areas. To Andrew's point about whether its solvable, I think it would be solvable if all indicator's on a site were consistent it would make it recognizable.

<Rachael> That's out of scope. We are not looking into cross component. Something to explore in WCAG 3.

<Chuck> proposed poll: remove the last 2 bullets.

<Chuck> alastair, can you vet that poll? Am I asking the right question?

<Rachael> shadi: Even at AAA this would need more time but we are out of time due to policy uptake, need to focus on WCAG 3, etc. I strongly agree with Alastair as well to address this in WCAG 3 where we can better deal with it there. It is a strong improvement. I wish we'd kept it at AA but AAA is better than nothing.

<Zakim> GreggVan, you wanted to say "if the focus does not have contrast with one side or the other (or both) then a 1 pixel gap is provided between the focus and the non-contrasting

<Chuck> proposed poll: accept the following text - if the focus does not have contrast with one side or the other (or both) then a 1 pixel gap is provided between the focus and the non-contrasting side that has a contrast of 4.5:1 or greater with the highlight."

<Rachael> GreggVan: At AAA, if the focus does not have contrast with one side or the other (or both) then a 1 pixel gap is provided between the focus and the non-contrasting side that has a contrast of 4.5:1 or greater with the highlight.

<Zakim> Chuck, you wanted to say I don't know where the sense of the group is on this, can we do a poll?

<Chuck> proposed poll: accept the following text - "if the focus does not have contrast with one side or the other (or both) then a 1 pixel gap is provided between the focus and the non-contrasting side that has a contrast of 4.5:1 or greater with the highlight."

<Rachael> Chuck: straw poll

<LoriO> question is 1 pixel big enough?

<Rachael> ...+1 to add language, -1 to not add it

<iankersey> -1 are we talking just about buttons here, or links, or other interactive elements? seems ambiguous

<GreggVan> 1+

<dan_bjorge> -1, falls down with gradients and at edge of pages

<Rachael> -1

<alastairc> -1, raises other issues

<AWK> -1

<Detlev> -1 the language needs more work, and I agree with Alastair that this needs testing before making that a normative requirement

<Luis> -1

<Chuck> -.5

<Wilco> -1, too vague

<bruce_bailey> +0

<JenStrickland> -1

<Makoto> -1

<Rachael> Lori: Is 1 px enough?

<mbgower> -1 raises other issues, and just on principle, we've already shown the HUGE number of edge cases we can't anticipate

<Ryladog> +1 - but I like a 2 pixel

<shadi> -1 such last minute addition have high risk of causing unintended consequences

<Chuck> 12 against, 2 for

<JustineP> -1 needs more work

<jon_avila> -.5 because this needs much work to address all situations. I agree with the concept - but it needs to be addressed carefully and this needs more work to be clear and testable

<Chuck> 13 against, 2 for

<Rachael> alastairc: To Lori's question, we did testing with the low vision taskforce but where it was becoming a problem was a 1 px solid line separated by the component was somewhat visible to most people. It was not sufficient if it was the same color as the component and adjacent to the component.

<bruce_bailey> @mgower comment pushes me to -1

<Laura> -.5 needs more vetting

<Chuck> 14 against, 2 for

<LoriO> me /why not change the wording to a minimum of 1 pixel

<Rachael> ...Katie, what we are looking at is requiring 2 pix as the side of the indicator but Gregg is requesting separation.

<Rachael> ...Poll is pretty clear. We know based on the history of this criteria is that every change requires a Lot of testing. A few of us have done much of that and it looks like we have concerns, including myself.

<Rachael> dan_bjorge: Maybe a compromise would be adding a note reminding people about the contrast requirement.

<LoriO> @Rachel +1

<Rachael> GreggVan: Unless you were to define the highlight itself as a component, the other guideline doesn't comply.

<Zakim> Chuck, you wanted to say not really supportive

<jon_avila> SC 1.4.11 applies to focus states - this group has already stated that.

<jon_avila> I do agree we note and I had asked for a note about this last week or two weeks ago as well.

<Chuck> Rachael: I'm hesitant to add a note, cross referencing could be extreme across the guidelines. Maybe taking an action diving into the understanding, I would support that.

<shadi> +1 to consider for the Understanding docs

<GreggVan> concur

<Rachael> Chuck: I know in some other standards we've cross referenced other guidelines, but in many cases we could cross reference so I'm hesitant.

<jon_avila> Yes, understanding.

<mbgower> +1 to add in more about offsets in the Understanding document

<alastairc> draft RESOLUTION: Accept the focus appearance SC text, and review the understanding document

<Rachael> alastairc: I think the understanding needs an overhaul. At AAA this is basically promoting good practice. I suggest we accept the SC text and review the understanding document to incorporate the best practice in the AAA version.

<Rachael> GreggVan: Just suggest in the understanding say however you should also note that buttons that are not next to other buttons need additional consideration.

<shadi> +1

<Chuck> draft RESOLUTION: Accept the focus appearance SC text, and review the understanding document

<Rachael> Bruce: I think that should be both of the following.

<alastairc> draft RESOLUTION: Accept the focus appearance SC text, and review the understanding document, including what happens with individual buttons without comparitors

<GreggVan> +1

<mbgower> +1

<Rachael> +1

<dan_bjorge> +1

<bruce_bailey> +1

<shadi> +1

<Laura> +1

<Wilco> +1

<LoriO> +1

<ShawnT> +1

<iankersey> +1

<jo_weismantel> +1

<jon_avila> +1

<Detlev> +1

<JustineP> +1

<Luis> +1

<JenStrickland> +1

RESOLUTION: Accept the focus appearance SC text, and review the understanding document, including what happens with individual buttons without comparitors

<Rachael> alastairc: Gundala, do you have concerns?

<Rachael> GN: I am not happy but will accept it.

<Chuck> oh cool approach!

<Rachael> alastairc: Noting that we had a copy of Focus Visible but its been removed. That should make no difference.

<alastairc> Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the <a>bounding box</a> of each, the circles do not intersect another target or the circle for another undersized

<Rachael> ...We added the undersized target bit using teh text agreed to last time. Text above.

<Rachael> ...this is in target size minimum using the circle approach we discussed.

<Zakim> mbgower, you wanted to say that we may want to look at the wording we put in notes in the CR about fallback

<Rachael> ...other part. not needed has been removed.

<Rachael> mbgower: I want to make sure we have the wording on fallback that happens should this not pass on CR. I think we are marking it at risk and the fallback is to adopt the existing 2.2 language for target size.

<Rachael> alastairc: Yes, that is correct. The fallback on target size is to go back to current text. If that doesn't get agreement, then removal.

<Rachael> dan_bjorge: Do we have fallback on focus appearance or is that not going with at risk marker?

<Rachael> alastairc: It will get an at risk marker but the fallback is the AA text at AAA and the fallback is removal.

<Chuck> Rachael: Because the group is split, can we add the 3rd fallback of AA with current text, so that we have flexibility?

<Rachael> alastairc: In principle of least objections, that may be the least likely one. Lets discuss that afterwards.

<AWK> /me the WG _loves_ multi-option CFC's! :)

<Chuck> I recall it, I don't recall the decision (or lack thereof?)

<Rachael> Wilco: Did we consider the option of a 24 circle instead of a 24x24 square? Where did that conversation go?

<Rachael> alastairc: There were some odd results when that was the primary bit of text.

<Zakim> Chuck, you wanted to say lets discuss afterwards...

<Rachael> dan_bjorge: I don't recall us finding a specific issue with that in the current text. I agree it would be more consistent for everything to be based on the same shape. My weak preference is changing it.

<Zakim> mbgower, you wanted to say it gets weird on diagonals, is my recollection. The updated Understanding is really good

<Rachael> bruce_bailey: My recollecation is that we were sticking with the square to avoid a 3rd CR but now we are here, we should consider the circle.

<alastairc> +1, Pat's done some great work on the understanding doc

<Rachael> mbgower: Something weird happened on diagonals. It is very helpful to read it.

<alastairc> q/

<Rachael> ...there is something easier about starting with the square, and only if it fails, moving to circles. That's my recollection but I'd have to go back to notes.

<Rachael> jon_avila: I was going to say for me thinking about how people test this, manual testing may be easier with the square.

<Zakim> alastairc, you wanted to say that I'd prefer to stick to the square as the basic, with circle to allow for odd cases

<bruce_bailey> +1 that rounded corners are common

<Rachael> dan_bjorge: I think, as a test tool author, its the opposite case. Buttons with a border-radius set, all you have to test is width and height. If the border is set, you have to calculate. If you want to do it manually, you're better off with a circle than a square.

<Rachael> alastairc: From a simplicity point of view, I find it easier to think it through with a square. 24 pixels isn't that big. Having the 24 is a good basic but you have the more circular measure that makes it easier. You put a square over that target and as long as nothing else is in that square, you're ok.

<Rachael> ...as a last minute thing, I'd rather not change that now. For the exception it doesn't seem too difficult.

<bruce_bailey> +1 to

<Rachael> One more question, are we not revisiting target size enhanced with the language for target size minimum.

<Rachael> alastairc: We had it on survey last week and we will come back with that proposed language for 2.1 and 2.0

<Rachael> Bruce: I was expecting to see the inline in 2.2?

<bruce_bailey> https://github.com/w3c/wcag/pull/3123#issuecomment-1500652549

<Rachael> Wilco: It changed the normative requirement in a way we missed.

<Rachael> alastairc: That was not the inline exception was it?

<Zakim> mbgower, you wanted to say we are looking at the AA right now, right?

<Rachael> alastairc: We can slightly change the target size enhanced.

<Rachael> mbgower: I think we were looking at AA and I haven't seen a resolution on that.

<Rachael> alastairc: It would be good to work out if we are going to align them.

<Rachael> mbgower: Unless we are proposing taking the AAA language into the AA, shouldn't we get hte AA done and then align the AAA with it?

<Rachael> alastairc: We don't need it for CR but do need it for PR.

<alastairc> https://github.com/w3c/wcag/pull/3123/files#diff-951af9e4a0995712c1febbcefe2a63d456ea746283c6983ef89075c7ade89113

<Rachael> alastairc: We don't need target offset. Patrick raised that the minimum bounding box is no longer used in focus appearance but we are using it in target size. I suggest a tweak to the bounding box definition and make it "bounding box"

<Rachael> ...we can remove it but it might be better to reuse it.

<Rachael> ... any objections?

<Rachael> mbgower: Don't we still need that part for target size?

<Rachael> alastairc: Not with the inline exception.

<bruce_bailey> good catch on renumbering !

<Rachael> jon_avila: I suggest we need to reorder a few of the SC.

<Rachael> GN: I note that you say shape. Shouldn't it be more general and say UI element?

<Rachael> ...the last line of the defintion.

<Rachael> alastairc: It depends on how its called.

<Rachael> ...that would be called from target size. Its the bounding box of each target. The undersized target is the thing the bounding box goes around. In that case, the shape is the shape of the target. I think that's ok.

<Rachael> dan_bjorge: I am in favor of adding a definition like this but I don't think you can remove the other definition.

<Rachael> alastairc: You are right.

<Rachael> alastairc: We still need that, I will undo that change.

<Rachael> alastairc: We could have bounding box and minimum bounding box.

<Rachael> dan_bjorge: I think we do want it.

<Rachael> [discussion of coordinate system]

<Rachael> ...likely understood enough.

<Rachael> GN: If I read it correctly, then in the definition of bounding box it is the minimum rectangle. Its the smallest enclosing rectangle.

<Rachael> I think the defintion should say its the smallest enclosing rectangle. I don't know we need it in the title. Can we use the same definition?

<Chuck> Rachael: I support that. I don't see a difference that would cause confusion as to why we have 2.

<Luis> +1 to only having "bounding box"

<Rachael> mbgower: If we add in the new one, if we need both they are there and we can remove it if not needed.

<Zakim> bruce_bailey, you wanted to ask if both aligned to horizontal

<Rachael> bruce_bailey: In bounding box there is content that isn't in minimum bounding box

<Rachael> mbgower: Isn't aligned to horizontal axis doing this?

<Rachael> mbgower and bruce discuss horizontal access applicability. Seeming agreement that one definition will work

<Rachael> dan_bjorge: I don't think the horizontal axis is problematic. Desirable in both cases. I think the ability to wrap onto mulitple lines of text would be problematic.

<Rachael> alastairc: We will take that one away and come up with a proposal on that which I will send around to the group. Feels like we are down to the last bit.

<Rachael> dan_bjorge: I think there is an ommision. We discussed changing the math for a 1 pixel size but we discussed 2 pixel.

<Rachael> alastairc: I believe that's been done but I will find it.

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

<Rachael> ...I'm going to hand it over to Michael on focus not obscure examples. We only have a couple minutes. Can you intro changes?

<Wilco> Instead of getting on queue; Alastair when do you expect the 4.1.1 Parser note for WCAG 2.0 / 2.1 to go out in CFC?

<alastairc> Wilco - Hopefully this week, I got the PR ready today - https://github.com/w3c/wcag/pull/3152

<Rachael> mbgower: Last week we adopted a note for focus not obscured. [reads note]. The issue that opened against focus not obscured tackled situation when the user disclosed content. The notes were not in the same format. In line 10, I've tried to keep the meaning but format it to match the second note. The intention is no change in meaning but reworded as editorial change.

<Rachael> ...the second note addresses issue raised by Melanie.

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

<Rachael> ...There are substantial changes to the understanding document. Teh understanding will go through revisions. The notes are the most important for CR.

<Rachael> Bruce: I agree with breaking out the second note.

<Rachael> mbgower: Whole bunch of info in the understanding document. I wanted to make people aware of the note. I want to get validation from chairs if we can iterate on notes after CR begins.

<Chuck> I must leave too.

<Wilco> I would really prefer we don't do more note work after CR

<Rachael> alastairc: wrapping up.

<bruce_bailey> @mikeg -- hidden by user?

This is scribe.perl Revision VERSION of 2020-12-31
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/404 error links where we can/404 error links when we can/
Succeeded: s/vs. formative/vs. normative/
Succeeded: s/with the border set/with a border-radius set/
Default Present: ChrisLoiselle, shadi, Rachael, MichaelC, Lauriat, Francis_Storr, JustineP, ShawnT, mbgower, jon_avila, alastairc, Makoto, jo_weismantel, Wilco, mgarrish, Raf, LoriO, jeanne, iankersey, Laura_Carlson, sarahhorton, Jaunita_George, Cyborg, Luis, Katie_Haritos-Shea, kirkwood, Detlev, Glenda, maryjom, JenStrickland, bruce_bailey, AWK, dan_bjorge, GN, GreggVan
Present: ChrisLoiselle, shadi, Rachael, MichaelC, Lauriat, Francis_Storr, JustineP, ShawnT, mbgower, jon_avila, alastairc, Makoto, jo_weismantel, Wilco, mgarrish, Raf, LoriO, jeanne, iankersey, Laura_Carlson, sarahhorton, Jaunita_George, Cyborg, Luis, Katie_Haritos-Shea, kirkwood, Detlev, Glenda, maryjom, JenStrickland, bruce_bailey, AWK, dan_bjorge, GN, GreggVan, GN015
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle

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