Meeting minutes
Chuck: Strarting with housekeeping, introductions
<Chuck> Welcome Alex!
Alex Dunn introduces themselves
<Frankie> I have a new role
Chuck: Moving on to announcements. Next week we'll be hosting new member onboarding, on the same zoom channel, 30 minutes before the main meeting
Rachael: several of us will be at AccessU, I will be leading a session, please stop by and say hi
kevin: we will have office hours at accessU, this may include ad hoc usability testing, come by and say hi.
<Chuck> Welcome Michael!
<mike_beganyi> Welcome!
michael_fairchild: introduces self, I'm a TPM at Microsoft.
<ChrisLoiselle> https://
ChrisLoiselle: We are looking for active members to join our task force for WCAG2ICT
Chuck: The task force needs more participation especially if it is going to get into AAA criteria.
<ChrisLoiselle> Thanks, Chuck!
WCAG 2 issues review https://lists.w3.org/Archives/Public/w3c-wai-gl/2025AprJun/0019.html
Chuck: Item 1, WCAG2 issues review.
<mbgower> https://
<bbailey> You will need to authenticate to view project board
<bbailey> https://
<alastairc> This is the style change issue: w3c/
mbgower: pasted link into GitHub project link for backlog. We put out a 2 week review call for reviewing issues for approval. There are a couple items of items marked as substantive, the rest are editorial. #4276 is changing the presentation of some figcaptions, to make it more clear when the caption begins, this is re-styling this.
<alastairc> Here are the links to all the issues/changes up for review: https://
mbgower: The column for items to review in the project board is labeled "Sent for WG Approval". The issues are labeled based on their size and complexity
<bbailey> preview links are available from Pull Request
mbgower: looking at an update to the non-text contrast understanding page showing the style changes to the figcaptions
<julierawe> Thanks, mbgower
mbgower: we have one more week for comments, if you support it give the main comment a thumbs up, otherwise add comments with concerns.
<alastairc> https://
Frankie: I started a new role with the Seatle Cultural Accessibility consortium for live captions
Schedule check in https://www.w3.org/WAI/GL/wiki/WCAG_3_Timeline#2025
<bbailey> Backlog working on Audio Description !
Chuck: next topic, checking in on the schedule
<JenStrickland> DJ I'll email it to you.
Rachael: We are in Q2 2025, working towards our charter with a goal of publishing an initial developmental list by June. We'd like to have keyboard a11y ready for the list. We are going to make some behind-the-scenes technology changes. Anything in the working grouops that has been made progress on can go into this publication.
… Moving into Q3, we want one or two sub-groups moving into maturity. We need to do as much work as we can to have information to make the charter. We want to update the explainer
Rachael: There will be a retrospective at TPAC and re-charter in Q4.
shadi: 2 questions, can you say what the core issues are being discussed in Q2
<alastairc> Core issues list https://
Rachael: the core issues have not changed from the beginning, We have a Google sheet with all the core issue questions, this can be found here: Core issues list https://
shadi: if we want to publish conformance models by q4, what will we be publishing?
Rachael: we need a formal list of outcomes and requirements by the end of Q2. We are waiting until we have enough data.
shadi: I know there is a lot going on in the sub-groups. I think that the conformance model is going to take a long time, as will the charter discussions. I think we need more time
<alastairc> https://
Rachael: I agree, we will have 3 quarters for charter conversations. Back to the conformance models. We've talked about it a great deal, but we need to wrap the conversations up. We are open to talking about what aspects of the conformance model we can address before having the requirements.
… At the bottom of the WCAG3 doc we have narrowed down what the conformance model will look like. We have moved to the concept of foundational requirements and additional requirements.
alastairc: we have requirements under each guideline, we need to make more progress on that.
Chuck: there are two styles of queuing, conversational and linear queuing. Conversational allows the presenter and the questioner to have a back and forth.
Conditional requirements https://github.com/w3c/wcag3/discussions/305
Chuck: next item is conditional requirements
Rachael: One of the changes for WCAG 3 is the concept of conditional requirements (AKA adaptive tests). Something does not need to be universally applicable to be included. We had started talking about conditional requirements on GitHub with a conversation about i18n.
Rachael: Looking at questions on GitHub here: https://
Racheal: Question 1, what needs to be in the normative text? Are we comfortable with conditional requirements being foundational?
Rachael: Example, line spacing requirements depend on the language direction.
Rachael: Looking at issue #305 as an example of conditional requirements
<kirkwood> Is needing alt text a conditional requirement?
<alastairc> Within alt-text, you might have a condition to say that it's only required when conveying meaning.
<kirkwood> when an image is present?
<alastairc> Noting that a diacritic (https://
Gregg: First, +1 for conditions. This is great. For WCAG 2 we only excluded items that didn't apply to all types if we didn't know which types they apply to. We should be careful that we do not have conditions for no support, for example "if the underlying technology supports alt text", we should only do exceptions based on accessibility.
… If you are using an inaccessible technology the experience is inaccessible. Lack of support is not a get out of jail free card. EN301549 uses conditions on all of its provisions
kirkwood: would a conditional requirement be "if a page has images you must use alt text"?
<GreggVan> https://
Rachael: there is a continuum. We have this in WCAG 2 already. We could make it more explicit in WCAG 3. We can use the applicability trees if we want to expand it. This is about a quality of the created experience that makes something applicable or not.
gregg: I've added a link to a filter tool to filter EN301549. You can filter out provisions that don't apply based on things that are or are not in the experience. https://
<kirkwood> condition: page contains images. As long as we are explicit. pre-conditons like Gregg is saying. +1
<Zakim> alastairc, you wanted to suggest / ask about examples
<kirkwood> are we talking about an edge case here to point that Alastair is having a difficult time coming up iwith an example?
alastairc: we've been using the applicability tree as a mechanism for doing something similar, but for some scenarios we get (e.g. if you have a diagram on a marketing site that might not need a long description, but if it was educational content then you need it). Is that the type of condition that can be used here?
… Also conditions based on languages. This is way to not throw out requirements that are not universally applicable.
<Chuck> +1 we have run into different cases in our subgroup where our applicability tree doesn't handle.
Jennie_Delisi: I'm wondering if we need to consider when an element has multiple applications for the same element level. E.g. a word on a screen, or transcripts, or captions. The original way its being designed for may not be how its accessed. The way it is consumed changes it.
… If onscreen there are elements talked about where the language is consumed in a certain direction for one user but different for another user we might apply things like white space differently
<kirkwood> Jennie is giving a good point. think need real examples here to make
<Zakim> bbailey, you wanted to ask if conditional meant to cover exceptions currently built into SC?
kirkwood: I agree with that. I think that we need an specific example and Jennie's was good
<Zakim> bbailey, you wanted to ask if conditional meant to cover exceptions currently built into SC?
<bbailey> All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
bbailey: is the idea that the conditional might be things like exceptions built into current SC
<bbailey> https://
<Zakim> alastairc, you wanted to comment on exceptions vs conditions - numbers & scoping is the issue.
Rachael: We have perhaps made things exceptions that would better be a condition. Perhaps exceptions are best for very long conditions
<Zakim> bbailey, you wanted to follow up
<kirkwood> in order for a requirment to apply its when X condiion is met?
alastairc: you wouldn't want to list out a massive list of exceptions at the start of a requirement. We shoudl chose the method that is most concise and understandable.
<shadi> +1 to simpler having the condition first than exception afterwards
bbailey: "except where it is essential" comes up a lot in SC, that might be a candidate for conditionals.
<bbailey> https://
<Rachael> +1 to essential exception and division to conditions before/exceptions after
<bbailey> if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
gregg: second what bbailey just said. We can't make "where it is essential" as a precondition because it can't be processed until you read the rule. Things like timed responses in an auction, we can't make the response time longer for some. Other exceptions can mostly be made into preconditions.
<Zakim> alastairc, you wanted to comment on approach to writing for now
alastairc: I think for now the key is to build in exactly what the scope of a requirement is. This can be done with exceptions, applicability tree, conditions.
<Zakim> Rachael, you wanted to shift the conversation if this track is wrapping up
<kirkwood> When there is an image on the page (condition), the image must have alternative text (requirement) [asking]
Rachael: I'd like to use a survey to determine alignment ion what's an exception or condition. Is everyone comfortable with conditional requirements as foundation requirements?
<Ben_Tillyer> +1 to conditionals in baseline
<GreggVan> +1
alastairc: I don't have a problem with them being foundational as long as they are clear and objective
<Zakim> alastairc, you wanted to comment on including at foundational, depending on context
<Rachael> +1
kirkwood: need clarification of conditional requirements, doesn't every requirement have conditions? Is there a higher category we can apply to these, like language types?
GreggVan: You can put a condition on everything. The time to use them is when you want to eliminate extraneous items.
ChrisLoiselle: I think for Kirkwood's point, when you have decision trees around alt text for me its more about what the intent is. Is it how to code, how to test? that will affect where we want to place the conditionals.
<Zakim> Rachael, you wanted to wrap
alastairc: conditions eliminate many scenarios before a stated requirement. Exception is about eliminating a few scenarios after a requirement is stated
<alastairc> https://
Rachael: this is a great conversation. Let's move it to GitHub. Thanks
Opening survey on definition https://www.w3.org/wbs/35422/definitions-itterations/
Chuck: Next item, definition survey.
alastairc: we've opened a survey at https://
GreggVan: are these terms on the common glossary page?
alastairc: I'll add them to the common glossary, they are in the survey too.