W3C

– DRAFT –
AGWG Teleconference

14 December 2021

Attendees

Present
(tink), .75, Aimee_U, alastairc, AngelaAccessForAll, AWK, Azlan, Breixo, bruce_bailey_, chaals, Chuck, janina_, Jaunita_George, jeanne, Jemma, Jen_G, Jennie, JF, jon_avila, Judy, KimD, kirkwood, Laura_Carlson, Lauriat, LisaSeemanKest_, Léonie, Léonie (tink), mbgower, MelanieP, mgarrish, Nicaise, Rachael, Raf, shadi, ShawnT, stevelee, SuzanneTaylor, Wilco
Regrets
Allistair G, Sarah
Chair
Chaals
Scribe
alastairc, Chuck, jeanne, Rachael

Meeting minutes

Review how this session will be managed

Chaals: We will follow the agenda and focus on listening. I will ask a few questions and then go back to listening.
… As we work through issues, there are a few things I'd like to you to focus on. When answering the question, please focus on the question. You can also +1 items in IRC.
… please do put your hand up and speak (use q+ to add yourself to queue).
… if you've +1 then you don't need to repeat an idea. We have the whole meeting. I plan to give people enough time to speak but not an unlimited time to speak. Questions?

<Zakim> JF, you wanted to ask if we have defined "success" for this exercise

JF: My question is do we have a working definition of what success is? I'm looking at the agenda. Can we get the big goal articulated?

chaals: Very good question. Does anyone have a sense of what they think before I answer the question from my sense?

<JF> TY

chaals: my sense of success is that we have a clear agreement across the group that we have a good working process and have addressed the issues and that previous problems will have been addressed. If people are still unhappy on how the group is making progress, we will not have acheived success. WAlthough at some point before we have spent "too much time" wWe will ask how much success we have acheived and how much more time we want to put into the exercise. thoughts?

<Wilco> +1

<jeanne> +1

Chuck: I think its a big ask to assume everything will have been solved by the end of the call but if we can identify data points that can be acted upon, even if we don't come to solutions, that would be a measure of success.

<Lauriat> +1 to Chuck

<alastairc> +1

<jeanne> +1

Chaals: That is a reasonable level of compromise I can live with. I've committed to be available to this meeting and the next meeting, if needed. If at the end of the next meeting we think there is a lot farther to go, we should be taking stock.

Review process changes made to date

Chaals: The process has been recently tweaked.

Rachael: To address some of the issues, we've made a couple of process changes. A lot of discussion around the WCAG 3 document, marking that up. We've also tried to rely more on surveys, and reviewing the surveys differently
… those changes came out of the previous discussions, but we realise there is more to go.

chaals: From the retro or separately?

Rachael: Some from the retro, and ongoing conversations in this group.

chaals: I've read the minutes of the meeting where you looked at the proposal, looked at the proposal, it had a 2 month timeline to review.

<Rachael> minutes from previous meeting: https://www.w3.org/2021/11/05-silver-minutes.html#t02

chaals: is the outcome so far what you expected? Is it working?

JF: Two things that have been working out well from my perspective. We send out a list of questions before the call and ask people to write back before the meeting. I'm likin

<laura> +1 to jf

<tink> +1 to JF's comment about the chairs doing a good job.

alastair: In terms of publishing, its a bit early to say. We are going to mark up the document with maturity labels. We have a mockup of that but we need to get that into a proper PR to share with the group. After that it will hopefully be more obvious there is an new process and people can see the difference.

<JF> +1 to that Chuck

<kirkwood> +1 to JF regarding surveys giving structure

<ShawnT> +1 to Chuck

Chuck: From the perspective of reviewing responses and running that process, it feels as though we are giving more voice and attention to individuals who have not in the past had the same opportunity to express their opinions. That is from the chairs perspective. Hope we can get feedback from those individuals. It seems to be working from our perspective. More diversity in voices/opinions.

LisaSeemanKest_: There was a concern from members of COGA who don't like filling out the surveys. There are a couple of problems with them. They've gotten a lot better in terms of people feeling confident. Its still not the preferred format for some people who'd like to participate.

chaals: this is the big question I had next. Its not perfect. Still people who are feeling like its difficult to be heard but its better? Is that a fair summary?

<kirkwood> +1 to Lisa regarding survey barriers esp. COGA

LisaSeemanKest_: There are COGA members on the call who I invite to share their experience. If you don't have a channel that people feel comfortable speaking out on, then you won't know you are missing those voices. That tends to happen when we survey. Theres a group of people who you don't necessarily know you are not getting feedback from them.

chaals: I think we should mark this point down.

<alastairc> I'm making a list...

<JF> +1 - timelines are often quite short

<Wilco> +1

janina_: I am a bit concerned about using surveys to track conversations. The questions are put out on Thursday. A few responses come in on Sunday and Monday. Big stream in the last hour before the call come in. Its hard to track. On the call itself, we reiterate what is said in the surveys. I'm not sure its the best efficiency. Do others agree it needs some fine tuning?

<Chuck> +1

<kirkwood> +1

<mbgower> WOuld an earlier deadline for survey responses partially address that?

chaals: If people are feeling this in the group, I imagine Coga are probably feeling that too.

<stevelee> +1 to chuck - sometimes coga group are the canary

<mbgower> What are suggested alternatives to surveys?

LisaSeemanKest_: This is a concern brought up in the COGA taskforce a few times. They used to be a lot more complicated. Still multistep processes. Not sure. You have to open multiple tabs and the orientation process may be hindered by someone's disability. Even people who work in the field struggle. We have given that feedback. Use a google doc as well or call on people during call. If you structure conversation on survey results. To make it
… inclusive, use survey plus another mechanism

kirkwood: It becomes especially difficult when surveys are integrated with Github. Its hard to track. People feel uncomfortable saying anything because they aren't sure they have the information they need. [added by chaals: John Kirkwood clarified that this meant input was being lost because it was too hard]

<laura> +1 to GitHub complicating surveys.

<tink> +1 it's difficult to know where to find discussions and information because it's split across multiple places (email, surveys, meetings, Github etc.).

<JF> +1 to Tink

<chaals> [good question mbgower (there are many possible answers).]

kirkwood: I am not comfortable with answering for all COGA.

JF: I think one of the problems is that the information is scattered over multiple places. I do not like using google docs. I find them next to impossible to find. File management in Google docs doesn't work for me. We have emails, surveys, github. Part of the problem is that no one solution works for everyone, so we use multiple solutions that doesn't work for anyone

<Zakim> tink, you wanted to discuss a new topic

chaals: I think that in my experience lots of places cause problems but I recognize the irony of a group on inclusion saying you must use this even though its not working for you. Note what solutions are workable even if not preferred, vs which are just too hard to work effectively?

<janina_> +1 to tink on strongest vs loudest objections

<AWK> +AWK

<AngelaAccessForAll> +1 to tink

<chaals> [chair hat off: +1 to the distinction between "strong" and "loud" objections being important]

<ShawnT> is there something that we can use that's interoperable, similar to RSS?

<alastairc> q/

<Lauriat> +1 to tink

<Zakim> alastairc, you wanted to say what the current workflow is supposed to be...

tink: As someone who used to be in the group but came back after a break. In meetings, sometimes we mix up "strongest objections" with "loudest objections" I wonder what affect that has on new members who aren't used to the feistiness of W3C life. I wonder if it leads people to leave. I suspect its related to the bit in the decision making process. I expect it may relate for the process part that says striving for unanimity. That means that a
… few louder voices can block things. I wonder if it got out of shape somewhere without anyone realizing it?

<jeanne> +1 to tink

<janina_> +1 to agree that consensus is not necessarily unanimity

<bruce_bailey_> +1 to tink's comment of strongest objection vs loudest objection

+1

alastairc: We have various mechanisms for gathering issues but they are supposed to end up in github. we have two types of surveys. One is backlog surveys that center on github issues. That may have one issue or hundreds of comments. It may end up in a proposed change and/or a response. The survey is our mechanism to bring it into one place. What we have tried to do is to encourage as many people as possible to fill in the survey to have

people's thoughts in advance...
… we can start to pick out topics. That helps us, the chairs, to structure the conversation a bit better. But that is our backlog type survey. We also use the same mechanism to discuss more open questions like when we are going to review a whole document.
… its expected there will be bigger variety of opinions on these. Surveys are used for very different types. Sent out on Thursday. Respond by Tuesday. IS helpful for us.

janina_: At the risk of trailing something I just complained about, what about an earlier cut-off for the survey?
… encourage people to get in earlier rather than last minute.
… could think about email as another mechanism, but look to make them more efficient.

chaals: Please hold off on solutions for now, we're trying to understand the issues.

<jon_avila> I think closing off the survey would prevent people from getting their input in.

JF: On Janina's comment, they go out thursday, not enough time to tuesday.

chaals: we've discussed the changes since Nov (Oct), but the question is what are the actual problems we're facing?
… what are the problems you are facing still?

<Rachael> https://docs.google.com/document/d/1Kjovufu66f_k0cA06uBlPWXQWqwO-In4RW9NfCJQYW0/edit#

<jeanne> https:/www.w3.org/2021/11/05-silver-minutes.html

<janina_> An issue is Fear of publication

<trackbot> Created ISSUE-56 - Fear of publication. Please complete additional details at <https://www.w3.org/WAI/GL/track/issues/56/edit>.

chaals: Please speak from your own perspective. If you aren't comfortable saying that hear, please email / talk to me over the next week.

<Jemma> Google doc Rachael shared has a great summary.

janina_: We're looking at WCAG 2.2 which is end state, but also looking at very early stages of WCAG 3. We're so far from updating the working draft.

<tink> +1 (and then some) to Janina and struggling to put words even into Editors' Draft.

<jeanne> +1

chaals: I've seen expressed in various minutes both sides of that discussion. There are different issues at hand.

<ShawnT> +1

<bruce_bailey_> +1 to janina's point, that it should be easier to publish

chaals: and it helps to +1 when someone (e.g. janina in this case) makes a point you agree with.

<kirkwood> my issue the barriers (slowness) lack of stuctured embracing of collaboration in real time iditing (weither mcrosoft/google docs)

<KimD> +1 we should be able to publish (WCAG 3) often to get feedback.

kirkwood: Not having a sandbox or a collaborative live environment, e.g. google docs or online word, so that we can each jump in and comment, or add editorial changes. We seem very behind the times on that.
… we need to take advantage of that more.

Lisa: Apologies if I missed something (internet issues). My concerns with moving forward with WCAG 3, is that we wanted to ask some questions on a draft. We made some alternative versions to ask about granularity of templates keep shifting.
… we were advised to get these drafts as good as we could before even asking the question. But it brings up big risk of having to do the work 10 times.
… running the risk of not being able to create materials of a high enough standard before we can ask questions.
… seems a good way to ensure we burn out.
… We've got to be working together to address the user-needs, which needs to be first, before we worry about later things (like testable).
… if we shut things down too quickly we can't do that.

<jeanne> +1 to Lisa about testability being more valued than addressing user needs

Lisa: If we had a sample, e.g. is this a good structure, we're being asked to make sure it's high standard, pre-empt questions on testability etc.
… otherwise people shut it down straight away. We can't work like that.
… can't experiment, can't get the right granuality sorted out. Also feels like we're not sympathetic group that is working together.

<JF> +1 to Wilco

<laura> +1 to Wilco

<AWK> +1 to WIlco - a huge concern that will result in greater thrash down the road if a regular practice.

Wilco: Firstly, I have a feeling that people try to bypass AG, and bypass the discussions that normally happen in AG. E.g. peices of WCAG 3 that haven't been discussed in the group at all. There was a generic survey for agreeing publication. In doing that, wanting to go to the public before the group, it's the most important line of reviewers.

<mbgower> +1 to risk of publishing too soon. I have been inundated by questions about this new contrast algorithm.

Wilco: there's a risk to publishing things too soon. E.g. the colour contrast algorithm. There's currently a demand in the public for building this into various tools even thought it's not ready yet.

JF: I agree that user-need is an important consideration. That seems to be obfuscating implementers needs. We have to balance those.
… The implementers are the ones who have to act on things, and test them.

<jon_avila> We people with disabilities have to USE the products that aren't accessible.

JF: it can't be for users-alone.

<jeanne> -1 that we are specifically trying to address needs of large organizations

<Judy> +1 to Wilco's concern, also appreciating the particular example that he provided, and the risks of early implementation without potentially insufficiently vetting

laura: there is a fear of publishing a draft that isn't ready because it is hard to get things out.
… consensus can be frustrating, I've experienced that.

<mbgower> +1 to both the importance and frustration with consensus process :)

<JF> @jeanne that is not what I suggested - I am saying we need to solve problems for *both* groups, users AND implementers

<jeanne> +1 for a lot of representation of implementers

LisaSeemanKest: Implementers are very well represented here. The bigger ones have resources. Not worried about the implementer or testing-companies views will be under-represented. The difference between the user-needs in the supplement compared to WCAG was huge.
… that shows how the user-needs aren't adequately represented, rather than the needs of implementers.

<Jemma> +1 to Jeanne for unbalanced voice, specifically stronger voice by testers and implementers.

<Chuck> +1

<LisaSeemanKest> +1

<jon_avila> +1

chaals: Straw poll - Do we give enough priority to the needs of implementers. +1 for yes

<bruce_bailey_> +1

<kirkwood> +1

<laura> +1

<janina_> +0

<tink> +1

<ShawnT> +1

<Lauriat> +1

<Jennie> I am conflicted because of my different roles

<Wilco> 0

<Jemma> +1 to lisaseemankest and user needs

<mbgower> can you clarify which stage of the process you're talking about?

<jeanne> +1

<JF> -.5

<AWK> For WCAG 2.0/2.1 or in all documents?

<Kim_patch> +1

<AWK> 0

<stevelee> 0

<chaals> chaals: Through the process - i.e. by the time a Rec is published. Note this isn't a perfectly scientific question, so we know interpretations of the question will vary…

+1 by the end of the process, but agree we should start with user-needs.

<KimD> -1 if by by implementors you mean content owners/authors, we are under represented in AG, better in Silver TF

<AWK> 0 = adequately balanced

<JennC> +1 by the end of the process, but agree we should start with user needs.

<Rachael> +1 by the end of the process, but agree we should start with user needs.

<mbgower> +1 by end of the 2.1 process

<Wilco> Agree with Kim. Content authors, except for the very large ones, are not well represented here

<LisaSeemanKest> can we also ask if user needs are adequately represented? [chair does so, clarifying the question as "by the time a Recommendation is published"]

<LisaSeemanKest> -1

<Kim_patch> -1

<ShawnT> -1

<jeanne> -1

<Rachael> -1

<kirkwood> -1

<KimD> -1

<Wilco> Which user?

<janina_> +1

<AngelaAccessForAll> -1

<Judy> -1

<Chuck> +1

<JennC> -1

<tink> +1

<Jennie> -1 in some ways

<bruce_bailey_> +1

<Wilco> 0, some are, some are not

<Rachael> Different disabilities are represented more or less adequately

0, it starts there (generally), but in normative requirements can get filtered out by the end.

<KimD> (-1 in AG, better in Silver)

<JF> +.75

<Rachael> aka I think representation varies by category

<LisaSeemanKest> (or as JF would say it -5)

<mbgower> 0 "users" is an awfully big pool

<laura> 0, some are, some are not

<Lauriat> 0

<JennC> retracting back to 0 - some are, some not

<AWK> .5

<Rachael> 0

<Zakim> laura, you wanted to say: Fear of publishing a draft that some think it is not ready or heading in the wrong direction. It is hard to get something out of a draft once it is in.

<Raf> 0

<chaals> [+1 to the concern abut whether this is forming up "camps" … that would be an unfortunate outcome]

shadi: I'm a bit concerned about how this is framed, in terms of camps. People have expressed that not all users are the same or treated the same of equivalently. We need to think about implementability, even in the spirit of WCAG (2) some things are difficult to implement.

<JF> +1 to Shadi - implement-ability is closer to what my concern is, as opposed to 'implementers'

shadi: so the question is how we formulate things to make it feasible, rather than delineating camps.

JennC: Similar to shadi, I think the term "implementer" is the reason I struggled with the question. It could included users, implementers. On COGA, I'm aiming to increase inclusion for people with cog issues. Also trying to teach 40k people to create content. So budget for implementer is really hard to define.
… have to consider all of the audience.

<JF> +1 to Jennie

JennC: not sure all of the roles are being considered. We want something that is used.

<Zakim> mbgower, you wanted to say a more interesting poll to me would be the question 'do you think the 3.0 process to date is achieving..."

mbgower: On that last question, if you made it 'implementability' rather than implementers. you might get different responses from people involved in 2 vs 3. We're trying to find better ways to capture user inputs, and implement those in reasonable ways.
… noting dissatisfaction with the amount of output with things going into 2.1.
… there were about 70 candidate criteria and we ended up with about a dozen [ed - 18 I think]
… solving that problem is a pain point.

<Zakim> Jemma, you wanted to ask the scope/definition of implement-ability

<LisaSeemanKest> +1 to jemma

<jeanne> +1 to focus on automated testing and true false testing

Jemma: I think Michael Gower addressed it well. I really like implementability, it's important for the standards to be acceptable. But hearing it here, it tends to be about automated testing.

<Lauriat> +1

<mbgower> +1 to jemma

chaals: Let's take a break for 3 minutes.

<KimD> +1 to Jemma

<Kim_patch> +1 to John about the importance of efficient, collaborative tools

<shadi> [for the record, I mentioned several parameters beyond testability, including understandability and applicability in practice]

chaals: We are looking at problems that people have looked at. The following were noted in followup of the retrospective:
… When participation lowers, it can reduce diversity of perspectives & voices, and the number of people aware of the details of the work
… One person, unfamiliar with the details, can enter a group and shift direction unexpectedly
… A few prominent voices can end up represented above other perspectives present
… Work should not have gone to a second attempt-at-consensus
… The inconsistent results of those attempts shows a lack of certainty in that consensus
… Surveys prompt a closer look from the larger group who haven't looked at it before; shows potential gaps in keeping the group in the loop and our overall process of review may have missing steps
… The groups do not view themselves as a cohesive unit. AGWG’s role as the approving body causes friction with Silver, particularly when work does not move forward. Silver members see themselves as workers without a representative voice in the approval process. This results in frustration which leads to Silver members leaving.

<Jemma> I agree with Shadi's concept of implementablity principles. However, my observation in wcag and silver discussion has been heavily focused on whether it can be tested "automatically" or even the SC is cost effective to be used for automated testing.

JF: Testability: I don't think that testability has to be machine testable. I look at Content Usable from COGA with a specific outcome without a metric. I think they are testable.
… they are not a specific measure, you can know it when you see it and this is how you can recognize it.
… when people have to implement and do them, they need a measure to know if they did it successfully
… it has to be more than machine testable, but we have to know in some level of confidence that two people can agree it has met the needs

<AWK> Very few things in WCAG are fully machine testable - agree that SC are not held to a standard of 'must be automatically testable'

<Jemma> +1 awk

<Rachael> +1 to awk

chaals: are there other problems that we need to address?
… several people have said that some people have said that the difference between the completion level of 2.2 and 3.0 is a problem

<janina_> +1 that it's hard for this one group to finalize 2.2 while organizing and promoting a nascent 3.0

LS: Content Usable does have a section of how things can be tested and some are by user testing. If you have tested these things, you have done a decent job of implementing it.
… when we got rid of user testing in WCAG, that was a big change. User testing is a great way to know that something is implemented properly

chaals: I'm going to back to the issue of testing and testability.

<Chuck> +1 with that requirement

<janina_> +1 to Charles

<laura> +1

<Wilco> +1

<Lauriat> +1

<KimD> +1

<bruce_bailey_> +1

<AWK> +1

chaals: is there any disagreement with the idea that when we produce a recommendation, it includes that it explains how to implment it and know whether you have implemented it or not?

<janina_> -1 to minor diffs

JF: Implemented properly

<Wilco> Yes, minor differences matter

Chaals: I will wait on that interpretaion.

<bruce_bailey_> +1 because pretty sure there will be minor differences !

Chaals: let's also look at whether we can ignore whether there are minor differences in implementation

<AWK> how minor?

<KimD> Minor differences *may* matter, *and* they already exist in WCAG 2.x

<AWK> We need to eliminate subjectivity whenever possible.

JF: I agree there must be some level of testability, for example, a text alternative with a useless alternative
… we received feedback that counting is too difficult and we received feedback from stakeholders that counting is onerous. I'm concerned about the adoption of that.

<Zakim> mbgower, you wanted to say I wouldn't use the word test

MG: I agree that we want to have an area that is clearly about what is testable and repeatable. I don't think there has to be a "no go" are that are process related and maybe the final outcome may not be identical.

<LisaSeemanKest> +1 to MG

MG: within a team, you can agree that something meets the guideline, without having it is fully testable and reproducable

+1 to MG

<Jemma> +1 to MG and thanks for explanation associated with detailed workflow of measurement

LS: This fits in with what Mike Gower is saying that there are many ways of testing and we need to be open to that.

<jeanne> chaals: If you are ok to have minor differences in results, then you should put that in IRC

Rachael: You had asked what other issues other than what is on the list. I float that we may be beyond communication and tools have a challenge with trust.

<Wilco> +1

Rachael: Not sure it's there or not, but want to raise with the group for consideration. Lots of work coming up, and a need for us to not all have to be present.

<Lauriat> +1 to Rachael

Rachael: Is there a gap?

<KimD> "minor differences" is too hypothetical - some are ok, some are not.

chaals: In any group is a critical question.

<tink> +1 to Rachel and needing to trust each other to make good decisions.

<janina_> +1 to Rachael; esp. vis a vis what we expect from 2.2 as opposed to 3.0

<mbgower> As an example: "test your design with diverse users" a company can come up with their processes to achieve this, potentially publish that process, and confirm it is met with a release

<Kim_patch> In thinking about testability I keep coming back to this question: it useful for us to recognize that something is an issue for users even if we can't test it?

<jeanne> +1 to a gap in trust

chaals: I'm glad that was asked. It's unlike us... if people think there is a gap in trust, if its holding the group back, if you are comfortable providing your opinion, please do so.

<Jemma> +1 to Rachael

<KimD> +1 - yes, gap in trust

<alastairc> +1, minor differences are ok, but it is probably best to separate into different levels. E.g. small differences guidelines around technical aspects (e.g. page language), but allowing for more at the process/protocol level.

chaals: I understand that some may want to answer privately.

<JF> +1 there is a gap in trust

chaals: I will keep answers in confidence if provided through other channels.

<mbgower> +.5 yes, gap in trust

<Jemma> +1 to Alastairc

+1 there is a gap in trust

<LisaSeemanKest> +1 yeah

<Kim_patch> +1 gap in trust

chaals: Appears consensus on this point.

chaals: I have no answer for in next 30 minutes.

<Zakim> alastairc, you wanted to ask about the challenge of so much work in parallel, from one of the issues raised.

chaals: Alastair had a different but important question.

<kirkwood> result of Covid and lack of in person meetings?

Alastair: I'll continue Rachael's point. More raising the issue, in order to get WCAG 3 done, much has to be done in parallel. One thing that came up is that people work on something...

Alastair: gets to survey... The wider problem or example is that we have lots working in parallel, new guidelines, conformance, etc. We have to work in parallel.

Alastair: What mechanisms can we use to stay up to date on the parallel activities. What would work for the members w/o being overwelmed?

<mbgower> The feeling that no one is trying to game the system

chaals: Trying to call on Lisa...

chaals: will come back. Wilco.

<LisaSeemanKest_> sorry im back

<Kim_patch> start with using tools that allow people to collaborate more efficiently in the first place and follow what has happened

Wilco: Expressing my own sense of distrust. Reflecting on what Rachael said, there are a number of people in the group that I don't trust will represent the testability requirement very well.

<JF> +1 to Wilco I have a similar sense

Wilco: I need to see everything because at some point things may get put in that are difficult to take out if I don't see it.

Wilco: that's what is making me nervous, I don't know what to do about that.

<laura> +1 to Wilco

<Lauriat> +1 to Wilco, I feel similarly

<Jaunita_George> +1 to Wilco

chaals: Appreciate the way you explained it.

<tink> Kudos to Wilco for such honesty.

<mbgower> +1 I don't like having the feeling that someone is trying to game the system

<alastairc> Yes, if everyone feels a need to check everything, that makes work very slow...

<laura> It is hard to get something out of a draft once it is in.

chaals: Helps us to understand the problem. I can see that we can find ways through this and not take 50 years.

<shadi> Wilco++

Janina: Thank you Wilco. When something is put in it can be hard to take out, so it's important to not mischaracterize when it is put it in. And that also fits in with fear of publishing.

Janina: Maybe we need to work on putting in and pulling out. maybe we can frame it differently than "trust". I see us relitigating same questions.

<kirkwood> Good on you in your want/desire to get it right Wilco

Janina: It's a lack of cohesion. I blame the fact that we are still trying to do 2.2 which has a different set of orientation than 3.0. That's my characterization of the trust question.

<Jemma> +1 to jaunita george

<laura> There is a fear of publishing a draft that some think is not ready or heading in the wrong direction.

Tink: I want to agree that there is a lack of trust, I have listened to many participants express their concerns. Agreeing with Wilco's side, I've seen decisions that I have had difficulty trusting. There are concerns creating guidelines that get entrenched in regulation and the user needs.

<LisaSeemanKest_> +1 to tink

<Lauriat> +1

Tink: I struggle with that. There is a lot of focus on writing guidelines for legislatures and policy makers, but struggle with trusting that this is at the detriment to individuals with disabilities.

<jeanne> +1 tink

<Jemma> +1 thanks for sharing another level of trust issue.

<AngelaAccessForAll> +1

<KimD> +1 with Tink - a LOT of focus on making "legislatable" guidelines.

<bruce_bailey_> +1 to tink -- that too much focus on being adopted by regulators

Lisa: I have thought the same things Tink has. Part of our challenge is the success that legislative bodies refer to us. The issue with trust I see is, in other working groups, when they standardize something, everyone knows you are doing what is in interest for your company.

<Jemma> I think there are different level of trusts - technical, polictical, even individual to individual.

Lisa: Here there's that component. It's a member organization, where people standardize and it's useful to do so. Same as any other division of W3C.

Lisa: But people are torn between personal wish of what's best and representing their company's interest, and people have to do that.

<Jemma> yes, company level of interest, not necessarily technical level.

Lisa: When supporting something that is testable, maybe through a more expensive or slower approach, that will impact their business model, they are going to be under instruction that this is hard for their company.

Lisa: It's not a criticism of anybody in particular, but this is a motivation for people. It has positive aspects, needs of companies are being included, but...

<laura> +1 to Lisa and companies motivated by vested interest.

Lisa: There is the thought that the expense weighs in on the decision, but they won't say outright. Or concerns with legislative pressures.

Lisa: There are pressures that this wg is under, and we need to structure something around that. User testing should not be impacted by those pressures.

<Jemma> + lisa for reality check.

Lisa: Admitting that these pressures exist would be a good first step.

<Wilco> +1, well put Lisa

chaals: We are coming up near the end of the meeting. Queue closed.

chaals: We still need to think about next steps.

<Zakim> jeanne, you wanted to say seeing diaparity in who is doing the work.

Jeanne: I have problems with what feels like disparity between who is doing the work on wcag 3, and it feels silver subgroups are doing all the work and AG votes down in surveys.

Jeanne: It's hard on silver side to do all the work and not be able to see it move forward. It feels like one side is doing the work and the other side says "no".

<laura> Consensus is a lot of work but it produces a better product.

<janina_> +1 to Jeanne

Kim: I want to go back to trust. I see a lack of trust who know at well because they use them. I explain over and over how things work. What happens is that I don't see a curiousity on why it is different.

Kim: You need to explain again. Ties to tools. Stuff goes by and difficult to follow multiple threads. If you use AT and it's difficult, people drop out.

<KimD> +1 to Jeanne. I wonder if this is because there's a lack of clarity/understanding about the difference between 3.x and 2.x?

JF: Legislative is an important drive. I can point to use case in Canada. Before AODA, taking up wcag at scale, task wasn't really recognized.

<Jaunita_George> +1 to JF

<LisaSeemanKest_> me\ thinks that that is why writing a supplement was a good solution

JF: Whatever we take up in wcag 3, there has to have enough for legislatures to adopt.

JF: Otherwise they will ignore.

<laura> +1 to jf

<Zakim> mbgower, you wanted to say that testable is not driving good design; understandable guidelines are -- and company goals are not necessarily divergent with people with disabilities

mg: Taking myself off.

<LisaSeemanKest_> there are people who want thier content to be useable

<Zakim> JF, you wanted to note that without legislators providing the driver, we may not get WCAG 3 adopted: a wonderful spec with laudable goals that no-one will adopt

chaals: Note that we have a number of things to think about and there are still a number of things to say. We have 12 minutes left.

chaals: We won't get all answers. I have some proposals.

chaals: Distrust is clearly an issue that we have to work on. It does appear to be holding us back.

chaals: Related feeling for a number of people that it's difficult to get work published. Relation being that there are people who don't trust that their work will be treated fairly, and that the work will be what they need in spec.

chaals: Getting work in draft seems to be an area.

chaals: Issues like people will use these in legislation. Contrast and color mechanisms adopted before they really are finalized.

chaals: It's also a case that the rest of the world is desperate for a partial solution, which is better than what they have now.

chaals: A partial solution may not be a bad thing to have.

chaals: And minds can be changed.

chaals: There are a couple of things that are important to keep looking at. One is tooling. What are the tools that people can work with.

chaals: Next step is can we gather what people would like to say in response to this meeting? Can we use the survey system? I'd like the chairs to continue to encourage getting more feedback on challenges.

chaals: What's deadline for agenda of next meeting?

Alastair: Meeting today, planning call tomorrow, we get agenda out shortly there after. Deadline is day after previous meeting.

chaals: Seems important to have another meeting on topic. Having planned by tomorrow may be too soon. But would be useful to have another call after we reflect and where we've looked at what is working well in addition to the challenges. Can we return in the new year?

<laura> +1

+1

<Jaunita_George> +1

<JennC> +1

<janina_> +1 to next year

<bruce_bailey_> +1

<kirkwood> +1

<JF> +1

<stevelee> +1

<ShawnT> +1

<Jemma> +100

<Rachael> +1 and next week we would work to wrap up WCAG 2.2 issues.

<alastairc> +1, particularly if people can send around suggestions before then.

<Jennie> +1

<mbgower> +1

<jeanne> +1

<Kim_patch> +1

chaals: I want to support Alastair's point and get support from chairs. We need to process this.

<KimD> +1 to continuing issues

<JF> @Chaals, you mentioned also accepting private comments. Perhaps you could share an email address?

chaals: I will try to write up the issues identified and make it available by next meeting, though may not be a topic in next call. From that point on....

chaals: We should suggest additional changes that might help with the issues. My email address is <pasted>

<chaals> [my email address is charles.nevile@consensys.net]

chaals: Please put something clear in subject line.

chaals: Email is good, I have a phone number that you can get from chairs.

chaals: I will let chairs schedule instance of this call.

chaals: Asking anyone, if you have comment in less than 30 seconds that you would really like to say before we ajourn.

Wilco: Thanks for running this.

<Lauriat> +1, thank you!

<Jemma> Thanks so much, @chaals

JF: Seconded.

<stevelee> Thanks chaals for solid chairing of a frank discussion

<Jaunita_George> +1

<jeanne> +1 thank you

<janina_> +1 on thanks to Charles!

<mbgower> Thanks for running. Having the discussion helps build that trust and process!

<Kim_patch> +1

chaals: Hopefully we get to a stage where we can finish this and are doing productive positive work on standards.

<AWK> +1 Thanks Chaals

<laura> +1 thank you

chaals: Thank everyone for contributing and making the effort to be helpful, frank, kind and thoughtful.

chaals: I will take up more of your time, starting next year.

chaals: At chairs permission, chairs adjourn meeting?

Alastair: We will let everyone know when it comes up.

JF: Is this last call?

alastair: One more next week, on wcag 2.2 issues.

<Rachael> Thank you all very much

<jeanne> There will be a Silver call on Friday

<chaals> g that, it is getting the conversation to shake out more quickly. I'm also appreciating that the chairs timebox items. That has also been quite helpful.

<chaals> s/people's thoughts in advance…/… people's thoughts in advance...

<chaals> s|Created ISSUE-56 - Fear of publication.  Please complete additional details at <https://www.w3.org/WAI/GL/track/issues/56/edit>.||

<chaals> s/people's thoughts in advance…/… people's thoughts in advance…/

<chaals> s!s/people's thoughts in advance…/… people's thoughts in advance…/!!

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/implementors/implementers

Succeeded: s/obfuscating developer needs/obfuscating implementers needs

Succeeded: s/lisaseems/lisaseemankest/

Succeeded: s/can tested/can be tested/

Succeeded: s/q_ lisa//

Succeeded: s/feedback on/deadline for agenda of/

Succeeded: s/Is next meeting next weeK? 21 December?//

Succeeded: s/dont'/don't/

Succeeded: s/e will ask how much success we have acheived and how much more time/Although at some point before we have spent "too much time" wWe will ask how much success we have acheived and how much more time/

Succeeded: s/by the end fo/by the end of/

Succeeded: s/I've been committed to be/I've committed to be/

Succeeded: s/... is that what you expected?/… is the outcome so far what you expected? Is it working?/

Succeeded: s/JF: Two things I noticed have been working well, is that we have agenda questions prior to the call, and ask people to respond in writing. That's managed to shake out the conversation more quickly. Also appreciating that the chairs are time-boxing things.//

Succeeded: s/JF: Two things that have been working out well from my perspective. We send out a list of questions before the call and ask people to write back before the meeting. I'm liking that. I'm also appreciating that the chairs timebox items. That has also been quite helpful./JF: Two things that have been working out well from my perspective. We send out a list of questions before the call and ask people to write back before the meeting. I'm likin

Succeeded: s/bruce_bailey_: I heard John Kirkwood say its the latter one.//

Succeeded: s/First I was queued to bring in that it becomes especially difficult when surveys are integrated/It becomes especially difficult when surveys are integrated/

Succeeded: s/People feel uncomfortable saying anything because they aren't sure they have the information they need./People feel uncomfortable saying anything because they aren't sure they have the information they need. [added by chaals: John Kirkwood clarified that this meant input was being lost because it was too hard]

Succeeded: s/chaals: I had asked if the problem COGA was having was that it was complicated. I think you answered that you think feedback is being dropped.//

Succeeded: s/good first question mbgower (there/good question mbgower (there/

Succeeded: s/Note what solutions can we live with vs what ar etoo hard/Note what solutions are workable even if not preferred, vs which are just too hard to work effectively/

Succeeded: s/we can start to pick out topics. That helps us,/… we can start to pick out topics. That helps us,/

Succeeded: s/Are we having closed captions on the Zoom meeting?//

Succeeded: s/I got it to work- thanks.//

Succeeded: s/tink, you wanted to ask a question about the sandbox idea//

Succeeded: s/can we also ask if user needs are adiquatly represented ?/can we also ask if user needs are adequately represented? [chair does so, clarifying the question as "by the time a Recommendation is published"]

Succeeded: i/+1 by the end of the process, but agree we should start with user-needs/chaals: Through the process - i.e. by the time a Rec is published. Note this isn't a perfectly scientific question, so we know interpretations of the question will vary…

Succeeded: s/chaals: We are looking at problems that people have looked at/chaals: We are looking at problems that people have looked at. The following were noted in followup of the retrospective:

Succeeded: s/chaals, you wanted to ask Kirkwood to state whether his point is that tools can be better, or that putting things where we can see them and play with them is important, or both//

Succeeded: s/inclusive, use survey plus another mechanism/… inclusive, use survey plus another mechanism/

Succeeded: i/alastair: In terms of publishing, its a bit early to say./scribe: rachael/

Succeeded: s/alastairc: It's a little early, as we haven't published the new labelling yet.//

Succeeded: s/Chuck: from the perspective of running that process, it feels as though we're giving more voice and attention to people who hadn't provided their voice in the meetings.//

Succeeded: s/few louder voices can block things. I wonder if it got out of shape somewhere without anyone realizing it?/…few louder voices can block things. I wonder if it got out of shape somewhere without anyone realizing it?/

Failed: s/people's thoughts in advance…/… people's thoughts in advance...

Succeeded: s/Issue: Fear of publication/An issue is Fear of publication

Failed: s|Created ISSUE-56 - Fear of publication.  Please complete additional details at <https://www.w3.org/WAI/GL/track/issues/56/edit>.||

Failed: s/people's thoughts in advance…/… people's thoughts in advance…/

Maybe present: alastair, Janina, JennC, Kim, laura, Lisa, LisaSeemanKest, LS, MG, tink