– DRAFT –
AGWG-2022-11-22

<laura> https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<JenStrickland> Here's the scribe list with link to instructions: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Scribe_List

<StefanS> Charles: any announcements?

Subgroup Check Ins

<StefanS> Regina: agenda?

<StefanS> Charles: bringing that up right now

Subgroup check in

<StefanS> Shawn: some updates to give

<StefanS> Shawn: conformance options about next steps meeting, we need to finalize next week

<StefanS> Charles: any other subgroup?

<StefanS> Jeanne: Sirver TF works on TPAC projects .. outcome of user needs .. we show them whenever we're scheduled

Revisit Evaluating Procedures PR https://www.w3.org/2002/09/wbs/35422/PR653/

<StefanS> Charles: other individuals with experience will be involved .. any other missed updates from subgrousp?

<StefanS> Charles: move on 1st survey

<StefanS> Charles: agree to merged PR? Specific to editors note .. some individuals have reccommendations

<StefanS> Charles: goes outside of original note

<StefanS> Charles: 2 individuals want to merge PR

<StefanS> Charles: is jennifer available?

<StefanS> Charles: (reads what jen wrote)

<StefanS> Charles: I didn't see changes in the edit, Jen?

<StefanS> Jenifer: there was change but super-tiny

<StefanS> Jennifer: something was wrong in paragraph

<StefanS> Jennifer: seems to be consolidated now

<StefanS> Charles: (reads other comments)

<Chuck> +1

<Jem> response is here https://www.w3.org/2002/09/wbs/35422/PR653/results

<StefanS> Charles: +1 to that

<StefanS> Charles: Gregg says that it confuses outcomes .. different things mixed to different ways

<StefanS> Gregg: this was written before and is behind actual discussion .. terms have been defined different now

Evaluating Procedures

<StefanS> Jennie: I will comment mine .. unconfortable with reference to COGA materials .. COGA TF is working on atesing plan .. and the way it is presented here the COGA TF is likely uncomfortable with

<StefanS> Jennie: COGA TF need to put consensus on this .. we need verification for every page

<Zakim> Rachael, you wanted to address Jennie's concerns (after queue opens)

<StefanS> Rachael: we will commit always circling this back to COGA .. we go ahead and consider merging it with two notes

<StefanS> Rachael: wid did make the change on TF teporarily

<Chuck> proposed RESOLUTION: Accept amended PR 653 and merge with 2 notes to address the need for the definitions and to replace the examples long term (next update) with Coga's

<StefanS> MichaelC: are we talking about same thing ? ay changes missed?

<Chuck> proposed RESOLUTION: Accept amended PR 653 and merge with 2 notes to address the need for the definitions and to replace the examples long term (next update) with Coga's

<StefanS> Charles: .. replace examples longterm with COGA examples

<StefanS> Charles: first refine the notes

<Jennie> +1

<Chuck> +1

<kirkwood> +1

<Jem> +1

<laura> +1

<JenStrickland> +1

<maryjom> +1

<StefanS> +1

<ToddL> +1

<OliverK> +1

<Regina> +1

<GreggVan> +1

<JakeAbma> +1

<Rachael> +1

RESOLUTION: Accept amended PR 653 and merge with 2 notes to address the need for the definitions and to replace the examples long term (next update) with Coga's

RESOLUTION: Accept amended PR 653 and merge with 2 notes to address the need for the definitions and to replace the examples long term (next update) with Coga's

WCAG 2.2 issue resolutions https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/

<StefanS> Charles: WCAG 2.2 review

Question 1 - Difficulties with inconsistency of Target Size (Minimum) #2695

<StefanS> Charles: rest of the meeting is all about that

<Jem> https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results

<StefanS> Charles: very long thread .. unintuitive results with lists where some fail .. radius approach suggested .. wilco proposed update

<StefanS> Charles: there is separate discussion about inline links exist

<StefanS> Charles: wilco on call? (reads what he wrote)

<StefanS> Charles: (reads Gregg notes)

<StefanS> Gregg: current def of offset .. if buttons overlap .. is problematic .. can always push one side of a button .. but makes no sense

<StefanS> Gregg: also z-Order issues .. measure from middle of button to edge of other button

<StefanS> Gregg: different sized objects have other issues .. what to take for measurement .. what to take as center and what is the offset then

<Chuck> Stefans: I imagine a square, size of a fingertip, placed on an object. Mobile scenarios have exactly that. I ask, where I would put the finger, I would start tapping on that.

<Chuck> Stefans: I would try to get to the center of the object, I would count white space and half that. Then you avoid overlapping issues.

<Chuck> Stefans: I count the white space and divide by half. This gives amount of pixels in size. I would expect here.

<StefanS> Charles: (reads Gundulas comments)

<StefanS> Gundula: def from furthest to closed has issues

<StefanS> Gundula: target offset discussion is close to that .. I suggest some changes to the definition .. user should hit the intended target and nothing else .. how can we measure vertical alignment?

<StefanS> Gundula: (explains her measusing concept in detail)

<StefanS> Charles: Mike? Should I read yours? (reads Mikes comments)

<Zakim> GreggVan, you wanted to say Perhaps the simplest is to say "there must be at least XX pixels between some single point in a target and the closest edge of all other targets". This combines the original with gregg and StefanS -- and accomplishes the goals of all three. And is easier to understand. Also suggest that we rename it something like "Effective Target Clearance

<Detlev> +1 to Alastair's simple solution

<StefanS> Alastair: Had an Idea .. draw 24x24 square over target .. want to hear the others

<StefanS> Gregg: lets combine the ideas of teh people (explains his idea)

<StefanS> Gregg: "effective target clearance" term

<Zakim> mbgower, you wanted to say 12px from the centroid seems like it might be the easiest way to express it. The calculation may be complicated for strange shapes but seems to work

<mbgower> * Spacing: The center/centroid of a control is at least 12 CSS pixels away from every adjacent target;

<StefanS> Mike: building of couple of comments .. spacing center is 12 css pix away from boundaries

<Zakim> Chuck, you wanted to ask about Alastair's suggestion

<StefanS> Mike: pretty easy to understand .. rectangles generally are

<Detlev> Mike: What about a ring-shaped target?

<Zakim> GN, you wanted to Alastair's suggestion (and Stefan's): the box shouldn't overlap neither with any other target nor with any other target's box

<StefanS> Charles: how this would work Alistair with your concept?

<StefanS> Gundula: not overlap with target OR their box ,, better?

<StefanS> Gregg: sometimes you have to select states, sometimes something else .. target type does matter in overlapping

<Zakim> alastairc, you wanted to propose next steps

<ToddL> I could potentially imagine target overlap when subgrid is implemented by Chromium maybe. I may be wrong.

<StefanS> Alistair: I'll take it from here. Gundula, we needs some testcases for that (discusses special cases) .. also Greggs def of target needs to incude nested targets .. we have solid proposals on the table .. can use friday meeting to work this out .. result should be mathematically to test

<mbgower> 8am pacific

<alastairc> 11am Boston. Ah, sorry about the day!

<StefanS> Charles: (we need to find an approppriate date)

<StefanS> Gregg: maybe offline via googledoc?

<StefanS> Alastair: I set up a google doc and send link around

Question 2 - Better clarity on inline targets for Target Size #2767

<Detlev> include me in

<StefanS> Charles: inline links can be difficult to measure

<StefanS> Charles: (reads comments)

<alastairc> This list is a key case: https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Standards

<StefanS> Charles: links in text cannot be increased in height

<StefanS> Charles: wilco wanted something else .. (reads wilcos comments)

<alastairc> I'm not sure how a navbar is not considered human language?

<StefanS> Charles: Gregg you wanted something else (reads Greggs comments)#

<StefanS> * Jem OK

<StefanS> Charles: reads Gundulas comments

<StefanS> Charles: (reads Alistairs comments)

<StefanS> Alastair: short summary of a long discussion ..

<StefanS> Mike: we touching in these comments many trhings .. line height for instance

<StefanS> Mike: you can have list of items, some aof them are link, some of them not etc .. horizontal separators to separate links .. how do we line up sentences?

<alastairc> Inline: A dimension of the target is defined by the same dimension of inline text.

<Zakim> alastairc, you wanted to suggest something

<StefanS> Mike: we can add these in an understanding document - what the difference between links in various different conztainers

<StefanS> Alastair: i can live wit set of exceptions .. but quite difficult to interpret .. list in main area body tag? or what? (proposes different approach for links)

<Jem> +1 to Alastair's idea of updating the exception

<Jem> adding info to inline

<StefanS> Alastair: half part of web content wouldn't pass when we are too strict .. so we need to have take care

<StefanS> Alastair: (proposes other approach for exceptons)

<mbgower> no

<StefanS> Gregg: comments are public?

<StefanS> Alastair: yes

<StefanS> Gregg: copy and paste of comments should be possible

<Jem> That is what I will do as a scribe - copying the response to the meeting minutes.

<StefanS> I learn a thing any day

<ShawnT> Maybe another person besides the scribe could do that

<Chuck> Michael's suggestion is option A.

<Jem> MG's suggestion is "The control is in a sentence, or in a sentence fragment within the main content."

<Chuck> Alastair's suggestion is Option B.

<alastairc> Inline: A dimension of the target is defined by the same dimension of inline text.

<mbgower> Both are useful.

<Jem> alastair's suggestion is adding excpetion to inline definition

<Chuck> poll: Do you prefer option A, option B, or C: Neither

<Chuck> A

<Detlev> Alastair: what about lists )and links within) with slightly different line heights

<Jem> Alastair: "Where list items contain non-link text, the list is considered to be body text and part of the inline exception."

<Jem> ..."Inline: Inline: The size of the target (height) is restricted by the height of adjacent non-link text-content."

<mbgower> line spacing?

<alastairc> B, could live with A.

<Jem> good question, Detlev.

<Zakim> GreggVan, you wanted to say a dimension of the target is restricted by the spacing between lines of text

<alastairc> https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Standards

<StefanS> Gregg: dimension o target is restricted by spacing between different lines of text

<mbgower> D: I think both approaches are worth pursuing, and see which one is more successful

<Jem> Greg: what do you mean by various text links?

<Jem> alastairc:

<Jem> if you see the wikipedia page, it has various types of links in main, footer, and navigation

<Zakim> Chuck, you wanted to discuss mbgower's option D

<Jem> ...so we can see various link types

<Jem> greg: that clear my question.

<Jem> mg: both approaches tackle the same problem

<Jem> ...in Wiki page, there are vertical list of links and so many different types of links

<Jem> Chuck: Alastair will create the PR..

<Zakim> GreggVan, you wanted to say suggest option e) " a dimension of the target is restricted by the spacing between lines of text for the language"

<alastairc> I think a google doc with image exampltes will be better than PRs at this stage

<mbgower> +1 to alastair's comment

<Jem> +1 greg including other languages

<GreggVan> +1 to alastair

<GreggVan> +1 to alastair to move to friday meeting

Question 3 - Removing 4.1.1 Parsing from WCAG 2.2

<Jem> response for the topic is available at https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq13

<Jem> PR is at https://github.com/w3c/wcag/pull/2797

<Zakim> alastairc, you wanted to say Gregg's suggestino is included now

<Jem> greg's comment is just a tweak to change

<Jem> "The following content is left for historical purposes."

<Jem> "The following content is left for historical purposes to show the original intent."

<Chuck> proposed RESOLUTION: Accept PR 2797 to remove 4.1.1 Parsing from WCAG 2.2.

<Jem> alastairc: It is incorporated.

<mbgower> +1

<wendyreid> +1

<Jem> +1

<GreggVan> +1

<Rachael> +1

<alastairc> +1

<Chuck> +1

<ShawnT> +1

<AWK> +1

<SuzanneTaylor> +1

<AWK> +AWK

<maryjom> +1

<kirkwood> +1

<GN015> +1, also with Gregg's amendment

<Jem> alastairc: Awk did mapping on ...

<Chuck> proposed RESOLUTION: Accept amended PR 2797 to remove 4.1.1 Parsing from WCAG 2.2.

<Caryn> +1

<alastairc> Mapping doc: https://docs.google.com/document/d/1MJ6FxO7ujQ4X9BQtAnDDoWyvpAKU44MR4h-bob9SG7M/edit

RESOLUTION: Accept amended PR 2797 to remove 4.1.1 Parsing from WCAG 2.2.

Question 4 - Focus Not Obscured (minimum) should not prohibit cookie popups #2551

<Jem> response is at https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq4

<Jem> question is at https://github.com/w3c/wcag/issues/2551

<alastairc> Noting some votes are from last week...

<Jem> Greg and Wilco wanted to have update with adjustments. Greg is fine

<Jem> stefan wanted something else, "All cookie popups require user decision on storing, therefore focus is in popup and never behind, this is a pseudo debate."

<alastairc> Current proposed addition to the understanding doc:

<alastairc> A notification implemented as sticky content, such as a cookie banner, will fail this Success Criterion if it obscures an element with focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding">scroll padding</a> so the banner does not overlap other content. Notifications that do not require

<alastairc> user action could also meet this criterion by closing (dismissed) on loss of focus.

<Zakim> alastairc, you wanted to query Stephan's point

<Jem> alastairc: regarding stefan's point

<Jem> ...there is wide discussion behind it

<Jem> ... wilco and greg's points are addressed

<Jem> greg is addressing his two comments in the response

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

<Jem> above PR address Greg's points

<Jem> removing mandatory word and ..

<Jem> added "<p>A notification implemented as sticky content, such as a cookie banner, will fail this Success Criterion if it obscures an element with focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding">scroll padding</a> so the banner does not overlap other content. Notifications that do not

<Jem> require user action could also meet this criterion by closing (dismissed) on loss of focus.</p>"

<Zakim> Chuck, you wanted to ask about PR 2611

<Jem> greg: that answers to my question

<Jem> https://github.com/w3c/wcag/pull/2611/files also address wilco's issue

<Chuck> proposed RESOLUTION: Accept amended PR 2611 to address issue 2551.

<GreggVan> +1

<Jem> +1

<ShawnT> +1

<Chuck> +1

<OliverK> +1

<Detlev> +1

<alastairc> +1

<Rachael> +1

<JakeAbma> +1

<mbgower> +1

<alastairc> Chuck - suggest skipping 5 until 1 & 2 are resolved.

<ToddL> +1

<maryjom> +1

<StefanS> +1

RESOLUTION: Accept amended PR 2611 to address issue 2551

Question 6 - How does 2.4.12: Focus Not Obscured relate to opacity #2583

<Jem> response is available at https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq5

<Jem> question by wilco is "When a component is focused, and the component is covered by an element with an opacity of 95% would that count as obscuring? What about if the opacity is 5%?"

<Jem> Chuck is reading the comments from Melalnie and Wilco

<Jem> Greg: I suggest the change "Suggest following that sentence with a more direct sentence something like "When a focus cursor can be covered by a semi-opaque component, the ability of the focus cursor to pass 2.4.11 should be evaluated (and pass) while the focus cursor is under the semi-opaque component. "

<Jem> ...to provide simpler language and suggest what it can be done

<Zakim> mbgower, you wanted to say 'obscure' versus 'entirely hidden'

<Jem> MG: what "arguably" is trying to do ...

<Chuck> ack "ob

<Jem> ...differnt form of obscuring

<GreggVan> "When a focus cursor can be covered by a semi-opaque component, the ability of the focus cursor to pass 2.4.11 should be evaluated (and pass) while the focus cursor is under the semi-opaque component. "

<Jem> .. and trying to preemble @@@

<Zakim> Chuck, you wanted to ask if "obscured" addresses Melanie's question

<mbgower> While less than 100 percent opacity is obscuring the component but not causing it to be "entirely hidden"...

<alastairc> Another form of obscuring can occur due to light boxes or other semi-opaque effects overlapping the item with focus. While less than 100 percent opacity is not causing the component to be "entirely hidden," such semi-opaque overlaps may cause a failure of <a href="https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html">2.4.11 Focus Appearance</a>. When a focus cursor can be covered by a semi-opaque component, the ability of the

<alastairc> focus cursor to pass 2.4.11 should be evaluated (and pass) while the focus cursor is under the semi-opaque component. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus.

<Jem> MB: Alastairc and I are in the same page. We can work on simplifying the lanauges and removes the word, arguably

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

<Jem> alastairc: you can see the chages in above PR files

<mbgower> +1 that works

<mbgower> correct

<Jem> melanie: confirming what Alastair addressed in the PR

<GreggVan> For sighted people who use a keyboard or keyboard-like device (e.g., a switch, voice input), knowing the current point of focus is very important. However, when progressing through a page, other content may potentially hide the focused element. This Success Criterion ensures that the item receiving focus is not entirely hidden by other content created by the author.

<Jem> mg: changes is "Another form of obscuring can occur due to light boxes or other semi-opaque effects overlapping the item with focus. While less than 100 percent opacity is not causing the component to be "entirely hidden," such semi-opaque overlaps may cause a failure of <a href="https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html">2.4.11 Focus Appearance</a>. When a focus cursor can be covered by a semi-opaque component, the ability

<Jem> of the focus cursor to pass 2.4.11 should be evaluated (and pass) while the focus cursor is under the semi-opaque component. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus."

<Chuck> proposed RESOLUTION: Accept amended PR 2671 to address issue 2583.

<alastairc> I'm going to change cursor to indicator.

<Jem> +1

<mbgower> +1

<Chuck> +1

<GreggVan> +1 to that

<ShawnT> +1

<laura> +1

<GreggVan> +1 to resolution

<ToddL> +1

RESOLUTION: Accept amended PR 2671 to address issue 2583

<Detlev> +1

Question 7 - An attempt to simplify/clarify 2.4.11 Focus Appearance #2687

<Jem> response is available at https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq7

<Jem> alairstair's response is at https://github.com/w3c/wcag/issues/2687#issuecomment-1308736768

<Jem> MG: I do like how the 3:1 contrast has been pulled out so it is only stated once. It would be worth exploring if we can extract that.

<Jem> Wilco's response is "We should answer Eric's broader point about this SC being too complex for level AA. As he points out, he's not the only person who has concerns about this. I don't think we should dismiss that. Personally, I think it would be good if we did some reliability research for this. Maybe get 20 experienced auditors to test a page with some focus indicator complexities on it. That should at least give us an idea of where this SC is in

<Jem> its inter-rater reliability."

<Jem> Caryn: Eric's suggestion makes testing easier

<Jem> ...and improve understandabilty

<Jem> ... outweigh any concerns

<Zakim> alastairc, you wanted to suggest taking on Wilco's suggestion about testing with people

<Jem> ... my co-worker is also agree with Eric's comments

<mbgower> I would object, for sure

<Jem> alastairc: two separate things, one is interreliability research and the other is about responding to the raised issue

<Zakim> Chuck, you wanted to ask about doing the research before approving the resopnse?

<Jem> alastairc: two things can be pararell

<Jem> ... worth to try to simplfy color contrast..

<mbgower> Yeah, I'll give it a shot, and I agree it is a 'long' shot

<Chuck> proposed RESOLUTION: Accept proposed response to address issue 2687 and perform Wilco's proposed research in parallel.

<Jem> +1 MG

<Jem> MG: suggesting that taking constrast as the separate area and working on it

<Jem> ...regarding Caryn's point

<Jem> ... there are good examples by alaistair about challegnes

<Chuck> proposed RESOLUTION: Accept proposed response to address issue 2687 and perform Wilco's proposed research in parallel.

<alastairc> +1

<Jem> +1

<ShawnT> +1

<laura> +1

<Caryn> +1

<Rachael> +1

<mbgower> +1 and I'll attempt to reorg as per the issue

<Chuck> +1

<JakeAbma> +1

<Detlev> +1

RESOLUTION: Accept proposed response to address issue 2687 and perform Wilco's proposed research in parallel.

Question 8 - SC 2.4.11 "Focus Appearance" on WCAG 2.2 Candidate Recommendation #2689

<Jem> response is available at https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq8

<Jem> caztcha raised issue 2689, trying to reform the SC into simpler text.

<GN015> Did we skip question 5? If so, was it intentionally?

<Jem> Wilco 's comment is "I think what is "continuous" is fairly debatable. Is a 200 px wide slider with 5 options continuous? What about 50? what about 500? Where do you draw the line here. Even something like a color picker isn't truly continuous. It's a range between 0 and 255. It's all pretty arbitrary, and then starts to depend on things like how much pixel density does the screen have.

<Jem> We should stay out of this and just exempt all sliders. WCAG has other requirements that ensure further accessibility of them, such as 2.1.1 keyboard."

<mbgower> I think Wilco may have cross referenced the wrong survey question, or the survey numbers changed

<Jem> alastairc: wilco's response should be from q8, not q9

<Jem> ...question number is changed

<alastairc> GN015 - yes, it was intentional to skip 5, we need to do the other parts of Target size first.

<Chuck> proposed RESOLUTION: Accept proposed response to address issue 2689

<Jem> s/Wilco 's comment is "I think what is "continuous" is fairly debatable. Is a 200 px wide slider with 5 options continuous? What about 50? what about 500? Where do you draw the line here. Even something like a color picker isn't truly continuous. It's a range between 0 and 255. It's all pretty arbitrary, and then starts to depend on things like how much pixel density does the screen have.

<Jem> 11:37 AM

<Jem> 11:37 AM

<Jem> We should stay out of this and just exempt all sliders. WCAG has other requirements that ensure further accessibility of them, such as 2.1.1 keyboard."/ /

<alastairc> +1

<Chuck> +1

<Jem> +1

<ShawnT> +1

<mbgower> +1

<Rachael> +1

<Detlev> +1

<GreggVan> +1

<ToddL> +1

<laura> +1

<kirkwood> +1

RESOLUTION: Accept proposed response to address issue 2689

Question 9 - 2.5.8: Are all slider variants excluded or only sliders that look and are operated like sliders #2713

<Jem> response is available at https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq9

<Jem> Jaws-test asked in issue 2713 whether sliders with distinct areas counted as continuous in Dragging.

<Jem> https://github.com/w3c/wcag/pull/2718

<Jem> MG: I agree with Wilco. Slider case bothers me.

<Jem> alastairc: we talked about target size

<Jem> patrick updated the content

<Zakim> mbgower, you wanted to say that is every slider

<Jem> ...the comments was removed from the slider

<Jem> alastairc: it will be simple pr

<Chuck> proposed RESOLUTION: Accept amended PR 2718 to address issue 2713.

<Jem> mg: yes, it is just removing slider portion

<alastairc> Examples include color pickers displaying a gradient of colors, or editable areas where you position the cursor.

<Chuck> +1

<mbgower> +1

<laura> +1

<Rachael> +1

<Jem> +1

<ShawnT> +1

<maryjom> +1

<Detlev> +1

<GreggVan> +1

<ToddL> +1

<Regina> +1

RESOLUTION: Accept amended PR 2718 to address issue 2713

<Jem> mg: Wilco 's comment is suggesting exempting all the slides

<Jem> ... which is opposite we are thinking. wondering why we shoudl exempt the sliders

<Jem> alastairc: removing the slider as the example is ...

<mbgower> We should just bring to Wilco's attention

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

<mbgower> is Melanie on call?

<alastairc> OK, I'll ping Wilco on that

<mbgower> k

Question 10 - 2.4.12 Focus not Obscured (Minimum) and user opened / controlled content #2751

<Jem> The response is available at https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq10

<Jem> In issue 2751 Melanie asks whether openable content would count towards failures of focus-not-obscured.

<alastairc> Yes, there will be other WCAG 2.2 surveys, but we've focused on (potential) normative text updates first

<Jem> Melanie: Regarding Rachael' point, I agree with her but I did not adress that in my comment.

<Jem> Rachael: we can tweak the words so we can reflect the intention

<Jem> jon_avila: my understanding is that when people are testing is

<mbgower> Yes, that's my understanding too, Jon

<Jem> ...to catch the initial state and add that to the document.

<mbgower> yes

<Jem> melanie: mg's suggestion is losing the focus, not obscuring the focus?

<Jem> ... user purposely loose focus...

<Jem> and collapse the intial view..

<Jem> ... I am trying to cover often used case by content editor

<Jem> alastairc: it does not fail those types of widgets..open and close dialog

<Jem> MG: It is really hard to understand the users' intents - focus in the tab and out of focus without realizing that it obscures the content...

<Zakim> Chuck, you wanted to say I don't think we have time to get to consensus

<Jem> +1 to chuck

<mbgower> Maybe we can work offline on this, Melanie

<Jem> alastairc: I will work on this

<alastairc> On linkedin, it does have a right-hand side panel which obscures some links, and it's a problem...