AGWG Teleconference -- 14 Sep 2021

<Chuck> meeting: AGWG-2021-09-14

<alastairc> scribe: Fazio

<scribe> scribe: fazio

No new topics

Mobile taskforce needs members

Chuck: Mobile Task Force needs/requests new members

Bruce: Federal group focuses on mobile web - would like to invite them, but wants a template invite if available

<Lauriat> +1, I'd like to forward some call for members to folks in Google

WCAG 3.0 Conformance plan https://docs.google.com/document/d/1Fvj3M0RS-U_A66UGaYfCgHVTOvOJ9j1NOOpK4Ufar5Q/edit#heading=h.49wk4uo76vj

Janina: Mobile TF should have a wiki page to use

GN: does Mobile TF deal with Native programming or something else?

<alastairc> As part of AG, focused on web as our scope. However, it's useful to understand how the native aspects work as well.

Jake: focus is on Mobile devices - only web- interested in native but Web views are the focus

<Rachael> From Kim: The Mobile Accessibility Task Force needs more members – especially mobile developers and people who work with users. Currently, we’re coordinating with Silver on the template and process to move existing 2.1 Mobile SC’s to the new format. Coming up are discussions about new mobile operating system abilities and how they’ll affect standards, and how mobile apps fit into the picture.

GN: why is there a ned for Mobile TF?

JF: Silver subgroup to look at protocols is forming, seeking participants - contact JF at [email protected]

Rachael: Mobile TF is looking for Mobile developers

<jeanne> Actually, the task forces preceded WCAG 2.1

<Zakim> Chuck, you wanted to answer Gundula

<alastairc> Why a task force? Because it's really hard to do formative work in a large group with >20 people.

Chuck: TF given lattitude to explore ideas informally that can't be fit into formal meetings

<Rachael> https://docs.google.com/document/d/1Fvj3M0RS-U_A66UGaYfCgHVTOvOJ9j1NOOpK4Ufar5Q/edit#heading=h.49wk4uo76vj

<bruce_bailey> is gant chart available in spread sheet or project plan format ?

Scoring discussions coming up - foundational work, protocols, paths, levels

iterative publishing, revising will continue over the next year

2023 formal publication is expected

JF: thinks the time crunch is insufficient
... more time is needed for the complexity

Peter: big fan of the work on this plan

Rachael: wcag 2.2 should finish in 2 months, focus will intensify on wcag 3 at that point

Bruce: project plan Image really needs to be an accessible doc

<jeanne> +1 bruce. I can't read it except in Rachael's screenshare

gregg: Plan needs to be flexible because it's not realistic

<Chuck> +1 for Gregg's comments

<jenniferS> Thank you, Bruce, +1

<jenniferS> Sorry, +1 to Gregg.

Garr: plan constrains work, but concerned about how and what it constrains

WCAG 3.0 Request for approval to publish if all content has been approved via CFC

<PeterKorn> +1 to that extension

<sajkaj> +1000 to Rachael

<jeanne> +1 to extension

Rachael: Can we skip CFC for WCAG components that have previously been approved?

GN: thinks CFC is important for the entire doc regardless if individual pieces have gone thrtough process

Gregg: even WCAG 2.2 shouldn't skip a final CFC

<jeanne> -1 that we spend so much time on CFC voting, and WCAG3 is in such an early draft

+1 gregg

I agree with Gregg

Alastair: WCAG 2.2 and WCAG 3 are in vastly different states, so they can be handled differently. Less complicated for WCAG 2.2

<bruce_bailey> [11:34] * bruce_bailey afk a bit, bandwith issue -- need to check that no one in house is streaming...

<Zakim> idea, you wanted to discuss handling both perspectives

Jake: likes project plan, not much call for consensus in silver
... a lot of AG doesn't have clear understanding of WCAG 3

<JF> +1 to Jake

Peter: project plan likely too modest. Need to carefully examine all drafts, which are calls for comment not consensus
... relax some of the protocols on the many small iterations. If CFC is needed for every little change this will take too long

Gregg: once consensus is acheived issue needs to be closed unless new issue arises

<Chuck> +1 to janina

<Zakim> Chuck, you wanted to say I see two questions

<tink> +1 to Janina

current expectation is to show progress not get consensus

<jeanne> +1 to Janina

gregg: traditional standard creation process doesn't apply to this

<GN015> +1 to Gregg

<MelanieP> +1 to Gregg

<JakeAbma> +1 Gregg

<Chuck> draft poll: option 1: CFC each piece and not the whole, 2. CFC the whole but not the parts, 3. CFC both the parts and the whole

<JakeAbma> 3

<laura> 3

<david-macdonald> 3

<GreggVan> 3

<GN015> 3

<sajkaj> Option 2

<alastairc> 1, could live with 3

<garrison> 2

<Rain> 3

<PeterKorn> Question: this poll is JUST for right now, correct?

<kirkwood> 3

<Chuck> 1, can live with 3

<Rachael> 2

<bruce_bailey> 3, can live with any

<JF> 3

<MelanieP> 3

<Jennie> 3

<tink> 2

<alastairc> I assumed it was for WCAG 3.0, for the near/medium future

<david-macdonald> Measure twice, count once

<Chuck> Fazio: I know it seems we'd get more done w/o CFC'ing everything. I think we will run into problems however, if we don't.

<bruce_bailey> +1 (to gregg comment) that the bar for writing text that is anticipated to picked up by regulators is higher than writing industry consensus standards

<PeterKorn> Option 4: it is situational. For major revisions, 3 is appropriate. For a small collection of revisions ahead of a quarterly publication, optoin 1 makes sense to me.

<jeanne> 1

<Chuck> I count option 1 - 3, option 2 - 4, option 3 - 11

<Lauriat> +1 to tink, we need stakeholders involved in reviewing things earlier and more often

<Rain> +1 shifting my vote to 2. Gives a better understanding of what we are reviewing because we have the whole.

<alastairc> Hard question at the moment as we have a significant milestone coming up with conformance, which is one large things, then followed by lots of small things. So could do 2 then 1.

Gregg: if you don't cfc every step, little things will pop up at the end that derail the process

I agree with Gregg

<PeterKorn> Anything we decide here, right now, we can change our mind on later (like Congress, future sessions cannot be bound by what previous sessions decided).

<PeterKorn> I suggest we just decide what we do right now.

<jenniferS> was kicked out of IRC

<jenniferS> Lost the options even before I was kicked off IRC.

scribe change soon :)

<jenniferS> Thank you, Rachael! I vote 2.

<Wilco_> Joining in late, want my vote recorded: 3

<Chuck> current unscientific count: Option 1 - 1, option 2 - 7, option 3 - 11

<Chuck> ack

<Zakim> Chuck, you wanted to say an observation about how we've been doing it

<bruce_bailey> Pretty sure this is the post Jake is refering to:

<bruce_bailey> https://lists.w3.org/Archives/Public/public-silver/2021Mar/0002.html

<Lauriat> FYI: I saw 3 people vote for option 1

<bruce_bailey> That URL includes link to attachment.

<JF> +1 to Chuck

<alastairc> Suggestion: Commit to full CFCs for wide review publications, but keep the in-between consensus to items likely to cause objections, at chair's discretion as to what would need CFCing (because it's hard to define up front)

garr: can't afford being held up

<Chuck> 3 people did vote 3, but I heard 2 people switch to 2

<Chuck> me being one of those 2

garr: working fast on rough draft is beneficial

<PeterKorn> Sorry; I have to drop for another meeting.

gregg: what's criteria for inclusion if you don't cfc

<Rachael> I believe criteria for going to draft is discussion and consensus in this meeting.

<Chuck> alastair's suggestion: Suggestion: Commit to full CFCs for wide review publications, but keep the in-between consensus to items likely to cause objections, at chair's discretion as to what would need CFCing (because it's hard to define up front)

<GN015> Sorry I have to drop. Can you please take my vote for current Option 3 in case of another voting? Thank you.

<JakeAbma> +1 to Gregg

<JF> +1 to Gregg, which is also why I believe the proposed current timelines are unrealistic (far too short)

garr: sending out draft then dealing with objections takes up more time than addressing them as we go

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

<jenniferS> scribe: jenniferS

Alastair Campbell: hybrid, full CFSs, along with in-between items, key items without consensus, have additional CFCs.

then when we get to wide review, we have reference points.

we're at a point with WCAG3, where we have to make wide scale changes fairly often.

<Chuck> +1 to alastair's compromise

The wider the comment, the longer a solution is likely to take.

Wilco: I feel like this is a false choice.

Not review parts or whole, rather review when there's a new thing to review or only once in a while.

<JF> +1 to Wilco

you want to review every piece as it comes in -- in software dev.

<alastairc> Review != CFC, anyone can raise an issue any time

<Fazio> +1 Wilco

if you review large chunks, ppl feel pressure to approve baa most things are right, but not quite right, and nobody's fully onboard.

Michael: I think this is a scale & granularity question.

we tend to be quite granular.

<Jennie> Smaller sections for review will also be more accessible for some with cognitive disabilities. It would make it easier to decode what has changed, what is to be reviewed.

<Chuck> alastair I agree, 9 more minutes

<Wilco_> @alastairc, review should include CFC IMO

challenge with wcag3 is that it is such a large entity, change happens over rough ground, esp lately.

<alastairc> Wilco - at what level of granularity?

The question is whether we can pivot to giving attention to a point 1 update, and I don't know if we're quite there yet.

people coming in and out, getting up to speed… I'm worried about things getting slowed down too much without resolving CFC level questions.

Leonie/Tink: one way this could be solved/minimized is to publish more frequently.

<sajkaj> +1 to Leonie

<bruce_bailey> @gregg -- there was some parsing of you comments

<bruce_bailey> please see: https://github.com/w3c/silver/issues/487

if there are a lot of comments coming in, it takes time to process.

if you get into the habit of the group coming to consensus on incremental change, encouraging feedback as you go, then you enable a progression to be made reasonably quickly.

<Zakim> Rachael, you wanted to clarify current consensus vs CFC process

Smaller chunks of changes, publish more often.

Rachael: we're using 3 terms interchangeably.

reviewing, in-meeting consensus, and then the CFC process for formal agreement.

I want to make sure we all understand the distinction.

Charles: more frequent publication was intended to reduce issues, but created more issues, it seems. huge barriers with how things interact with each other.

<Zakim> Chuck, you wanted to say timebox and to say timebox and to discuss frequent publishing

JF: not opposed to more frequent publishing, but we're not addressing comments.

haven't heard intersection of CFC to publish and using GitHub issues.

we didn't have GitHub issues with WCAG 2.

now that we have ability to use GitHub, that lighter weight agreement can happen. less haste, more speed?

<Zakim> JF, you wanted to note that if we publish more frequently, we need to dedicate more time to responding to comments

sajkaj: disagree that we're not addressing comments. those of us working in silver… can't speak for everyone.

came in in a variety of methods. addressing formally, requires working group consensus on the responses.

<Chuck> Alastair - I noted the command down :-)

<bruce_bailey> +1 to what Janinia is saying , that the longer comments have been the subject of much conversation

using certain terms --- we have a review process, the WBS survey, then get through, there's a CFC where others respond, then later there's something formal required by W3C where more detail, public review occurs

we're not always detail oriented in scrutiny.

Greg: sajkaj is right, we actually got a group consensus on all the response that came in, met, reviewed the response, wrote it out, we're making the following change.

<alastairc> We do that on issues, but that isn't a CFC

<JF> Respectfully, there are 3.5 pages worth of comments/feedback from our FPWD that have not been responded to

greg: a way out of our conundrum might be… having consensus on CFC was to make sure you have everyone's input. the survey, each issue that was done, we put out to survey. the rule was, if you had a concern, you have to respond to the survey.

<alastairc> JF - we have to make progress on resolving the issues before you can close them, which involves getting agreement on the methods of resolving them.

sometimes issues arose in meetings, we handled those.

greg: that way ou don't have issues that come up after condensed on it.

<JF> @Alastair - understood, but it is nonetheless germane that we can't keep up now, and we want to go faster?

<Fazio> git hub isn't the most user friendly app

greg: having materials in GitHub is like saying it's in Sanskrit… Github is incomprehensible to many, many people.

<Zakim> Chuck, you wanted to end conversation and move agenda

<Fazio> word!

<alastairc> JF - yes, if we don't progress on conformance etc, we can't close many of the issues.

<bruce_bailey> @gregg -- i was not asserting that a comment in GitHub counts as being responsive

<Ryladog> +1 to Gregg

JenniferS: it is also inaccessible for many vision considerations / screen reader users.

Jennie: my concern is about the accessibility of the CFC process for cognitive disabilities. the larger amount of text takes more effort to compare to what was originally there, and then create that vote.

<Fazio> agree with Jennie. I have a hard time with the process (as a TBI survivor)

Jennie: plus the memory of that discussion, conversation goes back & forth, we're relying on the individual voters' ability to review discussion and remember that conversation.

<Fazio> traumatic brain injury = TBI

<alastairc> Noting that nothing that goes to CFC would be new, it would have been agreed in meetings. Overall, the review needs to have happened prior to CFC.

Jennie: that's why I voted for the parts and the whole, is to have greater representation in the process.

<bruce_bailey> @gregg -- i just was looking for some public-facing evidence that your comments are recieved and appreciated -- because they are

WCAG 2.2 Accessible Authentication (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-accessibile-auth/

chuck: now focusing on WCAG 2.2 content, prior content to come up in future meeting.
... first survey: is on accessible authentication, issue 1902 about definition of common object.
... long discussion about cognitive function task, should be treated as an exception rather than current handling.
... to log in sometimes presents an insurmountable obstacle, particularly with the lack of accessible captcha alternatives.

there are 5 support a AAleve sc, … aaa does not allow for recognizing common objects.

David Macdonald: historically we tried to introduce SC that had a clear path to meet it.

Question 1 - Recognizing common objects path forward

David: it seems to me, the alternatives for captcha are pretty low. so I suggest dropping it, or opt for ones that are not mature.

Alistair Campbell: it think that's a bit unfair atm. like basic username and password is fine, 2fa with webauth and other methods is fine. the reason recognizing common object is an issue is…

Alistair: is that sometimes a user's IP address triggered this might be a bot, so might add a captcha to the typical auth methods. typical auth is captured in transcription.

<bruce_bailey> lol, which of these is a spiral galaxy -- good example

Alistair: some are captured in GitHub - some are simple, some are complex, and what if it's asking you to provide a picture you recognize to show you the next time you log in -- couple instances of slightly rare instances.
... coga task force disagreed with the last public review, where if it was something user provided or common objects, then accept these for feasibility

chuck: I was supportive of the AA level, and then AAA it does that… is it possible for us to do this in the time frame, and meet our goal of publishing by October or November?

Alistair: I think so, it's not a big change in terms of substance.
... adding the aaa is a variation on the aa, just takes away those exceptions.

<Zakim> bruce_bailey, you wanted to ask if we are addressing wcag2ict for 2.2 ?

Bruce: in response to meeting the timeline. I expected we would revisit the wcag to ICT work in time for 2.2 publication.

<Zakim> alastairc, you wanted to discuss wcag2ict discussion

Bruce: I think that's a bigger concern than this particular item.

Alistair: we've been trying to get a group going, but haven't been able to start that yet.

<Chuck> It's not a dependency, it was parallel work (or would have been)

Alistair: we never saw the ICT as a dependency, or same timeline.

Bruce: ok

<mbgower> +1 that wcag2ict is running out of runway

<Chuck> q Chuck

Chuck: scribe change?

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

<Rachael> scribe: rachael

<alastairc> WCAG2ICT was published 5 years after 2.0, we can probably improve on that.

<alastairc> https://github.com/w3c/wcag/issues/1902#issuecomment-907469906

david-macdonald: We proposed a AA. We don't have a AA. What are we proposing exactly?

Alastair: I assumed it was AA to start.

Rain: This is something we've been working on for quite a while. We've been trying to get the right langaage and investigating concerns of orgs as well. We should be able to propose something within a week or two. The AA / AAA split is a compromise stance from COGA.
... if we do not indicate that any object recognition is a cognitive function test, we are lying. The AA and AAA split allows us to make clear that if you are using the captcha technology in AA, maybe you are conforming but you are still leaving some users out. This approach makes that clear. Its in writing.

<Zakim> Rain, you wanted to quickly before I drop off

Rain: that is the goal. We don't have langauge in the SC that explains that if you are complying that you are still excluding someone. We understand some of the technology is not mature. I have taken this to colleagues across other tech companies and its because there is a perception that current captchas are accessible.

<kirkwood> That was clear

Rain: without the language in our SC, its not clear that the technology will mature.
... I am happy to follow up with the language if the group agrees to move forward.

Alastair: Step 1 is to get agreement to this bit and then we'd bring the langauge back.

GreggVan: ... I worry a lot about the cognitive items because for technical reasons they go AAA and then people dont' see them. Need higher visibility.

<Jennie> Apologies - have too drop. Have a good week.

<Chuck> Hi Mike, I am and you are up when the conversation comes to a close, or please queue up and discuss your response

<bruce_bailey> +1 to greggs comment that AA version of this is important

<alastairc> Yes, we can add note, just want to confirm approach of A/AAA first.

GreggVan: when we can't get AA, can we have something like a note that says on an AA level Note Cognitive tasks are hard to define but really a barrier, see AAA so that when you are only looking at AA, they can see it,

<garrison> dropping. Bye.

GreggVan: a lot of people would care if they could find out but they don't know.

Chuck: Since this conversation is ongoing, if you submitted a comment on survey please add to queueu

david-macdonald: So this proposal changes A to an AA that includes mature and AAA that references less mature options, and then we add a note along the lines of Gregg.

<alastairc> Exception: Two types of cognitive function tests are excepted from Level AA at this time:

<alastairc> - prompting the user to recognize common objects (examples: cars or tables),

<alastairc> - asking the user to recognize content, such as an image or a word, that they provided to the website.

Wilco: Are we saying that AA, that will exempt one type of captcha but not others?

<Zakim> Chuck, you wanted to read MG's comment

JF: I am concerned about what we do with this when we migrate. I remember 6-7 years ago at JP morgan chase. Found ourselves in a meeting wiht Accessibility on one side and Security on the other. We were arguing these types of cognitive barriers, were barriers. Concern was from a security perspective that these tests provide a gatekeeping mechanism that stops denial of service attacks. Security won because of the impact. We have to recognize

that there are other variables.

<Zakim> mbgower, you wanted to say I'm concerned about maturity of the SC

mbgower: I was the other who voted for removing this. I didn't have a choice I liked. COGA objects to exempting...

<david-macdonald> I could live with that.

mbgower: There is a maturity consideration. The understanding doesn't synch. Its not an authentication problem its a verification problem. Is one of the problems here that we need an SC that deals with CAPTCHA itself and not include the verification as part of the authentication.

<Zakim> alastairc, you wanted to comment on the security point and to comment on security point and source of object recognition

Alastair: Its worth remembering that the scenario is authentication not account creation. The reason this has been an issue is that even as a part of authentication, occassionally captchas are used to prevent abuse. There is another issue that Abbey raised. She's been working at a bank and we need to update understanding document. It is quite mature from the security point of view.

<Chuck> poll: Propose a AA level SC that allows for recognizing common objects and audio, plus an SC at AAA that does not allow for recognizing common objects.

Alastair: the object recognition wasn't introduced by the taskforce. I added it later to address issues brought here. That is why there is discussion from the taskforce.

<Zakim> Chuck, you wanted to propose a resolution

<mbgower> This is the wording in the doc right now: " Recognizing common objects, or a picture the user has provided, would not be a cognitive function test."

Chuck: Is it worth the effort to move forward with an AA and an AAA and then bring it back?

<JF> I could live with Chuck's suggestion

<Zakim> alastairc, you wanted to comment on separate SC

david-macdonald: Mike's suggestion. I want to discuss. The idea of an SC for captcha. If the two questions, what would be in that SC. Is it possible to do something like that? Is it too late in the process?

<mbgower> The normative definition of cognitive function test is here https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication#dfn-cognitive-function-test

alastairc: On the captcha, one reason we need to deal with this is that if a captcha comes up that requires a user recognize something and type it in, that is a cognitive function test.

Chuck: mbgower Are you still leaning towards removing?

mbgower: 3 options: Allow an AA that allows object recognition, move it to AAA which takes it out of scope, or to remove it.

<Zakim> Rachael, you wanted to clarify options

<Chuck> Rachael: Too clarify, from COGA the desire is to have A or AA that says you should not have a cognitive function test. The question is, how do we find a mid-range that meets their needs while still ...

<kirkwood> I am not a robot []

<Chuck> rachael: I proposed this split so that we didn't drop this. WCAG 3 will take a while, there may not be a wcag 2.3. Knowing this is an issue, I'd like to see something in 2.2 than not.

<Chuck> rachael: The solution of putting it in and reference in AAA would be acceptable. I don't think we will get through the exception process.

<mbgower> Hail Mary

david-macdonald: Speaking to Michael's concern about skeptical that it will happen. I think there are examples that we have been able to do this.

<alastairc> This almost got into 2.1, we were waiting for webauthn, which is now widely available.

<mbgower> Okay, I can live with the proposed AA.

<Chuck> proposed RESOLUTION: Propose a AA level SC that allows for recognizing common objects and audio, plus an SC at AAA that does not allow for recognizing common objects.

david-macdonald: we have lots of examples of AAA doing the ideal and AA doing the live with.

<kirkwood> +1

<StefanS> +1

<mbgower> +1

<david-macdonald> +1

<JakeAbma> +1

<ToddLibby> +1

<GreggVan> can we add the note?

<GreggVan> +1

<Chuck> +1

<laura> +1

<bruce_bailey> +1

david-macdonald: One last addiiton, that WCAG does change the industry as a result of WCAG. Rain's point is useful.

<JF> +.75 (with ongoing concerns about migrating this to WCAG 3)

<Wilco_> 0

<alastairc> +1

<GreggVan> great

<alastairc> Gregg - we haven't got the text yet!

<MelanieP> +1

<GreggVan> perfect

<mbgower> The note is non-normative

<david-macdonald> AA and AAA versions (AA would have a note that AAA is desirable)

<Zakim> Chuck, you wanted to address Greg

<Zakim> bruce_bailey, you wanted to check on audio v visual

<mbgower> Here is the wording of the survey: Create a AA level SC that allows for recognizing common objects and audio, plus an SC at AAA that does not allow for recognizing common objects

<Zakim> Chuck, you wanted to say which will come back and MAY pass

<Chuck> proposed RESOLUTION: to Create a AA level SC that allows for recognizing common objects and audio, plus an SC at AAA that does not allow for recognizing common objects

<Chuck> proposed RESOLUTION to propose a AA level SC that allows for recognizing common objects and audio, plus an SC at AAA that does not allow for recognizing common objects

RESOLUTION: to propose a AA level SC that allows for recognizing common ob

WCAG 2.2 Focus visible (Q1-3) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Chuck: Proposed, Michael Gower proposed editorial updates

Alastair: They have been made.

Chuck: Gundula said I still feel that the phrase "against adjacent colors in the focused component" is hard to understand. To which exact colors does it refer to? Only the colors of the UI element itself? Or also its background color (that is, the color next to it, usually the background of the page)? The latter allows the focus indicator to blend into the background, which should not be allowed. Blending into the focused component results in a

focus indication by size change, which was explained to be valid several times along the AGWG discussions. As some examples show round elements, I'd rather define 'unusual shape' as anything neither rectangular, nor rounded rectangle, nor circle, nor oval.

Question 1 - Google feedback

<Chuck> proposed RESOLUTION: Accept amended response to address issue 1896.

alastairc: Its a response to what the Dahlia had put as a question. In the feedback document she'd highlighted the background colors. As we discussed last week, we have to be really careful about what we mean by background. If someone can suggest SC text that is more clear, it would be welcome.

<mbgower> +1

<Chuck> +1

<JakeAbma> +1

<laura> +1

Chuck: This is getting very detailed in a non-normative response to a Github issue. I propose we accept the ammended response with Mbgowers ammendments

<jenniferS> +1

<ToddLibby> +1

Gregg: Question. You had asked about an alternate SC wording. Are we voting on the current SC language? Are we voting on moving forward?

alastairc: We've worked several years on this language so unless someone wants to suggest we will move forward.

<alastairc> https://github.com/w3c/wcag/issues/new

GreggVan: Where should one send alternative options?

alastairc: Creating an issue is possibly the easiest way.

GreggVan: Its easy to create an issue. Harder to figure out how all the issues relate, all that stuff.

alastairc: Type a suggestion out in a new issue and we will address it

RESOLUTION: Accept amended response to address issue 1896.

<GreggVan> whoseonthephone

<alastairc> https://www.w3.org/2001/12/zakim-irc-bot.html

- DRAFT -

AGWG Teleconference

14 Sep 2021

Attendees

Contents