AGWG Teleconference -- 15 Nov 2022

<Chuck> meeting: AGWG-2022-11-15

<Detlev> scribe: Detlev

Intro by Chuck - Meeting open

Anyone volunteering to scribe?

Chuck: Introduce yourself - anyone new to the group?

Tzviya Siegman (Wiley) introduces herself

<AWK> +AWK

Chuck: Any announcements?

Rachael: Reminder that there is a meeting on Monday at CSUN (hybrid)
... looking for a corporate sponsor - tell chairs if you can contribute

<Chuck> Chaals

<alastairc> Charles Macathy Neville

Rachael: Charles McCathieNevile has been asked to come back discuss culture in the group

<alastairc> Sorry, McCathie-Nevile!

Rachael: Survey will be open for just a week

Silver sub-group report back

Wilco: can Francis gove update?

<AWK> Chaals: https://www.w3.org/People/Charles/

Francis: Gives update on Issue severity subgroup
... looking ant the role of context now in light of the different conformance options
... there should be a decent framework for assessing severity will be presented soon

Jaunita: test requirements subgroup has been writing methods for testing
... using common format
... working on a presentation to share with larger group

Wilco: giving update to Design & Info architecture subgroup

Chuck: goves update of equity subgroup - they are working on crafting a recommendation to present to the WG

<Chuck> ack

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

Chuck: Now going through the WCAG 2.2 misc issues survey

Question 1 - Proposal to Rephrase Success Criterion 4.1.1 #2525

Chuck: reading 4.1.1 part of survey
... question whether validation of content model should be part of 4.1.1
... Reading three options

Alastair: AWK's point on scope of changes - start CR review again - full implementations testing is delayed - we could go back to CR
... if we get support for normative changes we could implement changes outlined in the survey

Chuck: (Reading survey responses from Poornima)

Poornima: Would like to keep SC to make sure mark-up related aspects are retained
... if text is changed to focus on syntactical that is fine

Chuck: reading Joe's comments
... reading Bruce's comment
... (reads David MacDonald's comment)

Alastair: (carries on reading)

<Chuck> +1 to DM's experiences with 4.1.1

<AWK> +1 to David's comments

Chuck: (reads Gregg's comment)
... (reads Wilco's comment)

<alastairc> +1 to Wilco's comments, which speak to Poormina's comment, the SC isn't needed for the original intent

Chuck: (reads Rachael's comment)
... (reads Alastair's comment)
... (reads Michael Gower's comment)

Mike: someone else from IBM will speak to this later

Gregg: deprecation works better thant errata - the latter will take us back to rabbit hole of misunderstandings

<Zakim> alastairc, you wanted to ask Wilco whether there is a problem with an errata for 2.0/2.1, specifying the syntactical aspect.

<kirkwood> ++1 to Gregg’s point

<Zakim> AWK, you wanted to speak in favor of deprecating

Alastair: Not strongly in favor of also doing the errata

<Chuck> +1 to AWK, same experience!

<Rachael> +1 to AWK comment on extraneous errors

<kirkwood> +1 also same experience

<bruce_bailey> +1 to what AWK is saying about 4.1.1 fails being noise

AWK: in favor of deprecation - speaking for audit team, there is no evidence that there are any significant issues not call elsewhere - but a lot of noise that creates work for engineers - there is no impact on end users, so no time should be wasted on it

<Zakim> thbrunet, you wanted to add some historical context to 4.1.1

<alastairc> It would filter down to smaller orgs though, who don't have the knowledge to ignore 4.1.1 issues.

Tom Brunet (IBM): historical context supports deprecation

scribe: lots of historic parsing problems, parsers could not handle faulty markup correctly - now they are a lot better

<GreggVan> +1 to thbrunet - that is exactly why it was added and general validation was not

scribe: so it is no longer needed

Wilco: We need to consider what it means to deprecate something in WCAG

<Zakim> Rachael, you wanted to state that making changes does not stem from a judgement on prior group's competence

<GreggVan> +1 to Rachael

<Chuck> +1, not intended as negative judgement

Rachael: When we choose to make a change that is not a verdict on any previous group

<Zakim> bruce_bailey, you wanted to say the errata *reinforces* the original meaning

<GN015> +1

<Ryladog> +1 to Rachel

Bruce: The errata would just be reinforcing the original intent - unclear we can deprecate only in 2.2

Chuck: Had presumed that deprecation was sufficient - but needs to be investigated

<mbgower_> if aria blows up, you'd fail 4.1.2

Poornima: Opted to keep SC 4.1.1 - HTML is covered but cannot cover ARIA, that would impact end users / SR users

<Chuck> +1 to MG, it's a failure of 4.1.2

<jon_avila> 4.1.1 doesn't cover ARIA other than duplicate attributes missing quotes - it would fall under 1.3.1 or 4.1.2.

Poornima: keep to make sure in can be used wth automation to detect inccorect use of ARIA

<Zakim> alastairc, you wanted to speak to deprecation

<bruce_bailey> +1 to not having in 2.2

Alastair: As to Wilco's comment on deprecation: It should mean removing it in 2.2

<Zakim> AWK, you wanted to speak to at risk

Alastair: but where do we explain that? Possibly under the high level principle 4

AWK: deprecating and mark "at risk" we would onyl do that when moving back to CR - having something in the text why it is gone would be useful.
... argument for removal is that if everything is covered elsewhere, we effectively keep backward compatibilty

<bruce_bailey> +1 to AWK that if 4.1.1 not needed for 2.2 (because other SC) then 4.1.1 is not needed for 2.0 or 2.1 either

Gregg: Bruce make sa good point - the number has to stay there to avoid confusion - if you don't have errata it looks like you are asking for full validation - so errata might in fact be a good idea to explain depreaction

<bruce_bailey> +1 to GV point that 4.1.1 was *never* about validation

<AWK> I don't think that anyone is currently thinking that 4.1.1 requires full validation except for people who don't understand that specific published techniques are not required for conformance.

<Wilco> https://www.w3.org/TR/WCAG22/#cc1

Gregg: deprecation and errata are separate issues, we need to move quickly as to depraction

Wilco: Statements abotu all things at the same level are met includes deprecated SCs so that might not work
... AWK's point as to backward compatability: That may not be true for old browsers - but in modern browsers it would work

<alastairc> qv

<Chuck> Poll: Support deprecating 4.1.1 in WCAG 2.2.

<alastairc> qv?

Chuck: doing a poll
... about deprecation of 4.1.1

<Rachael> +1

<Wilco> +1

<iankersey> +1

<wendyreid> +1

<GreggVan> +1

<maryjom> +1

Not final decision just taking a view where the group stands

<AWK> +1 (supports deprecation)

<bruce_bailey> +1

<GN015> +1

<thbrunet> +1

<Chuck> Poll: Support deprecating 4.1.1 in WCAG 2.2.

<Francis_Storr> +1

<alastairc> +1

<ShawnT> +1

<Chuck> +1

<SuzanneTaylor> +1 in favor of deprecation

<jon_avila> +0

<mbgower_> +1 if we can agree on what that means for reporting :)

<Poornima> 0

<laura> +0

Chuck: If group decides we then address all points necessary for deprecation
... no objection to deprecation

<Zakim> alastairc, you wanted to talk to backwards compatibility

<Ryladog_> Obsoleted

Tom: the definition of deprecation - it means it is still available but will be withdrawn in future version - if it is completely removed, deprecatino may nit be the right term

Alastair: The SC would still catch things like unique IDs - while the SC would find such things, anything impacting a11y would be caught elsewhere
... we don't want people to test on report on it anymore

<Zakim> bruce_bailey, you wanted to say now i want stronger than deprecated

Alastair: deprecation would mena it is still there but not included in results

<Zakim> AWK, you wanted to call it a change so in WCAG 2.2 4.1.1 reads "this criterion is blank and has no requirements"

<SuzanneTaylor> +1 for "deprecated" in 2.0 and 2.1 and removed in 2.2

Bruce: stronger: it is now counter-productive and harmful

<GreggVan> from merriam webster Deprecated is increasingly used as a technical term meaning "to recommend against using something on the grounds that it is obsolete," or "to declare some technological feature or function to be obsolescent."

AWK: agrees with Alastair - the number is still there but there is a statement that it has been removed (no requirement)

<Zakim> Chuck, you wanted to suggest a path forward, now that we have a sense of the group

<bruce_bailey> in federal regulation sometimes there will be a number followed by "reserved" -- but that is not quite right for this context

<Zakim> GreggVan, you wanted to say "depricate and remove it from 2.2 with a note in uder

Chuck: need a recommendation haw to proceed, we don't know what it means - we need to put together a proposal (as Chairs) and put that to the group

Gregg: we should make a resolution like depreacte and remove in 2.2 but we need an explanation in errata if people have to comply to 2.0 or 2.1 so that people now what removal means

<Zakim> tzviya, you wanted to provide typical w3c definitions of errata and deprecate

Tzviya: no strong opinion - how the terms are used - deprecation typically is implementors must use it authors should not use it though, and errata is fixing an error in the spec

<tzviya> https://www.w3.org/2021/Process-20211102/#deactivation

<bruce_bailey> +1 to "rescind" if that is a possibility

Chuck: (to other chairs) let's put together a proposal (with errata draft)

Alastair: agree

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

Alastair: we got the temperature, need to work through. Open question whether we shouls add errata for 2.0 and 2.1

<alastairc> Sorry, wrong PR, this one: https://github.com/w3c/wcag/pull/2793/files

Gregg: Chairs now have a good sense - let's end discussion here let editors figure out how to go about the removal/deprecation

<Ryladog_> +1 to Jon

<laura> +1 to Jon

<ShawnT> +1 to jon

<AWK> +1 to Jon's mapping idea

<alastairc> Any volunteers to work on that?

<GreggVan> +1 to adding to understanding

Jon A: one thing helpful would be to have a mapping in understanding docs, so people know where things should go (1.3.1, 4.1.2 etc) - that resource would help people with transation.

<ShawnT> isn't there already something out there?

<AWK> I volunteer to help

<iankersey> +1 to Jon and volunteer to help on mapping

<Ryladog_> I agree with Jon about not changing 2.0 and 2.1

scribe: would be careful changing older versions - better explain that tech has changed and SC no longer is needed

<Zakim> Chuck, you wanted to ask about errata in 2.0 and 2.1

<laura> Any explanation would be helpful.

<bruce_bailey> fwiw - i do not see harm to 2.0 / 2.1 reputation

Chuck: taking temperature tregarding errata?

<Chuck> Poll: Support errata for 2.0 and 2.1.

Alastair: now thinks it will be better to let it lie as it is - but if people disagree, tell us

<Zakim> bruce_bailey, you wanted to say fix in 2.2 but not 2.0 / 2.1 is bigger risk

Gregg: many people will point to text, so errata on older versions would be good.

<GreggVan> +1 to Bruce's comment

Bruce: disagree that removing it in 2.2 and leaving it in 2.0 and 2.1 is a bigger risk

Alastair: some peopel don't know the original intent - different way of using it exist - like does in include nesting diosallowed in content models

<bruce_bailey> i believe larger risk to reputation to take out of 2.2 and leave it in 2.0 and 2.1

<AWK> If we did do errata for 2.0/2.1 it might be significant enough to publish edited specifications for those also. Most people don't know about or look at Errata.

<Chuck> Poll: Support errata for 2.0 and 2.1.

<Chuck> https://github.com/w3c/wcag/pull/2793/files

Alastair: errata might tell people that people have been doing it wrongly - so may be smopother nit to touch 2.0 and 2.1

<Chuck> +0

<Rachael> +0

<GreggVan> +1

<Wilco> -1

dont know

<alastairc> 0

<SuzanneTaylor> -1

<JakeAbma> 0

<ShawnT> -1

<laura> 0

<bruce_bailey> +1

<Makoto> 0

<Ryladog_> +0

<Poornima> 0

<jon_avila> +-.5

<mbgower_> 0

<AWK> 0 I think?

<iankersey> 0

<Poornima> +1

<alastairc> It would add: "In content implemented using markup languages, elements have complete start and end

<alastairc> tags, elements are nested according to ***the syntactical rules*** of their specifications, elements do not contain"

AWK: Does not mean removing SC from the older standards, correct?

Gregg: Errata just to clarify the intent

<Zakim> bruce_bailey, you wanted to say we do not really have a choice about telling people they have been reading 4.1.1 wrong

Chuck: mixed picture as poll result

<GN015> +1

Bruce: We have to tell people that we are doing it wrong

<Zakim> Rachael, you wanted to say if the errata can be addressed later, can we revisit?

<GreggVan> +1 to rachaels suggestion

<alastairc> yes, we can come back to it

<mbgower_> erratum can happen anytime, AFAIK

Rachael: if we can address errata after 2.2. is through?

Chuck: technically, yes

<Poornima> I can scribe

<Poornima> scribe: Poornima

<alastairc> scribe:Poornima

<Zakim> Chuck, you wanted to ask for scribe change

Chuck: Rachel to your point, we can work on that synchronously, no resolution here, direction to put together on right terminology

<bruce_bailey> +1 to addressing 2.0 / 2.1 after we decide for 2.2

Question 2 - Dragging movement definition might be improved #2669

Chuck: as there are lot of words in synonyms, will propose to the group soon

<bruce_bailey> Yatil's codepen: https://codepen.io/yatil/pen/ExLVpLr

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

<Zakim> alastairc, you wanted to respond to Wilco's comment (i.e. we already reviewed this several times with "down event", think we should stick with it)

Chuck: 9 ppl agreed to go ahead

<Chuck> proposed RESOLUTION: Accept PR2770 to address issue 2669.

<alastairc> +1

<ShawnT> +1

<Chuck> +1

<Detlev> +1

<laura> +1

<bruce_bailey> +1

<JakeAbma> +1

<GreggVan> +1

<iankersey> +1

<GN015> +1

<Ryladog_> +1

<Wilco> 0

<AWK> +1

<mbgower_> +1

<Makoto> +1

RESOLUTION: Accept PR2770 to address issue 2669

Question 3 - Does 3.2.6 Consistent Help allow for content that is under disclosure widget on one page in a set but not another? #2303

<bruce_bailey> issue link: https://github.com/w3c/wcag/issues/2303

<bruce_bailey> link from survey: https://github.com/w3c/wcag/issues/2303

<alastairc> Poornima wasn't sure on what the update was, it is specifically the additional lines on 32-37 https://github.com/w3c/wcag/pull/2612/files#diff-ad8ce666792e846bd80105a61b15ef7d9f31c88814308f6e78ec90b1d43aad4fR32

Chuck: reading the comments

Gregg: this is inconsistent in passes

<bruce_bailey> +1 to GV proposed edit

<Chuck> Poornima: I need to review the link and read the disclaimer.

<scribe> scribe: Poornima

Alastairc: the consistent help is asking for help mechanisms to be in the same order, in some pages in disclosure widgets, in some pages it's not. is that a pass, the question was 'whether it technically pass'?
... yes it will technically pass

<Chuck> proposed RESOLUTION: Accept amended PR 2612 to address issue 2303.

<GreggVan> +1

<Chuck> +1

<Chuck> Poornima: I'm good.

<ShawnT> +1

<alastairc> +1

<iankersey> +1

<jaunita_george> +1

<Rachael> +1

<Ryladog_> +1

<JakeAbma> +1

<Detlev> +1

<Francis_Storr> +1

<jon_avila> +1

<laura> +1

<mbgower_> +1

RESOLUTION: Accept amended PR 2612 to address issue 2303.

<kirkwood> +1

<Zakim> bruce_bailey, you wanted to ask if this is example or just reply to issue

<Detlev> Sorry, have to quit meeting now...

Bruce: the PR looks fine, i think it was just responding to the issue, or changing to the understanding?

Question 4 - Change definition and add parts to NOTE for "target offset" #2427

Alastairc: it's the change in the understanding as well

https://github.com/w3c/wcag/pull/2778

Chuck: 8 ppl agreed with change, no objections in the comments

Gregg: nothing to add other than mentioned in my comment

Bruce: I think we should do the quick edit, for now we can ignore my comment

<mbgower_> I agree with Bruce. do this change, but we need a bigger one

<Zakim> alastairc, you wanted to respond to the comments

<Wilco> Here's a VERY long thread about target offset https://github.com/w3c/wcag/issues/2695 which may help explain, or maybe confuse you further.

Chuck: Just to be clear, you are not strongly objecting to the amendment?

<Ryladog_> Target offset needs work

<Chuck> proposed RESOLUTION: Accept PR 2778 to address issue 2427.

<mbgower_> +1

<GreggVan> +0

<alastairc> Gregg - if you join Friday's WCAG 2.x meeting we can go over that definition then

<Ryladog_> +1

<ShawnT> +1

<Wilco> +1

<bruce_bailey> +1

<laura> +1

<iankersey> +1

<alastairc> +1 (and we will return

<GN015> +1

<maryjom> +1

<GreggVan> thanks

RESOLUTION: Accept PR 2778 to address issue 2427.

Question 5 - Proposal to 'link' to blocks of text Target Size SCs #2430

https://github.com/w3c/wcag/pull/2779

Chuck: 1 comment for agree with change, reading the comments

<Zakim> mbgower_, you wanted to say this doesn't really address https://github.com/w3c/wcag/issues/2767

Alastairc: because the nature of the comment, ppl will get stuck into the substance of inline targets which is coming next week

<mbgower_> +1 to skip

<Wilco> +1 skip, gd with me

Question 6 - Accessible Auth understanding update #2355

Chuck: Skip to Question 6, as the Question 5 will be discussed next week

https://github.com/w3c/wcag/pull/2391

Chuck: 6 ppl agreed, 2 ppl agreed with adjustments

<mbgower_> +1 to keeping 'common'. we had to take it out of normative, but it's important concept

<Zakim> alastairc, you wanted to respond to gregg

<kirkwood> +1 to keeping common

Gregg: the issue was all about 'common' word got deleted.. i was just raising the fact why it's removed, as any aspect to it can be added as applicable

Alastairc: it seems to be restricting normative, we got objections even from COGA taskforce, 'common' could refer to based on culture, experience..

<kirkwood> good point

<Zakim> bruce_bailey, you wanted to ask about "recognizing a picture the website provided"

Alastairc: as it is not specific and clearly stating the objective, it's best to remove the 'common' word

<kirkwood> user provided i thiought you were correct

Bruce: was the recommendation to recognize the pictures that was originally provided?

<Zakim> mbgower_, you wanted to say needs a semi-colon ahead of "however"

Alastairc: the recommendation is to recognize the picture or objects provided

<Chuck> proposed RESOLUTION: Accept amended PR 2391 to address issue 2355.

<GreggVan> +1

<Chuck> +1

<AWK> +1

<bruce_bailey> +1

<ShawnT> +1

<mbgower_> +1

<laura> +1

<iankersey> +1

<jaunita_george> +1

<maryjom> +1

<Ryladog_> +1

<Makoto> +1

RESOLUTION: Accept amended PR 2391 to address issue 2355.

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

https://github.com/w3c/wcag/issues/2551 to Question 7

Chuck: Wilco had suggestions about cookie popups, reading his comment
... 7 ppl agreed, 2 ppl agreed with adjustment

Gregg: I think Wilco says the same thing in his comment, nothing more to add to my comment

<alastairc> any suggestions?

mbgower: I agree with Wilco's note, the focus is not obscured for the cookie popups, examples has to be clear

jon_avila: not clear of what we are talking about, from my experience most of the sites are readable .. for some ppl, the cookie notes present the problem, again it's for some folks not for others

<bruce_bailey> +1 for 2.2 to be clear if cookie notices (as typically implemented) typically fail this SC

Gregg: unless you change the SC to normative, you can't put a note to something. If we do put an exception to SC, keyboard operation also to keep in mind

<mbgower_> If there is a banner implemented as sticky content , focus cannot be obscured by the cookie banner. Options include making the banner modal so the user has to dismiss the banner before navigating through the page, or to use <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding">scroll padding</a> so there is no overlap.

<jon_avila> a Keyboard user shouldn't have to accept cookies if a pointer user does not have to in order to use the site.

Gregg: because it takes lot of keyboard tabs to get to the bottom of the page to dismiss the page

<Zakim> alastairc, you wanted to say that it was allowing for dismissing the banner (content)

Alastairc: cover the focused element when thinking around complex interfaces, in the cookie banner example, it seems that it immediately focus on the cookie banner

<bruce_bailey> +1 to Jon Avila comment that keyboard users should not have to accept cookies if a pointer user can use site without accepting cookies

<jon_avila> Most cookies banners only permit you to accept it.

Alastairc: then dismiss the banner, but if you don't dismiss the banner at the time it's focused, then it's a failure to the SC

<Zakim> Chuck, you wanted to ask if this would also impact focus not obscured (enhanced)?

<Francis_Storr> does this codepen, which has a cookie banner, the code of which is at the top of the DOM, immediately focuses on the banner, and allows scrolling to the footer do what people want? https://cdpn.io/pen/debug/ExRZBdo

mbgower: agree that it reduces the impact as the focus get there right away, say someone has a right navigation switch area and has 15 things, it doesn't collapse or lost of focus

<Zakim> Chuck, you wanted to ask if I heard right, the pr has been amended?

<Zakim> GreggVan, you wanted to say -- we COULD add a note to understanding if it said OK if focus moves to simple response popup because it would not cover the focus and the person

mbgower: same thing is I agree that the focus is there first to dismiss it, not much impact.. not the context of obscured focus

<mbgower_> define "easy to dismiss" :)

<alastairc> Poll question: Should an easily dismissable banner pass the SC? (That does/can cover focused elements if it is not dismissed.)

Gregg: may be another good pass tabbing off of it would close or dismiss the modal..

<Ryladog_> +1 to Jon

<bruce_bailey> +1 to mgower proposed edit at 29 past hour

<mbgower_> we can add "dismiss on loss of focus" to the examples

Jon_avila: in my experience, most of the cookie is to accept or decline.. you zoom the browser, you are making it to first accept or decline, but not other users, there are options to read through other content before reading cookie banner

<alastairc> That would be an illigal cookie banner. For places which request a cookie banner, you have to be able to not accept cookies

<GreggVan> +1 to "dismissed without having to agree"

<laura> +1 to jon

<mbgower_> If there is a banner implemented as sticky content , focus cannot be obscured by the cookie banner. Options include making the banner modal so the user has to dismiss the banner before navigating through the page, dismissing on loss of focus, or to use <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding">scroll padding</a> so there is no overlap.

Jon_avila: the question is whether the cookie banner can be moved or dismissed without responding..

<Zakim> Chuck, you wanted to propose the poll

Wilco: don't know these are writing exceptions to the SC. are there any exceptions to this at all?

<bruce_bailey> +1 that "dismissed" is not the same as "agree" so i hope SC does not have to change for cookie banner

<Chuck> Poll question: Should an easily dismissable banner pass the SC? (That does/can cover focused elements if it is not dismissed.)

<Chuck> +.5

<mbgower_> -1

<Rachael> -1

<ShawnT> -1

<Francis_Storr> -1

<GreggVan> +1 if you add "without agreeing to something

<Wilco> +1, and agree with Bruce's point on dismiss !== agree

<jon_avila> +0 would only support if dismissing doesn't mean user gives consent for something.

<Ryladog_> -1

<laura> -1

<bruce_bailey> +1 but need to add caveat that "easily dismissible" is close -- but not accept

<jaunita_george> -1

<GN015> -1

0.. because the easily dismissable without actually answering to it like accept/decline or having X icon to dismiss

<mbgower_> define "easily dismissed"

<Chuck> If there is a banner implemented as sticky content , focus cannot be obscured by the cookie banner. Options include making the banner modal so the user has to dismiss the banner before navigating through the page, dismissing on loss of focus, or to use <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding">scroll padding</a> so there is no overlap.

Alastairc: based on the response, I suggest accepting Mike's update suggestion..

Chuck: reading out the latest amendment

<Zakim> GreggVan, you wanted to say keyboard operable -- requires that full function be possible from the keyboard so that covers and to

<Zakim> GreggVan, you wanted to say "that does not include "dismiss the

Gregg: all looks good with the rephrase 'easily dismissable with no option on the agreeing'...

<Zakim> mbgower_, you wanted to say that is orthogonal

Alastairc: it's not only the cookie banner, but any banner like sticky components

<alastairc> Wouldn't that fail 2.1.1

Wilco: You can trap the focus inside the cookie banner, we might make it worse by adding the 'without accepting the cookie but dismissing'

<mbgower_> Those are 3 common techniques for these

<jon_avila> I agree with Wilco

Gregg: question is whether 2.1.1. fail?

<jon_avila> Closing on focus could be an issue for SC 3.2.1

<Zakim> bruce_bailey, you wanted to ask if Understanding is clear that dismiss == close and making a choice which is submit is *not* dismiss ?

bruce_bailey: do we have definition of dismiss? close choice is dismiss, accept is a submit choice so not the same

<mbgower_> but it's going to fail this

<alastairc> NB: A 'good' cookie popup would include Accept, Manage, and dismiss (accept). Manage would open something to accept/decline in more detail.

Gregg: they can scroll from underneath, but the keyboard operation get stuck on the banner, this might impact the mouse operation as well

<mbgower_> We're now discussion a hyptothetical implemetnation of a cookie banner

<Chuck> POLL: Support the amended language?

<alastairc> we should remove "cookie" from the second mention of banner.

<mbgower_> should porobably be "or using..."

<jon_avila> Banner could imply at top of page.

<mbgower_> If there is a banner implemented as sticky content , focus cannot be obscured by the banner. Options include making the banner modal so the user has to dismiss the banner before navigating through the page, dismissing on loss of focus, or using <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding">scroll padding</a> so there is no overlap.

<GN015> does cannot mean may not or is not possible to ?

<Chuck> POLL: Support the amended language?

<mbgower_> +1

<bruce_bailey> +1 is okay

<ShawnT> +1

<Rachael> +.5

<Wilco> 0

<alastairc> jon_avila - we have other examples, this is just on that example

<alastairc> +1

<mbgower_> more techniques would help

<GreggVan> +1 since this is understanding -- change it slightly to say "Options to meet this SC with sticky content include....

<jon_avila> +0

<Makoto> +1

<jaunita_george> +1

<kirkwood> +1

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

Chuck: no objections, this is not the proposed resolution..

<mbgower_> it's an example in the Understanding

<Wilco> I'm concerned people are going to trap keyboard focus on the cookie banner, while leaving the rest of the page interactive for mouse users. I bet that's going to happen.

Jon_avila: little bit unsure of focus moving to there.. little hesitatant as this may not be optimal way

<jon_avila> Those are fine - it's the dismiss on focus removing

Gregg: the two options is clever 1. everybody get to the banner dismiss it 2. add padding, put it below all of the content, so the whole page can be read, there are no content underneath the banner

<mbgower_> We can take out the dismiss on loss of focus. Someone said it, and it is a common technique

Jon_avila: if it dismisses on tabbing away, user may lose the chance of reading it

<mbgower_> "Sale on Monday!"

<Chuck> If there is a banner implemented as sticky content, focus cannot be obscured by the banner. Alternatives include making the banner modal so the user has to dismiss the banner before navigating through the page, dismissing on loss of focus, or using <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding"> scroll padding</a> so there is no overlap.

Alastairc: we don't want to get stuck only on cookie banner, consider menu that opens up, potentially obscuring other content..

<GreggVan> +1 nice

mbgower: on Bruce suggestion, that's fine, there is really a place of techniques with better examples

Wilco: I like to see cookie banner explicitly mentioned as it's seen very common

<alastairc> "If there is a banner implemented as sticky content, such as a cookie banner, focus cannot be obscured by the banner."

<alastairc> Updated: https://github.com/w3c/wcag/pull/2611/files#diff-a1e686474a9da05fc533ce56cd7a154aa4c12cbbf42591ac35b181ea0ea57f84

<mbgower_> if you want to make it 'cookie banners' i'm fine removing dismiss on loss of focus.

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

Chuck: Will the latest proposed amendment ok with the examples to add cookie banner?

<Zakim> bruce_bailey, you wanted to ask if "interactive banner" is different than banner ?

Wilco: fine with that

<alastairc> Wilco wanted a cookie banner example

<Francis_Storr> https://cdpn.io/pen/debug/ExRZBdo

mbgower: there are different examples we can make if we want, specifically cookie.. agree with Wilco in adding cookie calling out as an example

<Francis_Storr> https://github.com/w3c/wcag/pull/2746

<bruce_bailey> thanks @mgower -- i think dialog boxes should not be conflated with notice-only banners

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

Francis_Storr: cookie is potentially one example

Gandula: not clear of the context, cannot means it's not possible to, then what could be the alternative?

<mbgower_> it's an understanding doc. I think "cannot" is better

<bruce_bailey> +1 that cookie banner example as non-modal sticky dialog box is a good idea

Chuck: only 2 mins left, not sure if we can come with the resolution today

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

<mbgower_> I can take on making another example to address a notification (as opposed to dialog)

<ShawnT> +1

<Chuck> +1

<Rachael> +1 and revisit examples later

<mbgower_> +1

<bruce_bailey> +1

<alastairc> +1, we can revit later

<maryjom> +1

<jon_avila> +.5

<GN015> -1 I think the language might be misunderstood

<kirkwood> +1

+1, revisit to add more specific examples like cookie, dialog, alerts

<mbgower_> I don't know how to resovle the "may not". That is creating another point of confusion

- DRAFT -

AGWG Teleconference

15 Nov 2022

Attendees

Contents

Silver sub-group report back

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

Question 1 - Proposal to Rephrase Success Criterion 4.1.1 #2525

Question 2 - Dragging movement definition might be improved #2669

Question 3 - Does 3.2.6 Consistent Help allow for content that is under disclosure widget on one page in a set but not another? #2303

Question 4 - Change definition and add parts to NOTE for "target offset" #2427

Question 5 - Proposal to 'link' to blocks of text Target Size SCs #2430

Question 6 - Accessible Auth understanding update #2355

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

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output