15:42:11 <RRSAgent> RRSAgent has joined #ag
15:42:11 <RRSAgent> logging to https://www.w3.org/2021/12/21-ag-irc
15:42:19 <Chuck> rrsagent, make logs world
15:42:28 <Chuck> rrsagent, generate minutes
15:42:28 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/21-ag-minutes.html Chuck
15:42:34 <Chuck> chair:  Chuck
15:42:41 <Chuck> Zakim, start meeting
15:42:41 <Zakim> RRSAgent, make logs Public
15:42:42 <Zakim> Meeting: AGWG Teleconference
15:42:49 <Chuck> meeting:  AGWG-2021-12-21
15:43:06 <Chuck> agenda+ WCAG 2.2 Page break navigation (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/
15:43:24 <Chuck> agenda+ WCAG 2.2 Focus appearance (New Q1, then Q2-4 you may have filled in already https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/
15:43:33 <Chuck> agenda+  WCAG 2.2 Misc https://www.w3.org/2002/09/wbs/35422/wcag22-misc/
15:43:41 <Chuck> present+
15:44:11 <GreggVan> GreggVan has joined #ag
15:57:46 <Rachael> present+
15:58:17 <ShawnT> ShawnT has joined #ag
15:58:37 <bruce_bailey> bruce_bailey has joined #ag
16:00:33 <kirkwood> present+
16:01:13 <Jen_G> Jen_G has joined #ag
16:01:19 <Jen_G> Present+
16:03:13 <bruce_bailey> present+
16:03:20 <Rachael> scribe: Rachael
16:03:58 <ShawnT> present+
16:04:00 <Rachael> Chuck: Does anyone want to introduce themselves or have new topics?
16:04:12 <shadi> shadi has joined #ag
16:04:16 <Chuck> zakim, take up item 1
16:04:16 <Zakim> agendum 1 -- WCAG 2.2 Page break navigation (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/ -- taken up [from Chuck]
16:04:37 <MelanieP> MelanieP has joined #ag
16:04:39 <Raf> Raf has joined #ag
16:04:41 <MelanieP> present+
16:04:42 <GN015> GN015 has joined #ag
16:04:46 <shadi> present+
16:04:55 <Rachael> Chuck: Our first question today is  Revision to the definition of Page break locators #2155. [reads issue and results]
16:05:10 <GN015> present+
16:05:24 <Rachael> ...reads agreements. Bruce reads with adjustment. Did you want to speak to that?
16:05:41 <Rachael> Bruce: I like that we are referencing a print page. Do we define page break elsewhere?
16:05:46 <Chuck> q?
16:06:00 <Chuck> regrets: Rain Michaels, Laura Carlson, Jake Abma, Leonie Watson, Alistair Garrison, Todd Libby
16:06:03 <Rachael> results - 5 agree with update, 1 agree with adjustments, 1 something else.
16:06:22 <Rachael> Bruce - Page break isn't meaningful in a web page.
16:06:29 <Rachael> alastairc:  Not with our definition of webpage.
16:06:54 <Rachael> bruce_bailey: then I think we need to be a bit more descriptive.  Its a page break location relative to something formatted for printing or hard copy.
16:06:57 <alastairc> q+
16:07:07 <Chuck> ack ala
16:07:09 <Rachael> Chuck: You said you had some thoughts but may still need refining.
16:07:58 <bruce_bailey> right, mostly digital documents (!) that reference a dead-tree version
16:08:06 <Chuck> q+
16:08:07 <GreggVan> q+  to say can be edocs  that have pages too.    So  printing isnt quite right.     Maybe
16:08:07 <Rachael> alastairc: In answer to your question in the survey around are we talking about paper or not. Its not necessarily paper. It can be textbooks or PDFs. Its not printed out but has inherited the concept.  That's why it says not a printed document but serves the same purpose.
16:08:14 <Chuck> ack Gregg
16:08:14 <Zakim> GreggVan, you wanted to say can be edocs  that have pages too.    So  printing isnt quite right.     Maybe
16:08:59 <Rachael> GreggVan: Its something to say "Virtual pages in electronic documents, books etc" That is a lot of words. It seems like that could go in the understanding documents. Perhaps Virtual Page breaks.
16:09:34 <jon_avila> jon_avila has joined #ag
16:09:36 <Rachael> ...they are visually page breaks and referred to as page breaks. Or is it just ok to say equivilent of print page breaks which is pretty clear and then handle in understanding.
16:10:01 <Rachael> Chuck: Reads Wilco's comments
16:10:17 <alastairc> Topics: Does it cover page-break-after? Is it over-prescriptive.
16:10:43 <GreggVan> q+
16:10:50 <alastairc> q+
16:11:06 <kirkwood> +1 to Wilco’s comments
16:11:34 <Chuck> ack Ch
16:11:36 <Chuck> ack Gregg
16:11:38 <Rachael> ...Wilco's comments open up a new line of thought. Bruce, is the current definition such that you strongly oppose it and want more work on it or do you have a hard no.
16:11:52 <bruce_bailey> q+ to say i favor having this sc in 2.2
16:12:33 <Chuck> ack ala
16:12:33 <Rachael> Gregg: I am still trying to digest Wilco's comment. It doesn't matter where the headers are. The page breaks help location not navigation
16:13:16 <MelanieP> q+
16:13:33 <Rachael> alastairc: I think there are several things there. Page break after - That is the opposite direction than what we are trying to cover. If you set a page break after in a webpage it dictates how the webpage is printed. That is the opposite of what we are trying to do which is to line the webpage up with the print version.
16:14:20 <Chuck> q+ to poll on dropping this SC
16:15:04 <bruce_bailey> current line under discussion:
16:15:16 <bruce_bailey> <p><a>programmatically determinable</a> destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document.
16:15:31 <Regina> Regina has joined #ag
16:15:31 <Chuck> ack bru
16:15:31 <Zakim> bruce_bailey, you wanted to say i favor having this sc in 2.2
16:15:32 <Rachael> ...with regards to the classroom usage and whether it is overly prescriptive, I don't think it is because it is very narrow. I agree with Gregg that it assumes headings, etc. This was brought to us by edoc publishing group as a known gap because its not about e-readers. It applies to e style books rendered in a browser. Its clear in the understanding document. It applies to e-pub books when rendered in a browser. Its only when you are doing
16:15:32 <Rachael> this on a browser that this becomes an problem and its an author problem becuase there is no user agent mechanism. Browsers don't so it belongs here.
16:15:33 <Jemma> Jemma has joined #ag
16:15:36 <Ryladog> Ryladog has joined #ag
16:15:55 <Rachael> bruce_bailey: my concern is a general one. I think this is important for 2.2 for the reasons Alastair outlined.
16:15:56 <Chuck> ack Melanie
16:15:57 <Ryladog> Present+ Katie_Haritos-Shea
16:16:03 <GN015> FOn platforms where it is no problem it may as well be applicable. Gives the chance to report a success (fulfillment).
16:16:40 <Jemma> present+
16:16:43 <alastairc> q
16:16:45 <alastairc> q+
16:16:57 <alastairc> q+ to say no, they don't have an ID
16:17:08 <bruce_bailey> q+
16:17:11 <Rachael> MelanieP: I just wanted to mention Wilco is on holiday. I'm representing him a bit. I wanted to ask is there an answer to his question about would the normative cover the CSS property? The normative is written technology agnostic. The normative is what creates the requirements. It isn't clear to me that the normative plus the definition doesn't keep it out of scope. Potential for unintended consequences if the normative isn't clear.
16:17:15 <Chuck> ack ala
16:17:15 <Zakim> alastairc, you wanted to say no, they don't have an ID
16:17:24 <bruce_bailey> I don't agree this is epub only.
16:17:35 <Rachael> alastairc: This isnt' epub. We are not trying to apply it to that.
16:18:15 <MelanieP> q+
16:18:28 <Rachael> ...does it apply to the CSS attribute. I don't see how it could. There is no number so I don't see how it could be applied.
16:18:35 <Chuck> Poll:  1) I support dropping this SC.  2) I support keeping this sc (may need more work on definition)
16:18:36 <Chuck> ack bru
16:18:41 <Rachael> bruce_bailey: There are important problems with word online, pdfs, and other things. Not just epub.
16:18:45 <alastairc> Bruce - the user-agents cover PDF/ePub/Word
16:18:49 <Ryladog> +1 to Bruce
16:18:59 <Chuck> ack Melanie
16:19:05 <Rachael> ...My concern is that someone might say the document won't be printed so it isn't applicable.
16:19:34 <Chuck> q?
16:19:39 <Rachael> MelanieP: The definition proposed. [reads definition] Is that not what the CSS property does? It came from epub and serves epub. Isnt' that in the understanding?
16:20:51 <Rachael> alastairc: Yes [reads definition alternatives]. Maybe that is a bit easier. The CSS property doesn't set a location for the thing. It says this is where to break a page in the previous version. Maybe we need to pull the language "in relation to others in a set". Maybe we don't make the change if it causes confusion.
16:21:06 <Rachael> ...I think the part he wanted to get in was the "serves the same purpose" but maybe we need to keep the  same language.
16:21:06 <bruce_bailey> q+ to say "others is the set" is "other sets of WEB pages"
16:21:09 <Chuck> Poll:  1) I support dropping this SC.  2) I support keeping this sc (may need more work on definition)
16:21:31 <Chuck> ack br
16:21:31 <Zakim> bruce_bailey, you wanted to say "others is the set" is "other sets of WEB pages"
16:21:56 <Jemma> agenda?
16:22:08 <Rachael> bruce_bailey: The problem as I understood it with the original definition. The alllusion to other pages in a set was confusing with the language we use for webpages. The other set is problematic.
16:22:23 <Ryladog> Collection of pages?
16:22:33 <Rachael> Poll:  1) I support dropping this SC.  2) I support keeping this sc (may need more work on definition)
16:22:34 <Ryladog> 2
16:22:36 <ShawnT> 2
16:22:37 <jon_avila> 2
16:22:40 <GN015> 2
16:22:41 <Chuck> 2
16:22:41 <bruce_bailey> 2
16:22:41 <Rachael> 2
16:22:46 <Regina> 2
16:22:46 <alastairc> 2
16:22:53 <MelanieP> 1 representing Wilco
16:23:02 <kirkwood> 1
16:23:12 <Raf> +2
16:23:17 <MelanieP> q+
16:23:27 <Chuck> ack Ch
16:23:27 <Zakim> Chuck, you wanted to poll on dropping this SC
16:23:29 <alastairc> Ryladog - Doesn't work with our definition of pages, where a 'book' in a browser will generally be represented as one 'page'
16:23:32 <Chuck> ack Melan
16:23:56 <Rachael> Chuck: We have a couple of individuals who support dropping it but most are in favor of continuing to work it.
16:24:02 <alastairc> q+
16:24:05 <Chuck> ack ala
16:24:09 <Rachael> Melanie: consider moving it to AAA or mark it as at risk to protect the CR.
16:24:30 <shadi> q+
16:25:15 <MelanieP> q+
16:25:18 <Chuck> ack shad
16:25:20 <Rachael> alastairc: I would need to check with Michael. I think things are at risk before CR but the idea is not to have risk going into CR. Shadi? Chair hat on: Having talked to experts in this area on this topic and they are in favor of the fact this is needed, our primary concern should be around fit. Not gathering in scenarious that are not intended. If its not doing that, I would trust their judgement as to its validity.
16:26:04 <MelanieP> https://www.w3.org/2021/Process-20211102/#transition-cr
16:26:24 <shadi> https://www.w3.org/TR/2018/CR-WCAG21-20180130/#features-at-risk-in-the-wcag-2-1-candidate-recommendation
16:26:54 <jeanne> jeanne has joined #ag
16:27:03 <Chuck> q?
16:27:06 <Rachael> Shadi: Clarifying, I am no longer W3C staff. Michael would be the normative reference but unless the process document has changed, ideally we would not have at risk parts going into CR. It is possible that features are marked as at risk, it doesn't jeopardize it. Example of 2.1 with at risk examples.  These were looked at during the CR phase. I think what Melanie is saying is correct but please double check with Michael.
16:27:09 <Chuck> ack Melan
16:27:16 <Rachael> MelanieP: I added a link to the process document about that topic.
16:27:39 <Chuck> q?
16:28:16 <kirkwood> q+
16:28:21 <Chuck> ack Kirk
16:28:22 <Rachael> Chuck: The sentiment of the group but John Kirkwood, not putting you on the spot bu if you want to speak, please do.
16:29:11 <Chuck> q?
16:29:19 <Rachael> kirkwood: I am very much in alignment with Wilco on this. I have a difficult time seeing how this could move forward.  I would love to do this properly but the amount of work to do this is huge. There is a lot to take on with this.
16:30:18 <Rachael> Chuck: For those who voted for dropping it, will keeping it likely lead to a formal objection? I would like to understand whether we should focus on.
16:30:19 <alastairc> q+
16:30:31 <Chuck> ack ala
16:30:33 <Rachael> kirkwood: I do think it could be reworked but I wish you the best of luck.
16:30:47 <MelanieP> q+
16:31:43 <Chuck> ack melanie
16:31:48 <Rachael> alastairc: In John's comments, my perception is that its very narrow. I'm curious as to why it presents such a difficulty.  Its a niche but important scenario. I'm wondering what the concern is.
16:32:05 <Rachael> MelanieP: Answering Chuck's question. I think a formal objection is a distinct possibility.
16:32:07 <Chuck> q+
16:32:10 <Chuck> ack Chuc
16:32:51 <Chuck> q?
16:32:55 <bruce_bailey> q+
16:32:56 <Rachael> Chuck: Then we should continue conversation on keeping or not. Regarding web pages, the one use case is in regards to documentation that is presented in html format where users have the option to either print them or use the documentation online. I think that's kind of a niche where this may be applicable.
16:32:59 <Chuck> ack Bru
16:33:52 <MelanieP> q+
16:33:56 <jon_avila> +1 to Bruce - strongly favor keeping it.
16:33:57 <Chuck> ack Melan
16:33:58 <Rachael> bruce_bailey: I think its also applicable to situations where you have pdfs where the author hasn't kept the visual print page in synch with the programatic print page. Even if people don't htink they could fail a perfectly formatted PDF, then I think this is a much needed feature.
16:34:23 <alastairc> q+
16:34:29 <Rachael> MelanieP: I just wanted to reiterate the concept of marking it at risk so we can continue the conversation. Wilco is not here.
16:35:00 <Chuck> ack ala
16:35:10 <Chuck> q+ to propose a path forward
16:35:15 <Rachael> alastairc: I am not sure there is a need to mark this at risk because Wilco's comment just misunderstands the criteria. If we don't have a technical reason for marking it at risk, I don't think that's a valid route to go down.
16:35:21 <Rachael> ...as you note, he's not here.
16:35:48 <MelanieP> q+
16:35:57 <Chuck> ack Ch
16:35:57 <Zakim> Chuck, you wanted to propose a path forward
16:36:05 <Chuck> ack Melanie
16:36:11 <Rachael> Chuck: What if we leave the possibility of marking it at risk and we engage Wilco. We don't make a decision today. Or we can vote on definition and then circle back with wilco.
16:36:13 <alastairc> PRoposed: "<a>programmatically determinable</a> destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document."
16:36:17 <Rachael> Chuck: Current definition which hasn't changed.
16:36:39 <Rachael> MelanieP: A question on timing then. The holidays are here. Are you still trying to get to CR before the holidays?
16:37:02 <Rachael> alastairc: We also still have visible controls to get to in January so it will continue.
16:37:15 <Rachael> Chuck: That conversation will continue on. I would like to focus on proposed definition.
16:37:16 <kirkwood> - I am not willing to block, go with current consensus given Alastairs characterization
16:37:34 <bruce_bailey> PR link:  https://github.com/w3c/wcag/pull/2160
16:37:42 <Detlev> Detlev has joined #ag
16:37:47 <kirkwood> +1
16:37:50 <Chuck> proposed RESOLUTION:  Accept PR 2160 to address issue 2155, there will still be conversations regarding keeping or dropping this sc.
16:37:59 <kirkwood> +1
16:38:04 <Ryladog> +1
16:38:08 <ShawnT> +1
16:38:08 <Jemma> +1
16:38:09 <bruce_bailey> +1
16:38:10 <Chuck> +1
16:38:12 <alastairc> +1
16:38:13 <GN015> +1
16:38:13 <Rachael> +1
16:38:15 <jon_avila> +1
16:38:18 <MelanieP> 0
16:38:25 <Rachael> RESOLUTION:  Accept PR 2160 to address issue 2155, there will still be conversations regarding keeping or dropping this sc.
16:38:34 <bruce_bailey> scribe: bruce
16:38:38 <Chuck> zakim, take up item 2
16:38:38 <Zakim> agendum 2 -- WCAG 2.2 Focus appearance (New Q1, then Q2-4 you may have filled in already https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/ -- taken up [from
16:38:41 <Zakim> ... Chuck]
16:38:43 <Raf> +1
16:38:55 <Chuck> TOPIC:  Question 1 - Focus appearance and user-agents
16:38:57 <bruce_bailey> Chuck:  number of question, adjusting topics
16:39:03 <Chuck> Chuck has changed the topic to: Question 1 - Focus appearance and user-agents
16:39:35 <bruce_bailey> from survey:  Following the discussion on focus-appearance complexity, a question was raised about whether the user-agents are fulfilling the user-need.
16:39:44 <bruce_bailey> Chrome and Edge (about 75% of desktop browser share) now include an option to add a forced focus indicator.
16:39:51 <bruce_bailey> There were also points made about the difficulty of implementing the SC, although this was contested both on the actual difficulty, and that we have got to this point by trying to balance the user need with the flexibility and complexity.
16:39:57 <bruce_bailey> Please consider how/whether an SC should account for browser variations. For example, is a (fairly hidden) setting in a browser fulfilling the user need? Would author effort on this SC take away from other requirements?
16:40:04 <bruce_bailey> One possible way forward is to add 'mechanism is available' language to explicitly allow for browser-based solutions. For example, "A mechanism is available so that when user interface components receive keyboard focus, an area of the focus indicator meets the following:"
16:40:13 <bruce_bailey> Do you think we should:
16:40:20 <bruce_bailey> Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
16:40:26 <bruce_bailey> Add 'mechanism is available' language.
16:40:31 <bruce_bailey> Drop both focus-appearance SC (i.e. you consider that the browser features fulfils the need).
16:40:38 <bruce_bailey> Drop the AA SC but keep the AAA SC.
16:41:03 <bruce_bailey> Chuck sumarizes voting:  6 for add mechanism
16:41:09 <bruce_bailey> 2 for carry on
16:41:20 <bruce_bailey> melonie voted to drop
16:41:28 <bruce_bailey> also long respons from wilco
16:41:51 <bruce_bailey> Melonie (from survey):  Or allow an exception for relying on browser default as in 1.4.11.
16:41:56 <Chuck> q?
16:42:00 <bruce_bailey> Also... I object to the characterization of a setting in a browser's Accessibility settings as (fairly hidden). If you are willing to assign the large effort of meeting (and testing) this SC to every site owner in the world, surely assigning a little effort on the part of users to understand the accessibility features of their user agent is... reasonable?
16:42:37 <bruce_bailey> Chuck:  i am not sure how wilco voted
16:43:05 <bruce_bailey> Alastair:  Wilco did not vote because answer depends on how we address next question, mostly due to testability
16:43:24 <bruce_bailey> Chuck:  okay, wilco tentatively supports keeping it
16:43:35 <bruce_bailey> ... should we skip to next
16:43:45 <Jemma> 2. Using target-area as the basis for size metrics
16:44:04 <Jemma> Wilco would like to use the target-size of the component as the basis for size metrics.
16:44:16 <bruce_bailey> Alastair, most people consenssed on next question, but I prefer to skip dependance
16:44:35 <bruce_bailey> chuck:  reading from AWK answers
16:45:15 <bruce_bailey> ... most responses favor keep but add "mechanism" language
16:45:54 <bruce_bailey> Alastair:  paraphrasing AWK, we have moved language back-and-forth a bit already
16:46:40 <bruce_bailey> Chuck:  reads from Jonathan Avila commen
16:47:11 <bruce_bailey> Jon concluded:  Thus, you can just say ZoomText will always meet this and the author doesn't need to do anything - the SC is totally not needed.
16:47:57 <bruce_bailey> Jemma also agrees that no change is needed to SC, that question can be addressed in Understanding
16:47:59 <Chuck> q?
16:48:04 <alastairc> q+ to talk to mechanism
16:48:23 <Chuck> ack ala
16:48:23 <Zakim> alastairc, you wanted to talk to mechanism
16:48:35 <bruce_bailey> Jemma:  drafting consider including "mechanism is available" but that weaken requirment
16:48:50 <GN015> q+
16:49:08 <bruce_bailey> Alastair:  Mechanism is available is interesting because it does not actually change the SC requirement.
16:49:15 <MelanieP> q+
16:49:41 <bruce_bailey> ... i suggested this term because it makes it clearer that authors MIGHT rely on UA
16:50:00 <Chuck> ack GN
16:50:11 <jon_avila> q?
16:50:11 <bruce_bailey> ... while surfacing the potential, does not change fundamentals of SC
16:50:15 <jon_avila> q+
16:50:26 <bruce_bailey> ... and we have UA which are poor on this detail
16:51:03 <Chuck> +1 GN
16:51:06 <Chuck> ack Melanie
16:51:11 <Jemma> -1 all the users do  not know how to use available mechanism
16:51:12 <bruce_bailey> Gundala:  We have similar barrier where authors left off the hook because of high contrast modes available in there operating sytesm
16:51:43 <alastairc> Bypass blocks has similar language, which includes landmarks & screenreader...
16:51:46 <bruce_bailey> ... but this is still a gap.   Allowing ZoomText as a "mechanism" is not consistant, because that is AT.
16:52:16 <bruce_bailey> Melanie:  Agree that considering ZoomText or other AT as solution is not sufficient
16:52:24 <Ryladog> q+
16:52:41 <GreggVan> q+
16:52:48 <alastairc> q+ to say it's similar to text-sizing and bypass blocks
16:52:51 <Rachael> q+
16:52:58 <bruce_bailey> ... a user needing high contrast setting on a phone to adapt poor author content contrast -- that is one thing -- not great, but okay
16:53:27 <bruce_bailey> ... but focus is a UA function -- that is very different case !
16:53:33 <Chuck> ack Jon
16:54:17 <bruce_bailey> Jon Avila:  language of mechanism is very different than User Agent default
16:54:29 <Jemma> +1 to Jon
16:54:41 <bruce_bailey> ... mechanism should NOT be understood to include add-in AT
16:55:09 <Jemma> +100 to jon
16:55:11 <Chuck> ack Ryladog
16:55:12 <bruce_bailey> ... agree that FireFox -- as an example which has been around and not addressed -- there is a gap
16:55:30 <Chuck> q+ to support "carry on the sc as it is..."
16:55:43 <bruce_bailey> ... mechanism is available -- has not been sufficient.  We need pressure on browser makers.
16:56:05 <Jemma> +1 for easy fix with one line of css
16:56:18 <bruce_bailey> Kaie Haritos:  Author can fix pretty easily via css.  It is necessary for us to maintain as requirement
16:56:18 <Chuck> ack Gregg
16:56:25 <bruce_bailey> ... It impacts end users.
16:56:56 <MelanieP> thanks Gregg
16:57:12 <bruce_bailey> GreggV:  Melanie has changed my mind.  Mechanism is available is not strong enough....
16:57:48 <bruce_bailey> ... old idea was that if enough browsers had feature, we could kind of wave off the requirement
16:57:53 <Chuck> Jemma, I think the conversation is slowly shifting.
16:58:22 <jon_avila> q+
16:58:25 <bruce_bailey> ... and per our definition, UA includes AT ... but over time that has not demonstrated to strong enough to solve some problems
16:58:49 <jon_avila> focus-visible allow the indicator to be shown only when the keyboard is used and not with the mouse.
16:59:26 <bruce_bailey> ... i have some concerns that this is putting onerous on designers that now have to pick defect from some browsers -- force all pages to have huge borders on fields?
17:00:00 <Chuck> ack ala
17:00:00 <Zakim> alastairc, you wanted to say it's similar to text-sizing and bypass blocks
17:00:17 <bruce_bailey> ... but it seems wrong to require authors to fix a feature that all browsers should feature and make easy to adjust
17:01:07 <bruce_bailey> Alastair:  When we started this, we assumed we would be able to hit a balance between user needs and browser defaults
17:01:30 <bruce_bailey> ... since then, some browser defaults have improved noteably, namely chrome and edge
17:01:57 <bruce_bailey> ... Safari not great and FireFox still insufficient
17:02:31 <bruce_bailey> ... i was thinking that "mechanism" implied author supplied settting for the page or site
17:02:54 <Jemma> may be difficult to test "automatically"
17:03:12 <bruce_bailey> ... can be difficult to test, if there are multiple hover styles, but not from my experience is not difficult to impliment
17:03:30 <Chuck> q?
17:03:34 <Chuck> ack Rach
17:03:38 <bruce_bailey> ... what changes my mind is that "mechanism is available" is misleading
17:03:43 <Jemma> +1 alastairc
17:03:49 <Chuck> +1 alastair
17:04:16 <alastairc> q+ to say that good browser defaults can pass the SC, they just don't 'yet.
17:04:23 <bruce_bailey> Rachael:  chair hate off, i think the ideal state is that browsers impliment easy to find options, and authors cant breakit
17:04:47 <alastairc> s/chair hate off/chair hat off
17:05:18 <bruce_bailey> ... breaking might be hard, but be optimistic that browsers with provide sufficient solutions.  Presure to developers good.
17:05:47 <Chuck> q?
17:05:50 <Chuck> ack Ch
17:05:50 <Zakim> Chuck, you wanted to support "carry on the sc as it is..."
17:05:52 <Chuck> ack Jon
17:06:01 <bruce_bailey> Chuck:  Hearing more support on this call for dropping "mechanism" but want to get through queue
17:06:35 <GreggVan> Thanks - forgot that they keyboard indicator is only visible when doing keyboard focus
17:06:44 <GreggVan> nav
17:06:56 <Chuck> Poll:  1) I support carrying on with SC as it is.  2) I support adding "mechanism is available".  3)  Drop both focus-appearance SC.  4) Drop the AA SC and keep AAA sc
17:07:01 <bruce_bailey> Jon Availa:  Example is heuristic browsers are using to hide focus indicators when one is only using mouse or keyboard (so focus indicator fades)
17:07:05 <Chuck> ack ala
17:07:05 <Zakim> alastairc, you wanted to say that good browser defaults can pass the SC, they just don't 'yet.
17:07:37 <bruce_bailey> ... i think there is reason to be optimistic that browsers will mute unnecessary visual distractions.
17:07:39 <GreggVan> can you post - for the record -   what "the SC as is"    is exactly
17:07:42 <AWK> AWK has joined #ag
17:07:48 <MelanieP> which option inncludes exception for default focus indicator?
17:07:51 <AWK> +AWK
17:08:04 <alastairc> MelanieP - if the default meets the SC
17:08:09 <Chuck> Poll:  1) I support carrying on with SC as it is.  2) I support adding "mechanism is available".  3)  Drop both focus-appearance SC.  4) Drop the AA SC and keep AAA sc
17:08:10 <GreggVan> present+
17:08:12 <bruce_bailey> Alastair:  Just want to note that browser behavior in flux.
17:08:45 <bruce_bailey> Chuck:  tally in survey seems out of sync in this call, so straw poll
17:08:52 <Jemma> 1Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
17:08:56 <alastairc> https://w3c.github.io/wcag/guidelines/22/#focus-appearance-minimum
17:09:14 <Chuck> 1
17:09:19 <AWK> 1
17:09:21 <Jemma> 1
17:09:22 <MelanieP> 4 unless default focus indicator is allowed in the AA version
17:09:33 <jon_avila> 1
17:09:33 <Rachael> 1
17:09:35 <alastairc> 1
17:09:35 <GN015> 2, can live with 1
17:09:35 <Ryladog> 1
17:09:35 <GreggVan> 1
17:09:38 <bruce_bailey> Jemma:  Carry on as-is implies authors can have confidence -- if they test browser behavior
17:09:40 <Detlev> 1
17:09:50 <ShawnT> 1
17:10:29 <bruce_bailey> Chuck calls on Melonie:  similar to how we approach 1.4.11 -- can we add this to AA version ?
17:10:34 <GreggVan> q+
17:10:39 <Chuck> ack Greg
17:10:41 <jon_avila> I think that would be like a 5th option
17:11:10 <bruce_bailey> GreggV:  We have been waiting for this like 20 years.
17:11:23 <Ryladog> +1 to Gregg!!
17:11:41 <alastairc> To be fair, some browsers have improved, but it's not consistent. Also, agree that if they do step up, this SC is passed.
17:11:48 <bruce_bailey> ... it only appears when keyboard nav.  If the browswers ALL start doing this, then this provision will be met with default
17:11:54 <Chuck> proposed RESOLUTION:  Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
17:12:20 <bruce_bailey> ... but after 20 years of trying to get browsers to fix, they have not, so we need to task the content authors.
17:12:26 <Ryladog> +1
17:12:27 <Chuck> +1
17:12:28 <Rachael> +1
17:12:30 <GreggVan> +1
17:12:31 <Jemma> +1
17:12:31 <alastairc> +1
17:12:33 <MelanieP> -1
17:12:33 <kirkwood> +1
17:12:33 <bruce_bailey> ... it is a barrier to end-users.
17:12:34 <ShawnT> +1
17:12:38 <AWK> +1
17:13:14 <Rachael> q+ to suggest we record the resolution with 1 objection
17:13:16 <alastairc> If anyone has a better way of saying it that what is in the understanding doc, please let me know... "The default focus indicators in some browsers can be difficult to see, such as a 1px dotted outline, or a blue indicator which happens to be on a blue background. It is generally best to either define a keyboard focus style which meets this criterion, or test the focus styles across the browsers that are relied upon for conformance."
17:13:17 <bruce_bailey> Chuck looking for feeling of formal objects.
17:13:26 <bruce_bailey> Deque demurs to the new year.
17:13:46 <shadi> q+
17:13:52 <Chuck> proposed RESOLUTION:  Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it, noting that there is one objection.
17:14:02 <bruce_bailey> Rachael:  recommend accepting resolution, notes that there is some concern
17:14:05 <Rachael> q-
17:14:17 <alastairc> q?
17:14:36 <bruce_bailey> Chuck asks Rachael to make resolution proposal.
17:14:56 <bruce_bailey> Shadi asks for summary for concern with "mechanism"
17:15:23 <bruce_bailey> GreggV:  problem is that UA includes AT -- and people should not need AT for this need
17:15:26 <Rachael> RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default indication. C
17:15:41 <Rachael> proposed RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default indication.
17:16:03 <Rachael> proposed RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default focus indicator
17:16:15 <Chuck> q?
17:16:25 <shadi> ack me
17:16:44 <bruce_bailey> Jemma asks about objection process.
17:16:46 <GN015> What does including the default focus indicator mean in this context?
17:17:04 <bruce_bailey> Alastair:  we can deal with objections on CFC process
17:17:13 <bruce_bailey> RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default focus indicator.
17:17:51 <bruce_bailey> Jemma:  We should not really be using word "objection" here -- and that is not what she asked
17:17:55 <Chuck> TOPIC:  Question 2 - Using target-area as the basis for size metrics
17:18:01 <Chuck> Chuck has changed the topic to: Question 2 - Using target-area as the basis for size metrics
17:18:12 <bruce_bailey> Melanie:  it is okay, because I asked to add an exception
17:18:51 <bruce_bailey> Chuck reads from survey:
17:18:52 <bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq29
17:18:59 <bruce_bailey> Wilco would like to use the target-size of the component as the basis for size metrics.
17:19:05 <bruce_bailey> PR 2147 makes the change in the SC text. If we agree this, the understanding document will need updating.
17:19:18 <bruce_bailey> https://github.com/w3c/wcag/pull/2147/files
17:19:48 <bruce_bailey> Should we:  Change to using target size as the basis for measuring components.  9 votes
17:20:04 <bruce_bailey> Detlev (from survey):  I don't see anything wrong with using target size as a basis for measurement if that can simplify an automatic approach to measurement (no one, I believe, is looking forward to start calculating the focus area of targets on a manual basis) but I may not be sufficiently aware of loopholes that might appear. So it might be worthwhile going through edge cases (Alastair will have some in stock, I guess) to see what this[CUT]
17:20:09 <Jemma> s/be using word "objectioin"/be using "requesting including a default focus indicator"/
17:20:33 <bruce_bailey> David McDonald (from survey):  I don't have a problem with the proposed text. It add a bit of complexity to an already complex SC, but I understand that it may make it possible to evaluation the SC with automation.
17:20:39 <bruce_bailey> A precedence for this might be the complicated calculation for colour contrast becomes a black box and authors just use colour contrast tools. (but that calculation is not part of the SC language.)
17:20:45 <bruce_bailey> What would be ideal would be to have some sort of a name for the calculation and then reference it in the SC text...
17:20:52 <bruce_bailey> I don't object to alternatively updating the note if it accomplishes the same thing of making the SC evaluated automatically.
17:21:13 <bruce_bailey> Glenda (from surve):  +1 to what David MacDonald said
17:21:33 <bruce_bailey> Wilco (from survey):  1. Target should be linked to the definition
17:21:39 <bruce_bailey> 2. Rather than remove that note, I think we should replace it with something like this:
17:21:45 <bruce_bailey> > Some components have an "extended" target, where both the component and a larger container are interactive. Even in such cases the minimum area is taken from the component's target area, not the container.
17:22:06 <bruce_bailey> Bruce (from survey):  > Some components have an "extended" target, where both the component and a larger container are interactive. Even in such cases the minimum area is taken from the component's target area, not the container.
17:22:12 <Chuck> q?
17:22:20 <bruce_bailey> s/My preference is for the PR, since having the text mention "area" is good. I am also okay with updating the note./My preference is for the PR, since having the text mention "area" is good. I am also okay with updating the note./
17:22:33 <bruce_bailey> My preference is for the PR, since having the text mention "area" is good. I am also okay with updating the note.
17:22:54 <bruce_bailey> GreggV (from survey):  Absolutely. in fact having a small visual target and a large active area is a good technique for more accurate pointing. (and Notes are not normative usually)
17:23:16 <bruce_bailey> Chuck:  That is all comments from survey supporting PR.
17:23:46 <bruce_bailey> ... two votes for Update the note
17:24:06 <bruce_bailey> Jon Availa (from survey):  The target area could make it harder to meet and more confusing on how to test. This could mean potentially larger indicators if there are larger target areas.
17:24:23 <alastairc> q+ to talk through the change
17:24:32 <bruce_bailey> Jon Avila:  Needs more consideration.
17:24:46 <bruce_bailey> ... could have situation where offset makes objects overlap
17:24:58 <bruce_bailey> [gives another example]
17:25:36 <alastairc> q+ to talk through the change, and target area isn't about white space
17:25:44 <bruce_bailey> Chuck:  We also had 3 something votes.
17:25:52 <AWK> q+ to ask about standard checkboxes that use label properly
17:26:07 <GreggVan> q+
17:26:13 <bruce_bailey> Gundula:  target area is not right thing to be measuring
17:26:22 <bruce_bailey> ... overlaps was another example
17:26:33 <Chuck> ack AWK
17:26:33 <Zakim> AWK, you wanted to ask about standard checkboxes that use label properly
17:26:39 <bruce_bailey> Chuck calls to AWK for his clarification request.
17:26:51 <Ryladog> q+
17:27:25 <bruce_bailey> AWK:  There must be a variety of cases where the target area is extended , maybe without visual indicators, but this is not a problem for a keyboard area
17:28:11 <bruce_bailey> ... that is provided as an accomodation , maybe for someone uses a mouse but with difficultly , i dont think we have all the cases sorted
17:28:11 <Chuck> ack ala
17:28:11 <Zakim> alastairc, you wanted to talk through the change and to talk through the change, and target area isn't about white space
17:29:07 <bruce_bailey> ... another example is default with check boxes -- which are small -- but group border can be used to mee this SC -- and default controls are not typically problematic
17:29:50 <bruce_bailey> Alastair:  Explains some of the oddities and difficulties trying to be addressed.  Wilco has a neon sign example.
17:30:31 <bruce_bailey> ... Jake previously gave example with 4 px requirement which is rediculous on control easy to activate.
17:31:02 <Chuck> ack Gregg
17:31:07 <bruce_bailey> ... we have example with cards and drop shadows that can be easy to activate inputs
17:31:43 <bruce_bailey> ... also example with input boxes which easy to select.
17:31:57 <alastairc> q+ to talk about target area and spacing
17:32:11 <alastairc> https://w3c.github.io/wcag/guidelines/22/#dfn-targets
17:32:33 <bruce_bailey> GreggV:  We have SC which implications for the needs of testing tools, so manual testing does not have to be very easy.
17:33:00 <bruce_bailey> .. if target is used incorrectly elsewhere, fix that use elsewhere.
17:33:34 <Chuck> ack Ryl
17:33:44 <bruce_bailey> ... to AWK point, if we need min height/width for string of radio buttons, then do that.  It is still all target area.
17:34:09 <jon_avila> q+
17:34:34 <bruce_bailey> Katie:  Real life use case:  touch screen like a phone pad, RNIV tells us we need "well" between targets...
17:35:13 <AWK> That sounds like a different SC. https://www.w3.org/TR/WCAG22/#target-size-minimum
17:35:37 <bruce_bailey> ... but if someone using keyboard, the spaces get read by screen reading software, so that is not good, numbers should 7, 8, 9, etc. should just be read in sequence.
17:36:05 <Chuck> ack ala
17:36:05 <Zakim> alastairc, you wanted to talk about target area and spacing
17:36:39 <bruce_bailey> ... so there is tension between phone pad for use on touch screen and visul presentation giving space -- and buttons not have white space via keyboard.
17:37:11 <bruce_bailey> Alastair:  I don't agree we have incorrect definition else where.  Please submit issue if you disagree.
17:37:23 <Ryladog> q+
17:37:49 <bruce_bailey> ... This SC is addressing target point of view spacing , so using well for target space is fine.
17:38:44 <bruce_bailey> ... But a script might change the presentation, so the focus indicator might need to adjust.  Focus indicator might include spacing or might be for touch target, so those can be two different things.
17:38:56 <Chuck> q?
17:38:58 <Chuck> ack jon
17:39:05 <bruce_bailey> ... AWK gave example of check boxes, and this updates helps with that.
17:39:42 <bruce_bailey> Availa:  I understand the concern for conflating target size with target area.  I have been testing this...
17:39:50 <AWK> q+ to say that  this will cause more problems then it solves. We are mandating that checkboxes must have focus around the entire label and checkbox and I don't think that we can/should do that.
17:40:09 <bruce_bailey> ... My experiments, I can click target, via mouse, on whitespace outside button.
17:40:17 <alastairc> It would be the size of the label, which is wrapped around the input
17:40:20 <Chuck> ack Ry
17:40:42 <bruce_bailey> ... so the target size propert is not exposed.  The visual focus indicator, by contrast, is readily available for an audit.
17:40:58 <MelanieP> q+
17:41:00 <Chuck> ack AWK
17:41:00 <Zakim> AWK, you wanted to say that  this will cause more problems then it solves. We are mandating that checkboxes must have focus around the entire label and checkbox and I don't think
17:41:04 <Zakim> ... that we can/should do that.
17:41:28 <bruce_bailey> Katie:  It can seem like a concern that a visual focus indicator is larger than the target.  I don't agree it is a problem in practice.
17:42:02 <Chuck> q?
17:42:05 <Chuck> ack Mel
17:42:12 <bruce_bailey> AWK:  I have concern for the testabiltiy, and this conversation reinforces that.  I don't think we should make this change.  End with "component".
17:42:20 <alastairc> To quote Wilco: I think area of the component's target does exactly what we need here:
17:42:20 <alastairc> 1. It's technology agnostic
17:42:20 <alastairc> 2. for most technologies it can be programmatically determined
17:42:20 <alastairc> 3. it matches the border-box / browser indicated size in HTML and SVG (unless clipped, which is very rare)
17:42:20 <alastairc> 4. It doesn't require this problematic "visible area" thing as a fallback
17:42:59 <bruce_bailey> Meanie:  Wilco would address better, but a programatically determinable target area needed for testing this.
17:43:00 <AWK> q+
17:43:00 <Detlev> q+
17:43:08 <Chuck> ack AWK
17:43:21 <Jemma> definition: target offset
17:43:21 <Jemma> [New]
17:43:21 <Jemma> the distance measured from the farthest point of a target to the nearest point of the second target. Offset includes the target and spacing around the target. The target offset from A to B may be different then the offset from B to A, if the size of these targets differ.
17:43:22 <bruce_bailey> ... focus areas is just a browser feature.  It is no conflating.
17:43:29 <Chuck> ack Detlev
17:43:33 <Jemma> definition: target
17:43:33 <Jemma> region of the display that will accept a pointer action, such as the interactive area of a user interface component
17:43:38 <alastairc> q+
17:43:52 <bruce_bailey> AWK:  Disagree, as adding lable to checkboxes increases focus area.  It is a useful technique.
17:44:23 <bruce_bailey> Detlev:  If checkbox has accessible name, it is NOT necessary to use label.
17:44:24 <AWK> q+ to discuss nintended consequence
17:44:26 <GreggVan> q+
17:44:27 <Chuck> ack ala
17:45:24 <bruce_bailey> Alastair:  There probably are cases where area of input are different from focus or target area.  AWK example of label is one of them.
17:45:55 <bruce_bailey> ... to Jon Avila, area of label is readily available.  So that is one aspect.
17:46:11 <Chuck> q+ to propose a resolution
17:46:16 <bruce_bailey> ... We might consider exception for area being expanded via lable.
17:46:37 <bruce_bailey> ... see phrasing from my conversation with Wilco
17:46:54 <bruce_bailey> ... we need some fudge for either approach.
17:46:57 <Chuck> ack AWK
17:46:57 <Zakim> AWK, you wanted to discuss nintended consequence
17:47:09 <bruce_bailey> ... target size might be artificially expanded.
17:47:37 <bruce_bailey> AWK:  One consequence for this is discouraging use of label.
17:47:39 <alastairc> Arg, dis-incentivising associated labels would not be good
17:47:54 <ShawnT> +1 to AWK that would not be good
17:48:10 <Chuck> ack Gregg
17:48:14 <bruce_bailey> ... use of label makes meeting this SC harder -- and accessible name makes it not absolutely necessary...
17:48:28 <bruce_bailey> ... but it would be bad to discourage use of label
17:49:14 <bruce_bailey> GreggV:  Not sure this discourages use of label.  Not seeing a problem.
17:49:17 <alastairc> q?
17:49:40 <bruce_bailey> ... SC does not say designers HAVE to do things a certain way.
17:49:51 <Chuck> ack Ch
17:49:51 <Zakim> Chuck, you wanted to propose a resolution
17:50:06 <Chuck> proposed RESOLUTION:  Accept the change to using target size as the basis for measuring components.
17:50:10 <bruce_bailey> Chuck:  I have prosed resolution...
17:50:27 <bruce_bailey> +1 to support
17:50:30 <bruce_bailey> 0 to tolerate
17:50:32 <GreggVan> I was confused with your argument so I am not pro or con
17:50:35 <AWK> -1
17:50:35 <GN015> -1
17:50:35 <bruce_bailey> -1 to not tolerate
17:50:41 <alastairc> 0
17:50:44 <ShawnT> 0
17:50:44 <kirkwood> -1
17:50:48 <GreggVan> +1
17:50:50 <MelanieP> +1
17:50:52 <Detlev> 0 sufficiently not sure to say zero
17:51:01 <alastairc> I think we'll have to come back to this, we need Wilco on the call and the examples to hand
17:51:04 <Rachael> 0
17:51:04 <jon_avila> +0
17:51:15 <bruce_bailey> Chuck:  basically accepting PR
17:51:34 <Detlev> agree we need Wilco on the call to move forward
17:51:37 <bruce_bailey> GreggV:  Is target size?
17:51:43 <Jemma> target
17:51:43 <Jemma> 
17:51:43 <Jemma> region of the display that will accept a pointer action, such as the interactive area of a user interface component
17:51:52 <bruce_bailey> Alastair:  region of screen that can accept input
17:52:02 <Rachael> +1
17:52:05 <shadi> +1
17:52:09 <kirkwood> +1
17:52:15 <bruce_bailey> Chuck:  no leave for Wilco
17:52:23 <shadi> s/+1/
17:52:24 <bruce_bailey> RESOLUTION:  We love Wilco
17:53:00 <bruce_bailey> Chuck:  we do not have consensus
17:53:26 <Chuck> TOPIC:  Question 3 - Insufficient requirement for focus indication via enlargement #1858
17:53:33 <Chuck> Chuck has changed the topic to: Question 3 - Insufficient requirement for focus indication via enlargement #1858
17:53:57 <bruce_bailey> zakim, next item
17:53:57 <Zakim> agendum 1 -- WCAG 2.2 Page break navigation (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/ -- taken up [from Chuck]
17:54:15 <Jemma> zakim, take up item 3
17:54:15 <Zakim> agendum 3 -- WCAG 2.2 Misc https://www.w3.org/2002/09/wbs/35422/wcag22-misc/ -- taken up [from Chuck]
17:54:22 <Jemma> agenda?
17:54:39 <Chuck> TOPIC:  Question 3 - Insufficient requirement for focus indication via enlargement #1858
17:55:11 <bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-misc/results#xq2
17:56:09 <bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq28
17:56:26 <chaals> chaals has joined #ag
17:56:26 <bruce_bailey> Ben opened Issue 1858 about whether the examples are sufficient.
17:56:32 <bruce_bailey> Alastair & David proposed a response, essentially - we agree but not allowing for those examples would create false-positives.
17:56:40 <bruce_bailey> Agree with the response	9
17:56:45 <Chuck> proposed RESOLUTION: Accept amended response from Alastair and David to address issue 1858.
17:56:48 <bruce_bailey> Agree with adjustment	: 5
17:57:01 <bruce_bailey> https://github.com/w3c/wcag/issues/1858
17:57:06 <GN015> q+
17:57:08 <alastairc> Overall, whilst it is a limitation, it allows for several types of designed focus indicator that are not a problem. It is also mitigated by the dynamic nature of focus indicators.
17:57:15 <Chuck> ack GN
17:57:52 <bruce_bailey> Gundula:  Amended still relies on insufficient indicatore
17:58:08 <alastairc> We can remove the last sentence
17:58:13 <alastairc> "Overall, whilst it is a limitation, it allows for several types of designed focus indicator that are not a problem."
17:58:15 <bruce_bailey> ... users might need to shift gaze from keyboard and back again...
17:58:43 <bruce_bailey> ... the focus indicator can dissapear during that change of gaze
17:58:55 <bruce_bailey> ... cannot rely on dynamic indicator.
17:59:01 <alastairc> https://github.com/w3c/wcag/issues/1858#issuecomment-907361220
17:59:01 <Chuck> proposed RESOLUTION: Accept amended response from Alastair and David to address issue 1858.
17:59:08 <Chuck> +1
17:59:10 <bruce_bailey> Chuck:  edit has removed that last part of the response.
17:59:18 <alastairc> +1
17:59:19 <Ryladog> +1
17:59:23 <Detlev> +1
17:59:23 <GN015> +1
17:59:28 <jon_avila> +1
17:59:35 <Rachael> +1
17:59:35 <Detlev> present+
17:59:35 <Jemma> +1
17:59:37 <kirkwood> +1
17:59:41 <bruce_bailey> RESOLUTION: Accept amended response from Alastair and David to address issue 1858.
17:59:45 <Ryladog> Happy Hollardays!!
17:59:48 <jon_avila> * Happy holidays
17:59:50 <MelanieP> Cheers!
17:59:50 <GN015> q+
17:59:53 <kirkwood> present+
17:59:54 <bruce_bailey> Chuck:  Last meeting of the year.  Thanks everyone!
17:59:57 <Chuck> ack GN
18:00:08 <bruce_bailey> present+
18:00:10 <Jemma> Happy holidays, everyone!
18:00:19 <alastairc> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas
18:00:29 <ShawnT> Happy holidays! Stay safe!
18:00:30 <bruce_bailey> Alastair:  next meeting is 1/4/2022
18:00:40 <Jemma> rrsagent, make minutes
18:00:40 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/21-ag-minutes.html Jemma
18:00:50 <jon_avila> rrsagent, list attendees
18:00:50 <RRSAgent> I'm logging. I don't understand 'list attendees', jon_avila.  Try /msg RRSAgent help
18:01:04 <jon_avila> zakim, list attendees
18:01:04 <Zakim> As of this point the attendees have been Chuck, Rachael, kirkwood, Jen_G, bruce_bailey, ShawnT, MelanieP, shadi, GN, Katie_Haritos-Shea, Jemma, AWK, GreggVan, Detlev
18:01:13 <jon_avila> present+jon_avila
18:01:42 <jon_avila> rrsagent, make minutes
18:01:42 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/21-ag-minutes.html jon_avila
19:32:27 <chaals> chaals has joined #ag