<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
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
Chuck: Now going through the WCAG 2.2 misc issues survey
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
+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
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
+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
<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
+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?
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
+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.
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
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
+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.
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 ?
<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.
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> 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.
<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
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?
<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.
<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
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/ooking for/looking for/ Succeeded: s/Charles McCathie-Nevile/Charles McCathieNevile/ Succeeded: s/No going/Now going/ Succeeded: s/implementors must use it authors should not use it though/ deprecation typically is implementors must use it authors should not use it though, and errata is fixing an error in the spec/ Succeeded: s/maping/mapping/ Succeeded: s/expaination/explanation/ Succeeded: s/the consistent help is in the same order, in some pages in disclosure widgets, in some pages it's in other pass/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/ Succeeded: s/of Secondary target/of inline targets/ Succeeded: s/I accept Mike's/I suggest accepting Mike's/ Succeeded: s/definition of dismiss? closing and it may or may not show again/do we have definition of dismiss? close choice is dismiss, accept is a submit choice so not the same/ Default Present: shadi, ChrisLoiselle, jaunita_george, Laura_Carlson, tzviya, alastairc, Rachael, wendyreid, Francis_Storr, Jennie, Makoto, bruce_bailey, ShawnT, AWK, Chuck, Wilco, iankersey, sarahhorton, kirkwood, JakeAbma, Katie_Haritos-Shea, JustineP, -.5, Detlev_, SuzanneTaylor, .5, GreggVan, GN, Poornima, mbgower_ Present: shadi, ChrisLoiselle, jaunita_george, Laura_Carlson, tzviya, alastairc, Rachael, wendyreid, Francis_Storr, Jennie, Makoto, bruce_bailey, ShawnT, AWK, Chuck, Wilco, iankersey, sarahhorton, kirkwood, JakeAbma, Katie_Haritos-Shea, JustineP, -.5, Detlev_, SuzanneTaylor, .5, GreggVan, GN, Poornima, mbgower_, GN015 Found Scribe: Detlev Inferring ScribeNick: Detlev Found Scribe: Poornima Found Scribe: Poornima Inferring ScribeNick: Poornima Found Scribe: Poornima Inferring ScribeNick: Poornima Scribes: Detlev, Poornima ScribeNicks: Detlev, Poornima 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.)[End of scribe.perl diagnostic output]