<ChrisLoiselle> regrets second hour of meeting.

scribe+

Annoucements

<alastairc> TPAC registration https://www.w3.org/2025/11/TPAC/

alastairc: TPAC registration is open. Previous link.
... Before next meeting, half hour before normal start time we'll be running the new joiners onboarding meeting.

<alastairc> Path sub-groups https://www.w3.org/wbs/35422/Path_Participation_25b/

<Daniel> Deadline for discount is 23 August

alastairc: Taking all work of subgroups, working it into PRs, going through a couple of these today. Need to take a bit of a step back and plan the next few months of subgroup work
... Link to participation survey. Inputs group, you're on a slightly different track as we are aiming to get requirements though to review and documentation ASAP
... Safety is concluded, plain language discussing the options

<todd> Safety & Deception is completed, yes

alastairc: Remaining groups: we're looking to continue and cover off the rest of the requirements within these groups.

<alastairc> Conformance next steps https://docs.google.com/presentation/d/17VJvnm5UQW4WUzIoo9QNPVGfePgaZa8ifZWs-wtmv7E/edit?slide=id.p#slide=id.p and https://www.w3.org/TR/wcag-3.0-explainer/#conformance-models

alastairc: Comments are open for contribution on the group status
... Lots of content to work with, so now we need to look at conformance. Given content, discussions, etc. where do we take it from here
... The above is next week's discussion

Rachael: With conformance discussion, we won't discuss all of it, but will go over the plan to tackle it
... how to scope a claim

WCAG 2 issues https://lists.w3.org/Archives/Public/w3c-wai-gl/2025JulSep/0022.html

alastairc: WCAG 2 issues that are up for review.

<mbgower> https://github.com/orgs/w3c/projects/56

mbgower: Went out 2 weeks ago, but missed the reminder at the midpoint.
... [shares screen to show some proposed changes]
... [discusses a couple of points in these proposed changes, which can be found at the previously link]
... Folks can provide feedback by e-mail and the project folder.

Assertions merging https://github.com/w3c/wcag3/pull/342

alastairc: Hoping to merge into WCAG 3 draft.

<Rachael> PR files changed https://github.com/w3c/wcag3/pull/342/files

Rachael: A couple of changes have come up since last meeting. First is talking about conformance without a conformance claim. Request to make that more clear.
... Added statement about process being asserted. Had a good discussion about assertion generator, which has been changed.
... At this point, ready to merge and CFC

alastairc: Really helpful if people review things as we go along. Either way, this will be a fast-paced process

<kirkwood> +1 to process assertions

GreggVan: This language restricts assertions to process. This might be clearer for others to understand clearly.

Rachael: Originally proposed to handle these kinds of processes.

kirkwood: I want to +1 to using the terminology "process assertions". Think it's a great note.

GreggVan: Should we stop talking about assertions and start talking about process assertions.

<kirkwood> +1 to Gregg

alastairc: Good comments to add to PR

Glossary merging https://github.com/w3c/wcag3/pull/327

alastairc: Wanting to merge the definitions into the glossary

<Zakim> bbailey, you wanted to ask about view, sorry

bbailey: Question about view. Is this adding all to a list or just the last item of the list within the PR
... View in glossary. Does the key phrase about expansion describe the list before?

alastairc: So remove the comma?

bbailey: TLDR; yes.

alastairc: Any problems with changes?
... [shows how to add a suggestion in GitHub]
... [commits suggestion to affect changes]

<bbailey> Woot!

kenneth: Typically, the first word isn't capitalized. Most of the PR has capitals, but WCAG 2 isn't.

<stevef> hey sarahhorton

<Zakim> bbailey, you wanted to mention that sometime there is a second sentence

bbailey: Sometimes there's a second sentence and capitalization goes off.

<ChrisLoiselle> https://deploy-preview-342--wcag3.netlify.app/guidelines/#dfn-assertion

<Zakim> ChrisLoiselle, you wanted to comment on capitalization of Assertions vs. assertions

<ChrisLoiselle> https://deploy-preview-342--wcag3.netlify.app/guidelines/#conformance-0

ChrisLoiselle: Assertions requires a capital or not? Seems to be discrepancy.

<Zakim> Rachael, you wanted to say we haven't done editorial passes yet

Rachael: Have not yet done editorial pass. We will do editorial at a later time. Will be put to the group.

Scheduling Tradeoffs Discussion https://github.com/w3c/wcag3/discussions/343

alastairc: For next charter period, need to decide on top-level approach regarding publications. Had some discussion.
... What should next steps look like.
... [shares screen to show the GitHub issue summary from previous link]
... Does anyone have other outcomes we should be achieving that haven't been covered here?

LoriO: We have 2.2 people are using, then we come out with WCAG 3. How do we get them to realize that something has changed from 2.2 to 3 and they should consult 3 instead of 2.2?

alastairc: Process W3C specifies and one we've been through. We published a draft of it and then we send for review within W3C and the wider public. Plenty of people review the drafts and comment.

<Glenda> Glenda wants to add, deliver WCAG 3.0 incrementally so we can focus on delivering NEW important “success criteria” and/or “process assertions” sooner rather than later.

alastairc: for WCAG 3, if we were going for a wider approach, we would likely have a draft in a couple of years that would go for review.

LoriO: I'm looking at someone who works for x large company and is an accessibility tester. How will they know that SC 2.1.1 has changed from WCAG 2.2 to WCAG 3?

alastairc: Depends on a lot of things out of our control, but WCAG 2.2 won't be deprecated. Large companies need to set policy on what they're going to use etc.

GreggVan: When we say published can we published as draft or published as rec? Always confusing to see this.

<kirkwood> good point re: confusion publish rec/draft

<Glenda> Glenda changes her comment to: deliver WCAG 3.0 (Rec version) incrementally so we can focus on delivering NEW important “success criteria” and/or “process assertions” sooner rather than later.

Glenda: From Deque perspective, deliver WCAG 3.0 rec version incrementally.
... Trying to achieve creating more things industry can use to deliver accessible experiences, in my opinion

<Zakim> kevin, you wanted to respond to Lori

kevin: To Lori, any new features are available, such as when regulation incorporates new standard changes. We make announcements, outreach, etc. to raise awareness generally

<Zakim> Rachael, you wanted to say there are actually 3 options publish as draft, publish as rec, and publish as note

Rachael: We have different ways of publishing as outlined at the top of this issue [linked in title of this agendum].
... Drafts are easy to update. Recs are more set. Notes are not on the rec track and are on the note schedule. They are not things that get picked up as a regulatory option.

<Glenda> And even more refined: Glenda changes her comment to: deliver WCAG 3.x (Rec version) incrementally so we can focus on delivering NEW important “success criteria” and/or “process assertions” sooner rather than later. WCAG 3.x (Rec versions) wouldn’t focus on rewriting WCAG 2.x at this time…but could rely on WCAG 2.x at this stage). This is not just my opinion, thisi is Deque’s stance.

Glenda: It's rec version of 3. It's not just a note, not a draft.

GreggVan: On rec discussion, if published as rec and it's incomplete, the group can use this instead of the older version.

<Glenda> Glenda adds: WCAG 3.x rec (with a section that says AND all of WCAG 2.x A/AA).

<giacomo-petri> same

Glenda: needs to say "publish the new things sooner as rec" so that the changes will be picked up seriously. Impetus is for companies to use this.

alastairc: You want new things to be picked up by regulators and companies more quickly?

Glenda: They will not pick it up as necessary unless it's a rec

<kirkwood> +1 to Glenda

giacomo-petri: If we have requirements in WCAG 3 that are stricter than WCAG 2.x it shouldn't be a problem to pick up. If we have requirements that reduce the baseline, we should think about some way to mark some portion of SCs as obsolete.
... Maybe regulators will require 3.0 and some will require 2.x. Might be impossible to reach in a standard way

kevin: Was curious due to commentary and what they may or may not do. It's difficult to find a regulator. Reached out to some regulators and we have a few questions around approaches.
... If we went incremental, what would this imply for the regulator? Any regulatory updates coming in the next two to five years that would benefit from updates to WCAG? What would be required for them to adopt a new version of WCAG (rec or otherwise)?

<Glenda> @kevin can you share WHO you spoke with and what govs they are from? (countries)

kevin: Got a few responses and waiting on others. Some themes popped up: political context, timing and mechanism of adoption, importance of clear standards

<alastairc> Glenda - EU, US, UK.

kevin: State-level US may adopt new regulations depending on regulations (US)

<CarrieH> +present

kevin: Timing and mechanism. UK allows for fast adoption for use by their digital teams.
... Anything in EU requires changes to EN 301 549. Would take time.
... In US, slow to update as currently recommended level is 2.0
... Final item was less clear, importance of clear stable standards. Rec status is important for formal adoption.
... Without the above, may undermine ability to be used.
... If new recs address gaps, then their value may be increased and traction for implementation.

<bbailey> Learn about the (U.S.) regulatory process at: https://www.regulations.gov/learn

kevin: Will continue to garner responses, but currently will help us get a sense of the situation.

<Jennie_Delisi> kevin - if you need more to participate feel free to contact me re contacts for State of Minnesota.

GreggVan: EN 301 549 is under review. [Discusses process for review]. Last two updates. Without new law coming out, not sure money where will come to initiate review.

<Glenda> New York state law is already pointing at WCAG 2.2 https://www.tpgi.com/new-york-state-requirements-for-digital-accessibility/

GreggVan: EN 301 549 unlikely for number of years.

<bbailey> U.S. DOJ under ADA Title II (state and local government) cites to WCAG 2.1 (but 508 is stuck at 2.0 for the next few years)

GreggVan: Will only happen once, not incrementally. (EN 301 549)

<Wilco> Please note that while EU and US are "biggest bang for our buck" there are a lot of other places / organizations. Think Canada, Australia, India, Japan. Think policies of organizations with lots of tech. Federal governments, large banks, orgs like BBC.

<kirkwood> And NYC law pointing to 2.2

<kirkwood> can help too

<elguerrero> Glenda: Appreciate this research, is the person spoken to more focused on federal rather than state? US gov't or 508 only points to WCAG 2.0. Should contact people at NY state...

<elguerrero> kevin: Any misrepresentation is my misrepresentation. Just pulled a summary, trying to find a more global reflection.

scribe+ elguerrero

<Glenda> Please add https://convergeaccessibility.com/author/ken/ to your list of people to talk to.

<elguerrero> kevin: Backwards compatibility is the biggest issue, creates difficulties in picking up new regulation.

<elguerrero> maryjom: In some countries don't state versions, just pick up latest.

<elguerrero> maryjom: Some agencies pick up more recent versions of WCAG.

<Zakim> GreggVan, you wanted to say "just a quick note. since WCAG 2 series are backwards compatible -- a state can adopt a new version from another. But if they are not - they cannot

<elguerrero> maryjom: Regulations depend on the country, some slow to pick up, some follow the latest recs.

<elguerrero> GreggVan: We need to make standards that are backwards compatible that everyone can easily adopt.

<elguerrero> alastairc: Going through items in GitHub.

<elguerrero> https://github.com/w3c/wcag3/discussions/343

<alastairc> https://github.com/w3c/wcag3/discussions/343#discussioncomment-13923584

<elguerrero> alastairc: Question is: are there any other pluses or minuses for publishing new content versus in a rec track publication.

<elguerrero> alastairc: Question 3: What are the trade-offs with frequent, smaller rec tracks versus larger releases?

<elguerrero> alastairc: Incremental updates wouldn't be backwards compatible.

<elguerrero> alastairc: Smaller changes means less feedback, fewer objections.

<elguerrero> Glenda: Question on Point 2: are notes normative?

<elguerrero> alastairc: No

<elguerrero> Glenda: I need that clarified.

<elguerrero> alastairc: Edits the GitHub discussion to add Glenda's comment.

<elguerrero> Glenda: Note is not normative, a rec track is-- this is a trade off.

<Jennie_Delisi> +1 to Glenda, because of how it will be not implemented if not a "requirement" by some

<elguerrero> GreggVan: The goal of publishing it in little b its is that it can be used, but used for what? Replace WCAG 2?

<elguerrero> Rachael: On Glenda's point, pros of normative is that change is often and more likely to be picked up by regulation, I think. Cons are it's harder to change from our points of view. It's also longer to put out. We are all struggling with a set of assumptions, we have things outside of control so we have to guess what the regulators are doing.

<elguerrero> Rachael: If we have a small subset of new content and reference WCAG 2 and call it WCAG 3, is that more likely to be picked up by regulators than a note that's just sitting there?

<elguerrero> Rachael: We don't control the regulatory and adoption space so we have to guess and make assumptions.

<elguerrero> Rachael: Call out that normative vs. non-normative is not the trade-off space, it's the next step from down there.

<Zakim> alastairc, you wanted to comment on Gregg's question

<elguerrero> alastairc: To GreggVan's question: what incremental bits mean-- I don't understand how it would work myself.

<elguerrero> alastairc: Some bits would be added to the rest of WCAG 2 content, there would need to be updates to conformance model.

<elguerrero> alastairc: That's backwards incompatible because it changes what passes/fails, e.g. colour contrast.

<elguerrero> alastairc: Big thing is I don't understand how any of those increments could be backwards compatible.

<elguerrero> alastairc: Would have to do it every time the increment updates.

<elguerrero> alastairc: Biased that it feels suffocating if you can't adjust the other parts, every single requirement will set you back to where you were in the beginning, every time you add something new, you'll have to fit it in with what's currently there.

<Zakim> bbailey, you wanted to ask why WCAG-EM published as W3C WG Note instead of W3C Recommendation ?

<Zakim> Jennie_Delisi, you wanted to talk about the cost of adoption

<elguerrero> bbailey: Why are some things published as a Working Group Note and others published as Recommendation?

<Jennie_Delisi> Cost of normative adoption (user path): Consider impact, plan for adoption, get adoption approved, effective start date, education to use, update processes and related resources...

<elguerrero> Jennie_Delisi: Reaction to what Glenda and Rachael are talking about-- identify the cost of normative adoption as the actual user path to consider.

<elguerrero> Jennie_Delisi: Consider the impact to users and planning for adoption, getting it approved, having a start date, and educating all involved.

<elguerrero> Jennie_Delisi: That may be why they're hesitant to adopt non-normative elements.

<elguerrero> Glenda: It's taking too long for us to help people with disabilities to have more access. If WCAG 3.0 rec version normative did nothing but add process assertions, pull forward WCAG 2.2 and introduce a new compliance model.

<elguerrero> Glenda: Allows us to clean up for 3.1

<Zakim> alastairc, you wanted to make a hidde point - WCAG-EM and to comment on pulling WCAG2 content into 3, and how that prevent improvements

<elguerrero> Glenda: Rewriting WCAG 2.0 takes up a lot of energy.

<elguerrero> alastairc: Sometimes governments use notes as a basis for how their public sector websites are tested. People aren't forced to use them, but sometimes do.

<kirkwood> + COGA

<elguerrero> alastairc: If we take forward WCAG 2 content, we're taking forward the WCAG 2 structure. Can't see how to improve the structure, how you use the old content in a new structure with a new conformance model.

<elguerrero> GreggVan: On notes: what does it mean for something to be rec track? Means you conform to it, released something sufficient but not required. Testing doesn't make a product more accessible.

<elguerrero> GreggVan: Tests aren't normative.

<elguerrero> GreggVan: Don't have to test that way, just provide ways to test and what is considered sufficient.

<elguerrero> GreggVan: If they don't adopt it as a required way to test, it can just be a note to say how to test in a particular way without it being a rec track.

<Zakim> Rachael, you wanted to ask if we did that how we would handle AAA and coga

<elguerrero> Rachael: Chair hat on, Glenda, based on where we are with conformance model, we'd add assertions and processes. If we get to 3.1 and it has to be backwards compatible, how do we not lock in the AAA as supplemental?

<elguerrero> Rachael: Trying to figure out backwards compatibility between 3.1 and 3.0 without locking out high priority content.

<elguerrero> Glenda: We've got a lot of stuff in 1.3.1 in WCAG 2 and if we pull it forward to WCAG 4, we lose flexibility. We should add assertions and back off 100% conformance model.

<elguerrero> kevin: Does that mean all these SC are no longer required and no longer required to be compliant?

<elguerrero> Glenda: If you have one issue, you're non-conformant.

<elguerrero> kevin: If we back off and say 100% conformance, there are some bits you can let go of, are we not watering down things?

<elguerrero> Glenda: Not saying it to be perfect but tell me how well you're doing.

<Zakim> Rachael, you wanted to say correct on how it might fit in conformance

<elguerrero> Glenda: Instead of just failing.

<elguerrero> Rachael: Less concerned with conformance, encourages adoption of some percentage of AA and some of AAA.

<elguerrero> Rachael: Concerned about COGA and low vision support.

<elguerrero> Rachael: Tried to do ratings against disabilities in the first draft and approached it differently.

<elguerrero> GreggVan: Rating by disability gets into which disabilities are more important, anything that's programmatically determined means software can get at it.

<kirkwood> disdability lanes is difficult. do we depend on lobbying or disability specific laws?

<elguerrero> GreggVan: There are some things that are critical and some that are helpful. Need to figure out whether or not a provision is worth more than another.

<kirkwood> +1 to Gregg

<elguerrero> GreggVan: Should be up to regulators to say whether something is accessible. We're just trying to say what is and what isn't accessible.

<kevin> +1 to Gregg's point

<Zakim> alastairc, you wanted to ask how that works with WCAG 2 content?

<kirkwood> ruler not the rule

<elguerrero> alastairc: I don't see how we can change conformance model without changing WCAG 2 criteria.

<elguerrero> alastairc: To be more encouraging, we have a split between foundational and supplemental, to get more nuance.

<elguerrero> alastairc: We want to produce a note to regulators on how to adopt WCAG 3.0 to help companies in scoping.

<elguerrero> alastairc: Every time we update a chunk that is going to cascade outside of that chunk, and even if it doesn't, within that chunk, it will change requirements and is not backwards compatible.

<alastairc> https://github.com/w3c/wcag3/discussions/343

<elguerrero> alastairc: Please add comments or suggestions to the above link.

<elguerrero> alastairc: No more meetings, will now wrap up.

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/We're just guessing and make assumptions./We don't control the regulatory and adoption space so we have to guess and make assumptions./
Succeeded: s/Why are some things just a working group note and some are published/Why are some things published as a Working Group Note and others published as Recommendation/
Default Present: alastairc, Jennie_Delisi, filippo-zorzi, joryc, tiffanyburtin, kevin, Adam_Page, ChrisLoiselle, Daniel, julierawe, Azlan, Laura_Carlson, Chuck, LenB, ShawnT, Kathy, kenneth, Rain, Makoto, graham, Jon_avila, Francis_Storr, jtoles, Glenda, GreggVan, Rachael, kirkwood, Wilco, giacomo-petri, Frankie, Kimberly, mike_beganyi, mbgower, bbailey, AlinaV, todd, Roland, LTSzivos, Jen_G, mfairchild, Detlev, elguerrero, stevef, sarahhorton, present, CarrieH, maryjom, COGA
Present: alastairc, Jennie_Delisi, filippo-zorzi, joryc, tiffanyburtin, kevin, Adam_Page, ChrisLoiselle, Daniel, julierawe, Azlan, Laura_Carlson, Chuck, LenB, ShawnT, Kathy, kenneth, Rain, Makoto, graham, Jon_avila, Francis_Storr, jtoles, Glenda, GreggVan, Rachael, kirkwood, Wilco, giacomo-petri, Frankie, Kimberly, mike_beganyi, mbgower, bbailey, AlinaV, todd, Roland, LTSzivos, Jen_G, mfairchild, Detlev, elguerrero, stevef, sarahhorton, present, CarrieH, maryjom, COGA
Regrets: RainM, TiffanyB, Azlan, LauraC, JenniferS
No ScribeNick specified.  Guessing ScribeNick: mike_beganyi
Inferring Scribes: mike_beganyi

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


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

People with action items: 

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