Meeting minutes
Announcements
<alastairc> regets+ Lori
ac: will run orientation next week one hour before this meeting.
January Draft of WCAG3 https://deploy-preview-414--wcag3.netlify.app/guidelines/
ac: couple of months ago, the editors, met andworked through every provision.
… Need to review this. We are looking to move things from exploratory to developing, and our kind of maturity levels.
<alastairc> https://
<Rachael> Survey for blockers with alternative if you are unable to use github: https://
ac: 3 types of editorial changes, moderate (scope) not a blocker create a new issue.
<alastairc> https://
ac: blockers we have a quick survey set up.
<alastairc> https://
Julie: I'm still making updates.
RM: yes continue to fix things.
julie: will short names change?
… may be changes in how people navigate this.
ac: they may change a little bit.
<Zakim> bbailey, you wanted to ask if there is a diff preview ?
bruce: is there a diff version?
ac: not very useful but will take a look..
greeg: survey is open til?
RM: the 18th.
Sydney: I had a question just about how I plan to approach this,
… thinking of reviewing it in the W3C, not in GitHub and on the website.
<Zakim> Rachael, you wanted to say I think we can commit to the short names and organization being stable by COB Thursday.
RM: short name should be stable by thursday.
<Ben_Tillyer> Github docs on this: https://
ac: can leave a comment or a suggestion in GitHub
(demonstrates)
… https://
… if confusing use the preview.
<alastairc> https://
or pop it into the survey.
rm: the link is in the survey, and that's probably the best place to start for everybody.
<kenneth> the PR preview already shows exploratory by default
Julie: preview link is the only one showing. Not exploratory.
Ken: PR previews show everything by default, the link in the top right that says...
… README is not under guidelines. Don't worry about. The stuff under the source directory, don't worry about that either, that's just to make stuff display correctly.
<Ben_Tillyer> /docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request :)/https://
Ken: If you add single comment, it will send an email to everyone watching this every time that you add a single comment.
… If you click start a review. it will basically start a batch operation.
… But what that means, this is what to watch out for, so that people don't accidentally end up in a state where they think they commented, but nobody ever saw it.
… When you start a review, it will start adding pending comments, and those will only be visible to you.
… If you want to do it that way, you can do that, but what you need to remember to do is once you're done making comments, you need to go to the top right where it says Review Changes.
wilco: quite a few definitions that are either Just not there yet, or the placeholders with. w
Wondering whether the group thought about why are these ready for developing?
… Which I'm wondering, should those requirements go to developing if it's built on definitions that are not at that same level?
<Frankie> +1 to Wilco's question
gregg: do you prefer that we review changes and add them up, and then submit the review. with them all at once of to keep the clutter down, or do you prefer that we do the add individual comments as we go along.
ac: If you think it's just a handful, then I would suggest doing them individually, just because then it's in and it's done.
… When I did the review of this earlier, um, lots of them, I read it and I go, this isn't This isn't you know, finished. I mean, it's got all these undefined firms, and I went down to look at the definitions, and there weren't any.
<Wilco> +1 I can definitely live with exploratory deff for those
rm: I don't think we specified that we had to have them to move to developing, but I can certainly see the argument for it.
… developing means that we think the general direction is correct, but I wonder if we could aim to get definitions at the exploratory level, so we can get comments on them.
gregg: I thought the measure for getting into developing was not that it was headed in the right direction, but it was headed in the direction, and it also looked like it was possible that there was some possibility it could actually make it out, and that's why I think the definitions are important.
<Rachael> Maturity levels of document: https://
rm: he definition of developing is the content has been roughly agreed to in terms of what is needed for the section, though not all high-level concerns have been, sorry, high-level concerns have been settled.
<bbailey> Link in draft to description of maturity levels: https://
Hidde: I worry that we would keep things into exploratory for too long,
ac: kind of think about these review processes as kind of a bit of an onion.
Inner parts of the onion that is sort of doing an initial review, and then we're going to be expanding into internationalization, mobile testing etc.
julie: I wanted to bring up a specific example, text contrast, where we kind of have a... a draft of what it will look like, but with a placeholder for the actual algorithm.
<Zakim> Rachael, you wanted to summarize
julie: because we've built it out, but we're missing that key piece.
ac: That's a very specific example.
Subgroup work reminder / organisation
<scott> definitely would like to see at least exploratory definitions included.
<alastairc> https://
rm: I think we are agreeing that we're going to follow the process as far as, work, but we will guarantee, or at least strive very hard to make sure that there is at least an exploratory definition for everything we are moving to developing.
ac: If you signed up for a subgroup, those should be starting either this week or next week.
ac: (explains Calendar)
… any questions?
Bruce: wiki has some placehoder links.
<alastairc> https://
ac: not all of the facilitators have filled in that yet,
Heather: not in subgroup yet.
ac: looking for people for sign language and single sense,
Assertions https://docs.google.com/presentation/d/1Q78l5y6_SbHqQ9UAR1BPKbLhM5a_fN2Sl1XmDA6KvM8/edit?slide=id.p#slide=id.p
<Rachael> Assertions slide deck https://
ac: email questions, concerns, or things you want to change to the chairs.
rm: this will be an ongoing conversation.
… An Assertion is a formal claim of fact, attributed to a person or organization
… Assertions may be used as part of a conformance claim or to support an independent claim of accessibility conformance.
… The results of the process stated in an assertion cannot be tested.
… Assertions include: The statement about the process being asserted,
… The date of the assertion,
… The date or date range the procedure was completed,
… The scope of the assertion,
… Contact information for the person or group making the assertion, and
… The requirement(s) or guideline(s) supported by the assertion.
… WCAG will not require organizations to provide supporting documentation in order to conform.
bruce: is procedure and process the same?
rm: they are interchangable. Will need to clarify that.
… (goes over Draft assertion format)
… (goes over Draft Outstanding questions from explainer)
<GreggVan> thanks - that is very helpful review
<Heather> I can scribe.
<Heather> After this comment
Graham: Why are we doing assertions?
hdv: Assertions can be very useful for anyone who wants to compare products, and make it easier for those to make selections for products due to the standardized way to make claims.
rm: Encourage people to do non-repeatably testable actions that we know are important to support people with cognitive disabilities.
bbailey: Please ensure that succinct description of assertions is captured.
graham: +1 on the explanation. Devil's advocate on where do we think the gaps are? Capturing the areas that we cannot make rules is also important.
Rachael Anything we can make testable is absolutely desirable. Continually trying to figure out how to do it.
GreggVan Key is the testability part. Applied a manual, but then make it testable, and you have to say what the manual was. To make it testable, you have to say exactly what the review had to be and what the outcome of the review had to be. That's where assertions end up. We can't define exactly what a testable measure is kind of thing.
Rachael Appreciates the conversation to get everyone synced up.
Rachael: Slide 6 has a history of assertions. Slides 3-5 summarized where we are.
… Slide 7 is the beginning of the next phase. When making an assertion, the proposed format is "we" then "assert that" then whatever process is being asserted, including the guidelines supported by the assertion.
… include the date of the assertion and related linked. Does the format work?
… different kinds of assertions. one to cover topics that are difficult to turn in to testable requirements. Two, to provide a more robust coverage of user needs that are only partially covered as testable requirements.
… overall coverage needs to have some kind of review or procedure conducted. Expect that AT testing to be an example of this. Should there be umbrella assertions and cross-reference them? Maybe create style guides.
<Zakim> Jennie_Delisi, you wanted to discuss technology version
Rachael: also a concept of meta-assertion, such as scoping. Some may be considered into an upper level of conformance. Making a clear assertion around the scoping of the work you have done.
<Zakim> alastairc, you wanted to comment on when assertions would be asserted
Jennie_Delisi Overall likes the direction of assertions. Include the technology version to enable somebody to review the capture in time. Include the technology version, the online tool version number, and the browser version. This will help in a repeatable validation, or the scoping of it.
<Glenda> Here is a sample Participant-Representation Assertion I had drafted:
alastairc Use of assertions: You're just using the guidelines, but you're not making any formal statement. The second statement is that you are making an accessibility statement at a point in time. In this case, there would be a need information specific to the assertion. You need the general information at the top and the requirement/assertion
underneath.
graham Need to cover limitations of what we were able to do with that assertion.
Ben_Tillyer To Alistair's point, assertions can be made outside of conformance claims or statements. Maybe there's two versions, maybe you have a standalone version. Suggest using optional field, such as for evidence to be available to certain people. Legislators might want to see evidence of assertions that corporations are making. Second thought:
add 'competency' of the person or group making the assertion to carry reputational weight. Expiry of when it was written, and the limitation of its validity.
<Glenda> (1) Participant-Representation Assertion
<Glenda> Example Statement: Between 1 Jan – 31 Mar 2026, Acme Corp conducted moderated usability testing with ≥ 9 participants representing at least three functional-need categories (vision, motor, cognitive/learning) on all critical user journeys of the Acme Mobile Banking App v4.0.
<Glenda> Scope: Mobile app v4.0, iOS & Android.
<Glenda> Guideline Supported: User Testing (future WCAG 3 guideline).
<Glenda> Contact: inclusion-lab@acme.com
Glenda How could this create a situation where the right things are happening. Shared example (above).
… This is a participant representation fo the usability test. included the scope of the application, guidelines that applied, and contact information. Curious about what the results were, and making the usability test report available. Curious about the task completion rate for critical journeys. Down the line, do we have a remediation loop. Was
<Glenda> (2) Task-Success Assertion
<Glenda> Example Statement: Across the same study, participants with disabilities achieved a mean task-completion rate of ≥ 90 % on critical journeys, with zero Blocker issues remaining open at launch.
<Glenda> Scope & dates: Matches Assertion #1.
<Glenda> Evidence retained: Video recordings, success/failure logs, severity matrix.
<Glenda> (3) Remediation-Loop Assertion
<Glenda> Example Statement: 100 % of Blocker and Critical findings from the March 2025 study were resolved and verified via re-test with at least two original participants before public release on 22 April 2026
<Glenda> Procedure type: Design/development.
<Glenda> Evidence: Jira tickets, “fix-verified” confirmations in test logs.
anything fixed based on the results?
… continuous testing assertion and wrote one for an accessibility support set.
<bbailey> This 508 checklist might be useful for drafting assertions: https://
<bbailey> Interesting, to me, is no mention of date or scope!
julierawe Piggybacking on Glenda and Jenny about which tool we use to do the testing. Two buckets: Details to be made public, and then an informative section for internal only use. The idea of informative part is what we recommend you keep internally, keeping in mind the practical discussions with attorneys.
<Zakim> hdv, you wanted to respond to Alastair
hdv What kind of metadata to include? Realistically, some people are going to make assertions as part of their accessibility statement, and others will do a separate thing. Some attributions, like IC or Director level could have more weight. Some organizations require that director level or higher sign off on the conformance claims for the organization. Thinking about
evidence, whether it's public or private, in conformance information that we monitor at the Dutch government are extremely open and transparent, but there are different legal cultures that may use these differently.
Heather: Like previous comments. Who made it is useful, the group who made it, affects how seriously to take it. Review time is interesting, and who reviewed it.
… Agree with the context of: Who's using it, and what for? Is that creating a competivie advantage.
<Zakim> alastairc, you wanted to comment on expiry - has to be a point in time
<Jon_avila> I agree with what others have said about assertions - documenting the person - preferred at more senior level, scope of the assertion - what is covered, and the percent of use, expiration, etc. I've heard organization say we use a design system - but only for some components - many components don't actually use their design system.
<bbailey> Another FYI, M-24-08, most recent U.S. OMB instruction on 508: https://
<Zakim> Rachael, you wanted to discuss expiration date
alastair: Expiry has to be a point in time. Statements is a lot of work at the top of a pyramid. We will increase usage if we make that harder by having a particular review dates per assertion. If you're doing a statement, that needs to be the status at that point in time. Particularly for usability testing: task completion rates may be troublesome
because usability testing is so malleable because of the task selected, the questions you're asking people to do the task, who your participants are, what their disabilities are - there are so many factors. What is beneficial is that you've done testing, and made updates based on that testing.
<hdv> +1 Rachael, we run into context of expiration date discussions _a lot_ in our monitoring
Rachael Expiration dates: Encourage us to think about that as something to put in our policymakers document and not our format for the assertion. When we first began assertions, we dug into the concept of expiry date, and challenges vary. Will put this conversation in the policy document.
<kirkwood> this will be ioncluded in policy, if successful
<Zakim> Jennie_Delisi, you wanted to discuss retention timelines
Kevin Agree with Alistair and Rachel about the positioning of assertions and how to use them. Thinks about how long is the assertion valid for something that lends itself more to be something for a policy writer to consider. The policy makers may decide to be more lenient or less lenient. As for remediation checks, whether or not they have done
remediation. Conformance perspective, you're conforming or not confirming.
Jennie_Delisi Retention policies fall under shorter timelines to have this information stay up to date. Where that internal information is stored, based on the type of information being suggested, and the ability to keep that internal information up to date, as well as those links to that internal information. Agree that it should go in
recommendations.
Ben_Tillyer Expiry would be good to put in as an optional field rather than making it mandatory. Example: several different versions of a component library, and have different assertions for each of them. Having the expiration box whether that's version or time would be useful to larger organizations.
<kirkwood> +1 to separation
jkatherman Regarding assertion format, second part of the bracket. Recommendation would be that we separate those into two things: the process (the thing that was done) and the guideline supported by the asserting. We did this thing in order to, support this guideline, etc.
stevekerr Regarding expiry dates: if we were providing a time frame, consider if it were likely to change over a year.
<Zakim> bbailey, you wanted to mention that U.S. govt web accessibility requirements didn't have expiry or scope
<bbailey> I wanted to mention that U.S. govt web accessibility requirements didn't have expiry or scope. See links I posted in IRC.
alastairc Complications for organizations that have a different set of components for each section of the website, using a different tech version.
<kirkwood> +1 to Bruce
<kirkwood> agree
bbailey Posted links above. Suggest that WCAG should have a light touch because of things like document retention, and other broader policies.
<nat_tarnoff> +1 to Bruce's comment
Jon_avila Regarding to design systems: Sometimes the design system isn't used, or that the design system only addresses some aspects of accessibility. Having parameters that help define, or having parameters for people who are reviewing that information can make decisions if that information is provided.
alastairc Assertion writing needs to be fairly tight.
<alastairc> Contact information: Should we require a contact mechanism?
<hdv> -1
<Ben_Tillyer> -1 to public, +1 that it is documented somewhere (or staff ID etc)
<SydneyColeman> -1
<alastairc> -1
Rachael Making sure that the person making the assertion matters, and their expertise and understanding it is important. Do we require a contact mechanism?
<LenB> -1
<kevin> -1
<CClaire> -1
<Heather> +1
<nat_tarnoff> -1 People move in and out of the industry all the time.
<stevekerr> -1
<kirkwood> legal, don’t think we can
<Jon_avila> +1 requiring a named person +0 to contact information
<Rachael> note that contact information could be for a group or office like communications or the accessibility team
<julierawe> -1 especially given nat_tarnoff that people move jobs all the time
<kirkwood> -1
<tayef> -1
<Makoto_U> -1
hdv Complexities around having contact information.
<nat_tarnoff> How do we "qualify" a person for assertions?
<bbailey> +1 to contact information (of any kind) since we (U.S. govt) were able to get that into formal Section 508 guidance. (Not the law/regulation.)
<kirkwood> +1 to Jennie
Jennie_Delisi For safety reasons, contact could be a general inbox.
<ShawnT> -1 to person, 0 to a general
<jkatherman> +1 to contact but not requiring a specific person just a contact method to get the information (general information only)
<Zakim> kevin, you wanted to comment on contact information
<Heather> +1 to Jennie
<kirkwood> again legal
Kevin Legislation in the EU requires points of contact for accessibility statements. Falls into the policy side of things rather than as part of an assertion conformance requirement.
<kirkwood> +1
<bbailey> An example from OMB memorandum: The contact information for the Section 508 program manager (name and email address)
alastairc Could work that is as people creating WCAG, putting in optional fields, and then in the policy document, you might want to make these required.
RachaelWe are going to make it optional as a general contact, but recommend in the policy document.
… will touch on the next topic and pick it up next week. How we write them, and how we cross-reference them. Concept of very specific assertions. Reviewed examples.
… Conceptually, do we treat these as an umbrella, where we have a section in W3C that talks about style guides, or do we keep these as kind of their own individual?
<Zakim> Rachael, you wanted to weigh in chair hat off
<kirkwood> We assert that we meet WCAG 2.1 (again legal:?)
alastairc Chair hat off. The style guides jumped out for certain provisions as the obvious answer/progression. because if there are more than 4 or 5, it could naturally create an umbrella.
<bbailey> +1 to what alastairc is saying
<Ben_Tillyer> +1 to Rachael, thoughts sound good
<kirkwood> +1 to Rachael
<LenB> +1 to Rachael
Rachael Chair hat off. Having umbrella concepts in their own section is helpful, but want to keep them separate as well. Personally like to see how it interrelates. Would like to have cross-references and as individual assertions.
<Glenda> +1 to Rachael’s suggestion
<kirkwood> Bruce has a very good point
<Zakim> Rachael, you wanted to answer bruce
bbailey A concern is that he's seen whole websites with 100 pages devoted to alternative images, or a very very long style guide for how to do good audio descriptions. There's a tension between trying to keep things all in one place and keep them readable at a short glance.
<Jon_avila> Example of what Bruce is saying on alt text https://
Rachael I don't think we are writing the style guide, we are writing the guidance on how to create a style guide; how to use a style guide to improve accessibility.
bbailey Citing various style guides could be a great way to do this.
<kevin> Yes, possibly point as exemplars... with care
RachaelWe might do that in our informative documentation, making recommendations that are out of our scope; point to things as exemplars.
<GreggVan> +1 to that
Rachael Did anyone disagree with having a mix of both individual and centralized umbrellas when appropriate? (no responses)
<hdv> +1 to Rachael's suggestion
<bbailey> thanks Jon_avila -- and I will note that PDF resource is 50+ pages in print.
<kirkwood> What is a satisfacory assertion? to meet. Think we will need good/bad examples.
Rachael Thoughts on meta-assertions (introduction): go beyond just related to a style, to a particular requirement. Things like scope of what you're testing. Should we consider or are there concerns with us considering?
<kirkwood> just using a process doesn’t make something accessible though?
alastairc When dealing with foundational supplemental requirements, it really has to work on a page or view by page. You could have an assertion that we used WCAG to define our scope. It's like a meta-assertion to define which process you used to define the scope. You're making everything in your accessibility statement seem so much more credible
because you're been through this process, and therefor everything else you've done is less 'gamed.' You've gone through a definition process to define your scope.
… A process doesn't automatically make something accessible, but if you know that there are processes in place, they are so much more likely to have an accessible product, an accessibile process for dealing with issues. If an organization does not have those processes, then everything is 'gameable.'
<Jennie_Delisi> julierawe - would that be helpful for organizations that invest in plain language training for their staff?
<kirkwood> example?
To this point, assertions have been supplemental requirements. You do them, and you would increase your score. An assertion would essentially just up your score by one. Whereas this is more of a suggestion that we reserve assertions or meta-assertions for the silver level, because they are more organizational and process Oriented. They affect how
you do the rest of your conformance level.
<kirkwood> no
<kirkwood> +1 to exploring
<GreggVan> +1 usability testing is one example
<Heather> +1 to exploring
<Jennie_Delisi> +1 to exploring
<Ben_Tillyer> +1 to exploring, -1 to calling them meta-assertions. To me, they're just assertions
<alastairc> https://
alastairc wrapping up. Charter survey is open.
… Charter survey is scoping for the next two years of work, please add comments.
<hdv> +1 to Ben
<kirkwood> link to survey again?
<Jon_avila> +1 to exploring - DOJ was looking into this for the proposed ADA Title II rulemaking - but it didn't make it into the final rulemaking.
<ShawnT> +1 to Ben
<kirkwood> oops
alastairc Charter survey closes Jan 13 or 14th