W3C

- DRAFT -

AGWG Teleconference

24 Jun 2025

Attendees

Present
tiffanyburtin, Wilco, ChrisLoiselle, mbgower, bbailey, shadi, kevin, julierawe, AlinaV, Jennie_Delisi, alastairc, BrianE, Rain, kenneth, filippo-zorzi, Jon_Avila, Roland, Azlan, Makoto, Rachael, todd, maryjom, ShawnT, Francis_Storr, giacomo-petri, Laura_Carlson, Poornima, Glenda, mfairchild, present, Frankie, kirkwood, JenStrickland, LoriO, LenB, rashmi, GN, Kimberly, Graham, GreggVan, wendyreid, Adam_Page, hdv, Detlev, jtoles, mike_beganyi, JenStrickland5, JenStrickland1
Regrets
Chair
alastairc
Scribe
Chuck

Contents


<hdv> scribe=

<hdv> scribe+

Announcements

<hdv> alastairc: if anyone would like to intro or announce a change of affiliation?

<hdv> Chuck: we frequently get individuals who are new… at the first AGWG meeting every month, we host an onboarding session. It's 30 mins before this call

<hdv> Chuck: anyone should feel free to join that

<hdv> Adam_Page: I am new to the group, glad to be here. I am an invited expert, I'm also in the ARIAWG, and APG taskforce, and work for Hilton

<Zakim> Chuck, you wanted to ask Adam about IRC

ACT rules for review

<hdv> alastairc: we have a couple of ACT rules for review. As far as I'm aware we didn't have open comments on them yesterday, will open

<alastairc> https://github.com/w3c/wcag-act-rules/pull/346

<alastairc> https://github.com/w3c/wcag-act-rules/pull/335

<hdv> alastairc: they either don't have comments or resolved comments on them. Please take the chance to review, if you have comments please add them. We'll consider them approved by the end of the week

<hdv> alastairc: this is non normative guidance

<hdv> alastairc: an update to the specification is coming soon too

Scheduling Approach Alternatives https://github.com/w3c/wcag3/discussions/322

<hdv> alastairc: after last time's discussion we have some alternatives

<hdv> alastairc: last week, we looked at Option 1, taking a broad appoach, foundational first, supplemental later. Option 2 is taking a narrower set of requirements, similar to WCAG 2, then publish that before adding more requirements

<hdv> alastairc: then in Option 3, I thought it was starting with WCAG 2… but taking WCAG 3 content

<hdv> GreggVan: we're not talking about normal periodic publishing of draft, we're talking about publishing as a replacement standard, external review, and continuing to add things etc,that's what we're talking about, right?

<hdv> alastairc: in option 1 + 2 we'd have 2 charter periods until publishing… in option 3 we'd do it during first charter period

<hdv> GreggVan: so we're doing formal publication of a 'house for sale' even if it is not done? what is the purpose of doing that vs publishing as we go along?

<hdv> GreggVan: we're instead talking about publishing a full new standard that could be adopted

<hdv> alastairc: there's some differences between them

<hdv> Rachael: options 1 and 2 have drafts in between

<hdv> Rachael: option 1 is a the top [of slide showing on screen]

<hdv> Rachael: option 2 focuses on publishing wcag 3-version of waht's in wcag 2.2 up to aaa first

<kirkwood> link to presentation?

https://docs.google.com/presentation/d/1vwD1uJOB1mpduOJ3wdCnEovW5tRZolIVgIJC0FGXwOQ/edit?slide=id.g33d3c639021_2_25#slide=id.g33d3c639021_2_25

<hdv> Rachael: not sure if we could [ sound broke up ]

<hdv> GreggVan: since we publish working draft all through the process, what's the perceived value of doing something beyond working draft?

<Zakim> Chuck, you wanted to recommend that we assume everyone's best intentions.

<hdv> Chuck: recommendation from the chairs… we're made up of a diverse group from around the world… big and small groups, advocacy groups… please everyone keep in mind everyone's best intentions as we have this conversation. We want to serve all of our needs

<hdv> Chuck: we hope everyone assumes best intentions

<hdv> LoriO: I'm a little confused, I see a lot of options and publishing schedules, but none that I feel would help my users.

<hdv> LoriO: how can we keep people up to date?

<hdv> alastairc: we had additional options; an option 4 would be 'topic based', we're working through WCAG 2 content like in option 2, but the _way_ we would do it is topic-by-topic

<LoriO> thank you Alastair! This is exactly what I was looking for.

<hdv> alastairc: in option 5, we could look at rewriting WCAG 2 into WCAG 3 format

<hdv> alastairc: still mostly keeping with the WCAG 2 process, but being much stricter if things are equivalent to WCAG 2

<hdv> alastairc: in this slide you can see a comparison between option 2 (WCAG 3 narrower scope) and option 5 (WCAG 2.2 into WCAG 3 format)

<Rachael> github thread https://github.com/w3c/wcag3/discussions/322

<hdv> alastairc: then in a later phase of option 2 we would focus on informative documentation for phase 1

<hdv> alastairc: to summarise, we have option 1, wcag 3-broad, broad as in broad coverage, but realistically we would not be able to do all of that, and do supplemental and assertions later

<hdv> alastairc: then we have WCAG3-Narrower, which starts with comparable to WCAG 2.2 AAA and moves additional requirements and assertions to later

<hdv> alastairc: option 3 was WCAG2-Narrower, is to have the WCAG 3 structure but keep the WCAG 2 content and only write new content where we don't have it in WCAG 2. It would have more frequent publication, and not be backwards compatible like we had it in WCAG 2.

<hdv> alastairc: (backwards compatible as in passing latest WCAG 2 you'd pass all previous version)

<hdv> alastairc: the new ones from last week are WCAG3-Topical and WCAG2-Migration

<Zakim> Chuck, you wanted to address our goals for frequent publications

<hdv> shadi: thanks for the overview… and thanks for reminder re assuming good faith

<hdv> shadi: Gregg was asking some clarification questions… what I'm hearing is different ways of organising the work. One aspect is 'wait until the entire house is fully built and all the light bulbs are in etc', or alternatively, focus on part by part, eg start with the kitchen. Alastair, I think you mentioned it would cause some overhead.

<hdv> shadi: but I think that piece-by-piece-approach would be great because it would allow us to keep up with latest changes in technology and best for our users

<hdv> shadi: and would avoid building a house that ends up being one that we didn't want

<hdv> wendyreid: last year we did a publication sub group where we talked about, and one thing that came out of it, even if it wasn't our final recommendation, was that modules would be the most effective

<hdv> wendyreid: we should also realise that people are not going to, as soon as we publish, immediately embrace it completely

<hdv> wendyreid: we should not be afraid to publish things incrementally and iteratively. That also gives us opportunity to get feedback and information

<hdv> wendyreid: we're also getting ourselves caught up in W3C's publishing process, ie the process to get to Recommendation. The general public might not care as much about a document being in Rec status

<hdv> wendyreid: in general, as long as we communicate clearly about the document, we should probably not get too hung up on the final rec date, if we could get things out faster, in terms of functional requirements people can work with

<hdv> wendyreid: re backwards compatability… we can probably receive at least a _degree_ of backwards compat that would give people some confidence

<hdv> GreggVan: excellent comments from wendyreid

<hdv> GreggVan: when we talk about 'using it', I want to ask 'using it how?'

<hdv> GreggVan: the only usage of having rec status is @@@, or if you want to use it legally, eg to satisfy some regulation or requirement you have

<hdv> GreggVan: we need to think about how we want to plan and use this

<hdv> GreggVan: legal adoption, for like an ETSI standard, like EN 301 549… the cycle for that is 3-5 years

<hdv> GreggVan: and it has to be funded. The last two were faster because new laws in Europe were passed.

<LoriO> +1 for Wendy

<hdv> GreggVan: finally… re the house analogy… it's like building a new house, we're not talking about remodeling an old house, we're talking about a new house, eg building a kitchen without building the rest of the house. Which makes no sense.

<Zakim> mbgower, you wanted to say with Option 3, is it better thought as additive to WCAG 2 or _incorporating_ WCAG 2?

<hdv> mbgower: re the rec: can you clarify, a lot of parts in the slide we're looking at, what is 'pub', is that rec publication?

<hdv> alastairc: yes

<hdv> mbgower: another question, for Wilco or others who can speak to option 3… is it additive to WCAG 2 or to incorporate WCAG 2?

<Zakim> Jennie_Delisi, you wanted to discuss potential impact of timelines re government information

<hdv> Jennie_Delisi: I have a concern with two sides… first, as a COGA TF member, the assertions and other ways to address cognitive needs, I see those as alligning with those publication dates, they are really important, so that's the area I lean towards as a COGA TF member

<hdv> Jennie_Delisi: my second concern… if we're looking at publishing in >2030, if we consider government entities have to review, plan adoption date and have an effective date, even if one year was taken for that (which would be quite efficient), that could mean no adoption until 2035, which means 7 years after first publication dates.

<kirkwood> good point

<Zakim> ChrisLoiselle, you wanted to comment on topics

<hdv> Jennie_Delisi: these concerns make it hard to vote on the timelines

<hdv> ChrisLoiselle: Q re topics… when we want someone in the industry to go to WCAG 3… if we look at topical in the organisation and progressively iterating… in the current draft I see a bunch of things in progress

<julierawe> +1 to Jennie_Delisi comments

<hdv> ChrisLoiselle: for some I see a user goal but all user goals we have in mind

<alastairc> q/

<hdv> alastairc: intent is to have multiple ways of consuming it, each requirement could be categorised in multiple ways. The topical is more how we work on it, not how it is presented to users

<hdv> Wilco: I'll try to answer Mike's question. The way I think about option 3, is that we take the parts of WCAG 3 that we think have the highest impact. With some assertions we could look at the conformance challenges, think about the things we can address in the next charter

<hdv> Wilco: alongside that we take the WCAG 2 content, that isn't superceded by the new content, so that we can publish a full spec

<hdv> Wilco: that way, we have a part of WCAG 3 that is new content and a part that consists of old WCAG 2 content. That way we could have a full spec by the end of the next charter

<hdv> GreggVan: I want to second Jennie's comment. I don't like any of the timelines, they're frustrating.

<hdv> GreggVan: if comparing this to making software, we're basically doing a complete rewrite of the code. And backporting new features to old architecture.

<hdv> GreggVan: I don't know… is there something we could do while we're working on 3, I don't know how you can ship a new boat until all pieces are together

<hdv> GreggVan: there are some provisions in WCAG 2 that have to do with new technologies, eg contrast, there are new colour spaces etc

<hdv> GreggVan: we could make a 2.3 or add an annex, in which we can deal with such things

<hdv> GreggVan: as kind of a backfill

<hdv> alastairc: there are some things, like the color contrast algorithm update, that we could hand to the WCAG 2 taskforce to add or potentially publish it as WCAG 2.3. We can do it, but we have to be quite specific about it

<hdv> alastairc: chair-hat-off, as a member of the group who has been thinking about this too much… I second Jennie and think all options are bad and too long of a timeline… I don't feel great about the timeline of option 1 as a lot of the benefit is in supplemental and assertions and it's last

<Jennie_Delisi> * Please note I did not say hate. I appreciate the reason why the options have been presented as such.

<Jennie_Delisi> * I just find it extremely difficult to choose because of their implications/impact.

<hdv> alastairc: in the subgroups we've been breaking things down

<hdv> alastairc: what worries me about the incremental approach is the cascade effect. IF you update assertions we have to update the conformance model

<hdv> alastairc: you could make all assertions AAA but that's not how AAA was meant… we could add new definitions that then cascade to existing criteria etc

<hdv> alastairc: to me that seems like more work in some ways, you have to go find all cascade effects before every publication

<hdv> alastairc: we also work in parallel so would be hard to work on feature on feature

<hdv> alastairc: re WCAG2-Migration, it's a good way to restrict scope. Restructuring means rewriting, I think we'd end up at option 2

<hdv> wendyreid: in the modular / topical approach, you were going to have to, as modules start to eventually venndiagram their way, you have to continually update and fix

<hdv> wendyreid: a lot of editorial oversight would be necessary

<hdv> wendyreid: I don't think it's impossible, and I don't think there's a reason we shouldn't try it… maybe some tooling can help. The other part of the conversation we're missing, we have been working in parallel and because we're scattered, it's really hard to keep up with what others are doing

<hdv> wendyreid: and then we end up with differences that need to be reconcilled somehow

<hdv> wendyreid: would like us to try the sequential approach and focus on specific areas. Parallelising has made it really challenging to know where things are at. Having a one track mind and modularising can help us really focus, get them out, test them, get feedback and then iterate based on the feedback

<hdv> +1 to wendyreid!

<hdv> LoriO: thanks wendyreid, she brought some really good points.

<Wilco> +1 Wendy

<hdv> LoriO: let's say we do by topic… nobody has mentioned the fact that hte way we're thinking about putting together WCAG 3.0, what's going to happen when they look at WCAG guidelines and they are completely different between how they are formatted in 2 and 3? isn't that going to cause a lot of anxiety for people and confuse them?

<hdv> LoriO: I really like the idea of tackling topic by topic, but that's a simple difference people would see, but would be jarring to look at guidelines and differences beween them

<hdv> GreggVan: re color contrast… well, actually it's about contrast not color contrast

<hdv> GreggVan: if we take the most important additional information… AAA can be used as informative, there may be other things… there is stuff in AAA that's not nearly as important as some of the stuff we're talking about bringing to 3

<ChrisLoiselle> partial regrets at top of hour as well.

<Zakim> Rachael, you wanted to say that notes meet the needs as I understand them.

<Rachael> Rachael: ::chair hat off:: As we’ve talked over the past year or so about what is most important, we repeatedly identify a few key areas: contrast algorithms, assertions, and policy adoption. I struggle to see the benefit of publishing the full spec to get these out to the public instead of publishing them as notes. Notes allow us to get feedback, allow companies to work with the content knowing we will be integrating it, and does not have

<Rachael> the same publication and use burden that partial full standards have. Notes do not lock us in or cause the background compatibility issue. Can someone explain the benefit of modules over notes?

<Zakim> alastairc, you wanted to say that in the Venn-diagram overlaps, it's easier to deal with those pre-publication. and to also say that there is a danger with creating a module that

<hdv> alastairc: when Venn-diagram overlaps, I've already found in a subgroup that when you have an issue you fix them in the module you work on first

<hdv> alastairc: it's much easier to deal with those pre-publication, as soon as you publish and do it normatively, we're kind of locked into that

<hdv> alastairc: +1 to Rachael's suggestion

<Zakim> Chuck, you wanted to advocate for the retrospective

<hdv> Chuck: we're also welcome to hearing any concerns re approaches we take

<wendyreid> +1 to Rachael's idea, I like notes first

<hdv> Chuck: the retrospectives can be used for concerns too

<scribe> scribe: Chuck

JenStrickland: Boosting what Jennie was talking about. A concern I have Gregg about porting WCAG 2.2 AA to 3. It's relatively easier, and then to pick up what is important next.
... Who defines what is important? To date, cognitive (in quotes, lots is lumped in), they are in AAA, but the impact is quite dramatic.
... Speaking from US perspective, of the individuals who go to war, the statistics are that many people come back with cognitive issues.
... I don't think it is my place to assert what is important, but we should be aware that cognitive has not been addressed clearly with standards and guidelines, therefore it becomes something that is growing and left out of the guidelines we deliver.
... This group hasn't been up to date on the evolving cognitive needs. I would hate for cognitive to end up in AAA again. Particularly if it is not as easily automated.

alastairc: Cognitive requirements have been underepresented, but has also take a great deal of time to try and address.

Shadi: I agree with Jenn. Want to come back to a point the chairs have been asking what the benefits... the publication has overhead. Sometimes chairs have answered as chairs and as members. Yes there is overhead, but scrutiny and validation as well.
... Yes our org does look at that. It's different whether it is a note or a rec, and how much we invest.

Gregg: Clarification... Option 7, covering all of AA and cover more important. I didn't mean in chronological order. I meant in parallel. All of the important stuff that we can get done before we decide to publish that is not in AA, plus the AA, so that it can replace 2.0. And anything else around conformance. That's the first that can go

out the door.

Gregg: The only other comment is, we have done the study, there are more provisions that focus on cognitive than any other disability. The issue is that cognitive is broader and harder to find that are testable. We've spent more time, and cognitive least well covered. Not because of lack of care, it's just a difficult challenge.

alastairc: Need to get to a decision point. We've got close variations. Do we try to use wcag 2 content and add wcag 3 content? Gregg raised porting wcag 2 into current wcag 3. I hope it is as easy as Gregg is saying (Gregg - easier), but that helps with structuring problem.
... If we carried on with our current WCAG 3 approach...
... Where do we aim to get to for the next rec? I don't know that porting... I'm skeptical that we can we can include assertions, there's a structure problem that may take more than the next charter.
... Do we try and use WCAG 2 content in a WCAG 3 structure, to try and get something to rec in the next charter period? Or do we carry on with our current approach, to get a WCAG 2 equivalent to rec in 2 charter periods?

rachael: We have a WCAG 3 and fill in gaps with WCAG 2, which is different from A.

shadi: You mentioned that its 2 charters without assertions, but it is 3 charter periods.

alastairc: Yes, would have been longer to get to the supplemental into assertions. The other 3 options we are trying to keep the scope equivalent to WCAG 2.

shadi: Option 2 would be equivalent to WCAG 2 AA?

alastairc: Equivalent but not the same. In terms of requirements similar to WCAG 2, including coverage.

Shadi: 3rd charter would include AAA?

alastairc: The first one doesn't get us to assertions. I sense most would not like that. The migration approach would be strictest on scope.

<kirkwood> Since the more than 9% of the U.S. population has a cognitive disability (US FCC.gov) we should realize the importance.

Rachael: AAA gets pulled in, so we might as well address it so we don't get surprised later on.

alastairc: Most likely covered in assertions. We have option A: get as far as we can in a single charter period. Option b: 2 charter period gets us to something equivalent and new.

JenStrickland1: Holding our feet to the fire, that we include X number of cognitive in what we deliver, and not be optional, just to ensure we meet those needs.

Gregg: Option 7 is same as option 2, instead of limiting to AA, instead of constricting what is in AAA. Not fencing us into AAA but allowing us to go outside of that.
... We do them if they are more important than some of the AAA.

alastairc: I hope I've been clear that option 2 is equivalent but not the same.
... We have our one charter period, we have 2 charter period options, and 3 charter period option. A, B or C.

<Rachael> A - One charter period: Use WCAG 3 content and fills gaps with WCAG 2 content

<Graham> A

<Rachael> B - Two charter period: If not, what is the scope we aim for to start with?

<kirkwood> +1

<Rachael> C - Three charter period: Option 1: Broad scope, but focuses on foundational first, then supplemental and requirements.

<Wilco> A

<todd> A

<kirkwood> agree with Jory

Jory: The options where we port WCAG 2 content to a WCAG 3 model can happen a lot faster if we use AI. We could get 75% there if we trained that on WCAG 3 structure. We wouldn't have to lose any AAA options.

<JenStrickland1> Shadi votes A

<Wilco> +1 Jory, we should at least try that

Jory: It would also produce content that AI could consume. Testing is moving that way. If we can feed our guidelines into AI we will be doing better. This doesn't have to be a strictly human effort.

<kirkwood> +1

Jory: I understand the concerns, but I think it can be done.

<JenStrickland1> A

<BrianE> A

<Rachael> B

<alastairc> B

<mike_beganyi2> A

alastairc: Happy to try, concerned it won't speed us up.

<Jennie_Delisi> Not sure.

<Azlan> A

<giacomo-petri> A

<filippo-zorzi> B

B

<mbgower> I'm keen to get something published in the first charter period. But it's the details that are gonna kill us.

<Makoto> A

<joryc> B (but I think it will be faster than we think)

<Rachael> Revision: B plus Notes

<Glenda> A

11, 6, 1

<mbgower> A, with caution

<Frankie> A

<Laura_Carlson> A

<Francis_Storr> b

<kirkwood> A

<GreggVan> b

15, 8, 1

<Wilco> -1 Gregg, that's false

<kirkwood> that doesn’t sound good

<JenStrickland1> That’s not how I understand it for A. For A I see WCAG 3 content that would include cognitive.

Gregg: We would lose adding cognitive.

Alastair: Are you refering to the guideline?

Gregg: Publishing half at a time?

alastairc: could be importing WCAG 2 as foundational requirements, AND working on assertions.

Gregg: A complete 2.2 port plus new stuff. That's what's in B.

<julierawe> I am still confused about what the different options mean.

Rachael: publishing half the time. Just because it's one charter period, it doesn't mean that we complete in a single charter period. Just more publications.

Gregg: Publications as recs?
... It cannot replace 2, it's replacing pieces of the house?

mbgower: There has been strong indication that people want to get done in a single charter period. Now we have to figure out what that looks like. There is already 2 scenarios for one charter period, but we'll have to figure out what that means.

<Glenda> (A) WCAG 2.2 moves wholesale (copy paste)…no initial changes into this thing called WCAG 3. Then add some assertions…and adjust a handful of SC. This is a complete house.

Kevin: I want to highlight that in order to get to a decision, we need to meet consensus. We have a strong indication to explore A further, but if there are strong views we need to explore that. The final approach in the charter will still need consensus.

Rachael: I wonder, if we were all clear on what we were voting on. I thought that porting was part of option B not option A. Would it be better to offer in a survey?

<kirkwood> yes!

<Glenda> +1 to survey Rachael :)

<tiffanyburtin> Yes please

<BrianE> +1

<Frankie> +1 to a survey

alastairc: Good idea.

<kirkwood> +1

wilco: To reiterate Mike's point. There is a clear direction, maybe we refine the ideas for another look.

Alastair: OK. We do have subgroup rooms.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2025/06/24 16:27:10 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/alastc/alastairc/
Succeeded: s/backfil/backfill/
Succeeded: s/feedback/concerns/
Default Present: tiffanyburtin, Wilco, ChrisLoiselle, mbgower, bbailey, shadi, kevin, julierawe, AlinaV, Jennie_Delisi, alastairc, BrianE, Rain, kenneth, filippo-zorzi, Jon_Avila, Roland, Azlan, Makoto, Rachael, todd, maryjom, ShawnT, Francis_Storr, giacomo-petri, Laura_Carlson, Poornima, Glenda, mfairchild, present, Frankie, kirkwood, JenStrickland, LoriO, LenB, rashmi, GN, Kimberly, Graham, GreggVan, wendyreid, Adam_Page, hdv, Detlev, jtoles, mike_beganyi
Present: tiffanyburtin, Wilco, ChrisLoiselle, mbgower, bbailey, shadi, kevin, julierawe, AlinaV, Jennie_Delisi, alastairc, BrianE, Rain, kenneth, filippo-zorzi, Jon_Avila, Roland, Azlan, Makoto, Rachael, todd, maryjom, ShawnT, Francis_Storr, giacomo-petri, Laura_Carlson, Poornima, Glenda, mfairchild, present, Frankie, kirkwood, JenStrickland, LoriO, LenB, rashmi, GN, Kimberly, Graham, GreggVan, wendyreid, Adam_Page, hdv, Detlev, jtoles, mike_beganyi, JenStrickland5, JenStrickland1
Found Scribe: Chuck
Inferring ScribeNick: Chuck

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]