Assertions Discussion

[rachaelbradley]

We will be discussing Assertions for the next few weeks in the working group meetings.

Reference: Assertions Slide Deck

[rachaelbradley]

How WCAG 3 Define Procedures?

From WCAG 3: A procedure may be limited to guidance:

• approved by AGWG and listed in WCAG,
• that references publicly published guidance, or
• that meets criteria specified in WCAG
• or it may be any process that an organization uses to improve accessibility.

How should WCAG 3 define the procedures that Assertions reference?

[mbgower]

assertions are not repeatable or verifiable

On 7/23 call, I stated that I believe that while that may be true, the outcome may be able to be assessed. For example, if someone has an assertion for a process their team uses to arrive at clear wording, and their resulting headings are wordy and poor, one cannot verify the team has done their process, but can point to the outcome to show that either they did not carry it out, or their process sucks.

[bruce-usab]

On call 7/23, I shared my opinion that the current definition of assertions could include activities frequently included in U.S. legal settlement agreements such as consultation with advocacy organizations. From that perspective, some assertions have some ability to be verified.

[mbgower]

it may be valid to state that the assertion cannot be verified from the page's outcome but that the team may be able to show evidence that their process was carried out. I think this is supported on slide 7 of the assertion deck.

WCAG recommends maintaining additional information that an organization can use to improve or validate procedures and assertions.

[GreggVan]

Good finesse. It doesnt say anyone would have access to them -- or that they would have to show them-- but that it would be good to keep such records "to improve or validate procedures and assertions."

[shawnthompson]

Wasn't there talk early on about maybe adding links to documentation in metadata about assertions? I vaguely remember the idea being brought up and thought it was an interesting idea.

[GreggVan]

Key to the concept of assertions is that the ONLY thing to test is that an assertion was made. There is no requirement for a testable outcome (or we should be using the outcome as the measure - not the assertion).

Also note that we can give points for an assertion for higher levels -- but unless we can confirm that companies can make assertions (in the 2000-2008 period we were told that many large companies were not allowed to by legal departments) we would not be able to include assertions as requirements for conformance at the basic (or any regulated) level.

A key part of our architecture then has to be structuring the guidelines so that testable / requireable provisions are right along with recomendations for doing non-testable but just as important things.

[bruce-usab]

Maybe an example which might be point for call today:

Assertion: We have taken steps to ensure we are using plain language. We test our assumptions as described by Federal plain language guidelines
.

[rachaelbradley]

Summary of Questions from Assertions Template Exercise

1. What level should assertions be placed?

• For example, assertions may reference guidance such as a style guide or testing such as AT testing or usability testing that covers multiple guidelines/outcomes.
• Should the assertion be mentioned both at the outcome and a higher level
• Should we frame assertions so they refer to a section of a larger document (example: Guidance that addresses alt text instead of a style guide that addresses alt text)

2. How can a person or organisation with a small website attain the highest level of accessibility?

• E.g. simple website done by an expert may not need internal guidance in the same way that teams do.
• Related question: If a small website/organization meets all the criteria at each level, is that comparable to the assertion?

3. How are assertions tested?
   -Validating an assertion only tests that an assertion was made and correctly stated/documented. Sometimes testers will see sites that are so bad it is obvious the assertion is false. How is that handled?
   -If the documentation that supports an assertion is not public, how are assertions enforced or validated?

4. Can WCAG 3 require an accessibility statement?

• If yes:
  -- What should in included in order to make it useful?
  -- Should they only be required if the organization is using assertions?
  -If no:
  --There seems to be some consensus that an assertion must be made in a publicly available location. Would that location then be in an accessibility conformance report?

[rachaelbradley]

Summary of Discussion from 27 August 2024 meeting

From a documentation perspective, the group was generally in favor of integrating assertions at multiple levels, alongside requirements. Exactly how they are handled will be dependent on conformance decisions but the process we will continue to follow for the near future is building them into decision trees and then look later to see if they can be grouped. We then discussed how assertions might fit into conformance.

Please reply to the new threads below for the follow up questions:

• Should assertions be available to meet a conformance level? Opinions varied widely during the discussion. Some members felt they should be visible but never used to meet conformance at any level, some members felt that they the option to use assertions to meet any conformance level should be left open, and some felt that assertions should not be used at the most basic level of conformance but should be available as one way to meet higher levels of conformance.
• Do assertions need to be made in a place that is viewable by people who have access to the system or only in a conformance statement that is provided by the author? The group generally agreed that assertions should be documented as part of conformance statements but supporting documentation should not be required required to make a conformance statement.

[detlevhfischer]

1. My view is that assertions should be kept clearly separate from the result of any outcome testing and not enter any score. So they would not be on the same level but in another compartment.
2. Since the level of outcome would be unrelated to any assertions made, there is no problem for smaller organisations that don't have or need a formal process.
3. An assertion template may at least link to a doc (policy, process description or styleguide) that substantiates the assertion. If no such link exists, readers can draw their own conclusions. No test of content can reliably substantiate the assertion (because the fact that a site's content indeed demonstrates what is being asserted may be due to factors other than the documented process).
4. My feeling is an accessiblity statement is on the level of policy, not standard.

[GreggVan]

Regrets on the call tomorrow -- conflict came up
here are my thoughts quickly

What level should assertions be placed?
For example, assertions may reference guidance such as a style guide or testing such as AT testing or usability testing that covers multiple guidelines/outcomes.

• should not be required at any level we want picked up in regs
• but YES definitely want them viewable and seen right along with our most basic requirements !

Should the assertion be mentioned both at the outcome and a higher level

• yes -- mentioned at basic outcomes level -- as ways to get points for doing better to get higher level rating

Should we frame assertions so they refer to a section of a larger document (example: Guidance that addresses alt text instead of a style guide that addresses alt text)

• not sure I understand but I think I know. I think it should be specific. If in larger doc - refer to section.

How can a person or organisation with a small website attain the highest level of accessibility?
E.g. simple website done by an expert may not need internal guidance in the same way that teams do.

• in some ways it could be much easier to. in some ways harder
• we should include a mix of both so it is level playing field

Related question: If a small website/organization meets all the criteria at each level, is that comparable to the assertion?

• do not know what that means

How are assertions tested?
-Validating an assertion only tests that an assertion was made and correctly stated/documented. Sometimes testers will see sites that are so bad it is obvious the assertion is false. How is that handled?

• well - if the assertion is that you did training -- a bad site does not mean that you didn't. You may just have bad designers or designers that don't care.
• an assertion is just that. If you make it -- you pass - no matter what the site looks like. (Otherwise it is an outcome you are looking for and not an assertion

-If the documentation that supports an assertion is not public, how are assertions enforced or validated?
-require that it is public to be an assertion
-you can't enforce an assertion. it is or it isnt.

Can WCAG 3 require an accessibility statement?

• in WCAG 2.0 we were told that some companies would not do that. which meant they could not ever conform. which meant - why try.
• instead we said what was required if you did.

If yes:
-- What should [we] included in order to make it useful?
-- Should they only be required if the organization is using assertions?

• I think no - that might discourage assertions.

-If no:
--There seems to be some consensus that an assertion must be made in a publicly available location. Would that location then be in an accessibility conformance report?

• it could but many companies have confidential accessibility conformance reports and only show them when required as part of an RFP to avoid critique and criticism.

[detlevhfischer]

but YES definitely want them viewable and seen right along with our most basic requirements!

My assumption was that what organisations will want or be able to assert will depend on their own processes (human remedying, automatic checks, AI, whatever) and will come in various kinds of granularity (from addressing one outome, to several, to pledging continued conformance the the whole lot) so I fail to see the point of any kind of prefab assertion baked into the basic requirements.

[rachaelbradley]

Should assertions be available to meet a conformance level?

Opinions varied widely during the discussion. Some members felt they should be visible but never used to meet conformance at any level, some members felt that they the option to use assertions to meet any conformance level should be left open, and some felt that assertions should not be used at the most basic level of conformance but should be available as one way to meet higher levels of conformance.

Please reply to this thread with your position and reasoning or react to responses with thumbs up or thumbs down.

[gundulaniemann]

Assertions should not be part of the decision tree, as a strict separation between testable and non-testable outcomes is needed.
The example assertions we have seen so far ask for guidance/guidelines. These are usually internal to a company, thus they cannot be retrieved by 3rd party testers. As a consequence, they are not suitable for any conformance claim.

[GreggVan]

Yes but not the base level -- or the level that we want to have required in regulations UNLESS we determine that all companies can make assertions. Assertions are different than just doing something. It is like obeying a law (stopping at stop signs) and legally asserting that you stop at stop signs. Everyone can do #1 but a lawyer would not let you assert that you do.

we don't want the basic level of conformance include something that a company can't/won't do - or else they can never even try to conform at that level.

[alastc]

Chair hat off - I'm concerned that we might run into equity problems if we cannot use an assertion at the baseline level.

For example, if there is a language based requirement for people with cognitive impairments that can only be addressed by following a process. It could be as important (to end-users) as things which are more objectively tested.

Why shouldn't that be at the baseline level?

Chair hat on - I also appreciate the concern that we don't want to include things at a baseline level that can't be used by some organisations. I think we need to get an answer to that concern sooner than later.

[GreggVan]

Agree with this

But there is a corollary. If some orgs can't do it -- it can't be in a regulation. Or won't be adopted in regulation. And we don't want out base level to not be adaptable......

So again - a key question we need to determine -- "Are assertions something that can be required? That all companies could reasonably do? So far I know know if we have any reliable conclusion. Just old information (my information is old - but seems like it MIGHT (and might NOT) still hold and wishes and hopes and fears. Would be good to get some input from companies and lawyers at regulators? Tough question. We would need a bunch of legal opinions that agree? unghh

[ChrisLoiselle]

Hi @rachaelbradley using https://www.w3.org/WAI/planning/statements/generator/#create as an example, the "statement" provides what standards were applied, conformance status, "your efforts" which then has a subset of organizational measures, which could be interpreted as "assertions" by a company or org of "what they've done". I understand @nitedog and others were on the project team on the WAI statement generator, so perhaps pulling those individuals in on how we can reformat or utilize what WAI has already done to insert assertions in to that project would be beneficial so we don't lose all that previous work that seems to resemble these efforts. In the use case of using https://www.w3.org/WAI/planning/statements/generator/#create the statement wouldn't be used to meet a conformance level but provide a statement on what you've done to get to the level you are stating you've achieved per your assertions and efforts , methods, outcomes of testing, applicable outcomes analyzed, etc.

[rachaelbradley]

Do assertions need to be made in a place that is viewable by people who have access to the system or only in a conformance statement that is provided by the author?

The group generally agreed that assertions should be documented as part of conformance statements but supporting documentation should not be required required to make a conformance statement.

Please reply to this thread with your position and reasoning or react to responses with thumbs up or thumbs down.

[GreggVan]

Not sure what your first part means. You mean that they would have to put the assertion on every page that a person might visit so that they would be viewable by people who access the site on any page? Or do you mean that there is an accessibility statement someplace on the website (example.com/accessibility) where they can view it? (versus only having it available as a legal document if you request it?)

Can you provide a little bit more information about what the two choices are? Or if you have three or more?

[alastc]

(Chair hat off) I'd like to re-phrase the question a bit in order to answer: Should the documentation behind an assertion be publicly available, available to trusted 3rd parties, or always private?

I think from a WCAG point of view, we should only ask for the assertion, yes/no. That someone is making an assertion should be part of a conformance / accessibility statement.

However, all the documentation behind that should not be required by us.

We can provide informative information on how to assess that you are meeting an assertion, and what documentation you should gather as evidence.

The use of that documentation is then up to organizations and their regulators. It could be required to be public from the regulator, or it might be required if there is some legal action. However, I think it would undermine the use of assertions to require the documentation be public, as it is likely to include non-public information such as internal policies and processes.

[ChrisLoiselle]

@alastc

_Re: We can provide informative information on how to assess that you are meeting an assertion, and what documentation you should gather as evidence.

The use of that documentation is then up to organizations and their regulators. It could be required to be public from the regulator, or it might be required if there is some legal action. However, I think it would undermine the use of assertions to require the documentation be public, as it is likely to include non-public information such as internal policies and processes._

1. I believe what we'd need to determine, if we haven't already, is whether or not assertions are in fact testable. @GreggVan has mentioned before, I believe, that they aren't. @GreggVan correct me if I mis-read that in another discussion/issue.
2. If assertions are not , then how would one assess they are meeting an assertion?
3. Is that the company self validating and verifying internally that they are about to make an assertion publicly and then :
4. Making sure they've gathered and have internally (but won't ever share that documentation publicly), the information needed to make that assertion?
5. Or is what you are stating that the we, AG, would provide information on how to assess the assertion itself that the company made, from a customer or potential customer perspective?
   I've heard both sides of assertions on W3C calls, as to whether or not these would be testable, and I feel group consensus would be beneficial to understand how we'd proceed with these moving forward.

[alastc]

Hi @ChrisLoiselle,

Gregg has stated that assertions are testable, and he means that in quite a particular way. I.e. You can determine ("test") that the company has made a positive assertion. Yes/no, have they made an assertion? That is "testable".

He was not saying that the assertion could be validated.

Essentially, validation of assertions would be out of the scope of WCAG3. We can provide advice on how to document assertions, but then it is up to the organizations / regulators about how that documentation is used.

In practice, I would foresee that an organization making an assertion about alt-text, then having obvious 'fails' on the website, is not going to do well with regulators or in legal cases.

[bruce-usab]

Building on @mbgower comment above, that assertions might be validated (but not by source code inspection), an example an example is that if an org asserts they follow a style guide — an audit could/should include the style guide as an attachment.

[ChrisLoiselle]

@alastc thanks for the comment. If you can't validate something that is part of conformance then I would say the weight or applicability of assertions compared to what you did test and validate in actual testing would be worthwhile to include in a conformance statement. If you can't validate an assertion but you can make one, that does not seem fair to end user or a firm trying to make a procurement decision. For me that gets in to the gatekeeper and the gate analogy and if we are excluding from WCAG 3 or including in a phase for baseline or requirements, that is something to be considered for sure.

[GreggVan]

Assertions by their definition cannot be "evaluated" or "validated",. The assertion is just that. An assertion. the only thing to test is whether it was asserted. And if you have it in your hand - you have proof of it. Anything beyond that is not testable.

You can only rely on ISO 9000 and companies' integrity.

The only test of an assertion is that it was made.

it is not otherwise objective or testable

[ChrisLoiselle]

Hi @GreggVan I'm following your comment, but have a question on "And if you have it in your hand - you have proof of it."

Use case: A company asserts that their methods/best practices include using proper labeling for all interactive controls on their web documentation that is public facing.

The evaluator or end user of documentation finds that there are 3 unlabeled form elements for interactions such as submit this post, cancel and reply within the company's documentation forums. Not necessarily testing but just using the product with a screen reader they come up with unusable elements on a page that stop progress.

Is that proof in hand? To me, a company is asserting confidently they are doing something and the user is proving that they have not done so in entirety. If not a test, are you stating that a person can't test or validate an assertion at all? Would this be more of a "dispute" of fact to counter the assertion? How would someone accept this as true without validating ? If not able to protest or dispute, taking something as fact is nice in an Utopian world, but could get messy legally per what was stated, not stated or stated slightly incorrectly.

You prove a hypothesis by testing/validating it, thus if someone is asserting something there has to be a counter to that so I'm just wondering what that would be in terms of the actual "term" you'd use within this thread.

I appreciate your comments, time and thoughts on this topic and all the work we've done together, thank you!

[mbgower]

Use case: A company asserts that their methods/best practices include using proper labeling for all interactive controls on their web documentation that is public facing.

@ChrisLoiselle, please refer back to the Background slide at the front to the Assertions deck Rachael cites at the start of the discussion. Assertions are intended for considerations that cannot be judged by repeatable and verifiable qualitative or quantitative tests. The use case you cite does not fit, since it is clearly testable.

So I think we need to consider use cases that fit the context of the assertion discussion.

Having said that, some of us have already covered scenarios where an outcome is demonstrably poor, thus offering evidence that an assertion by a company is failing to achieve its goal. That is also called out in the second bullet of the Background slide "(results can be assessed)".

So, in such a case, an assertion could be made about steps a company takes to lead to a desired outcome, but if the outcome isn't achieved, the assertion is obviously challengable, either in the process effectiveness or adoption.

[ChrisLoiselle]

@mbgower I agree with what you are stating. I'm stating if we are using this word , the term and all the variations of what does not fit and what fits needs to be explicitly stated. The move to WCAG3 is to make WCAG more plain text driven / understandable. For each term used in WCAG3 , the defined term should offer a "if/when/then" type of scenario of applicability. Someone who doesn't have an enterprise type company behind them to research all things related to W3 and WCAG may get lost in all the terms we are introducing. Someone nonnative to accessibility may get lost on what these term means. The goal is make the technical not overly technical in that someone should not need to outsource to an accessibility auditor / company to verify what is meant by "X", related to WCAG or WCAG3.

For me, the goal is to make the use of terms and the explanations blatantly obvious so we understand this word means this and is defined as such. That would avoid pointing people to links / references to explain what we mean by things.

I totally agree with what you stated and how you stated it. Thank you for your comment! It takes a village to do what we do and I appreciate your insight.

[mbgower]

I agree that a list of assertion examples could help crystalize the discussion. There are a few in the deck, but it would be helpful to flesh a few out to further the discussion.

[GreggVan]

@ChrisLoiselle To answer your question.

• The only thing testable about an assertion is that it was made. If it was made - the assertion provision is met.
• Whether the assertion is true or not -- either when it was made or later - is not relevant to "passing" an assertion provision, only that the assertion was made.
  • here we rely on ISO 9000 series standards that companies follow where they have to prove the do what they say to pass.
• If you COULD test an assertion -- then it should never have been proposed as an assertion in the first place.
  • the purpose of assertions is to get things in front of authors that are not testable
• so any testing of assertions is moot. There should never be an assertion that is testable. (If it were testable there is no reason to not make it a requirement if it is important.) So the topic of "testing assertions" is is a contradiction of itself. It would be "testing the untestable" or saying that assertions must be testable to be assertions -- in which case they should be requirements not assertions.
• ALSO note that companies do not make up assertions. WCAG assertions would be pre-made statements established by and documented in WCAG to accompany and augment the requirements. A company can choose to make one of those WCAG assertions. But they can't make up an assertions by themselves and have it count toward any WCAG level of conformance or recognition. Otherwise they could make up all sorts of trivial assertions and count each ont toward whatever recognition we provide for someone who makes WCAG assertions.
  • we only give credit if they make one of the WCAG assertions that we document in WCAG as being worth getting credit for

Specific to your example or case

A company asserts that their methods/best practices include using proper labeling for all interactive controls on their web documentation that is public facing.

• if this is not a WCAG assertion then it has no affect on WCAG or any level of conformance to WCAG
• if WCAG made it up - it by definition is not testable so there would be no way to test this - except to test their assertion
• Having labels is testable so having labels would never be a WCAG assertion. So this case could never exist for a WCAG assertion.
• the only issue I see is that your case says "proper" which is not testable unless you have a specific list of properties that constitute "proper". Then it would be
• so the way it would work would be
  • WCAG might have a requirement of labeling for all interactive controls (this is testable)
  • if we could define objectively what "proper" meant -we would have a requirement for "proper labeling for all interactive controls"
  • if we could not define proper we might have an accompanying assertion that the labels were all "proper".

Does that help?

[rachaelbradley]

Additional conversation on assertions is in smart requirements comments.

[ChrisLoiselle]

@GreggVan @rachaelbradley @alastc

My recommendation would be to clearly articulate the differences of evaluated, validation vs. use of word testing per the assertion topic discussed here and on discussion 306. We also should be providing clarity on requirements vs. assertions in terms of conformance.

On #306 and the bulleted item:

- Include assertions for processes that don’t lead to repeatable results but have been shown to improve accessibility [Define by Date & Example Date].

My request is that we have more data / use cases to showcase examples to users of WCAG3 on how these assertions can be included for processes that don't lead to repeatable results but have been show to improve accessibility. If something is shown to improve accessibility , isn't that something that is repeatable per data you are tracking over time that shows net positive from the baseline? It would helpful to have more real-world examples vs. the theoretical on this on how it actually impacts end users of WCAG3 and the end user of tech that would apply WCAG3's methodology. If those data points live within W3C and WCAG3 material , I can review off of this thread and add more to my comments here.

[rachaelbradley]

3 June 2025 AG Meeting Discussion

Chairs put together a presentation to prompt conversation on the following questions:

• How do we handle assertions that span guidelines?
• What does “documented” mean? Available publicly or published at all?
  -- What information should be included when documenting an assertion?
  -- What optional supporting documentation should organizations provide with an assertion?
  -- Is there a need for WCAG 3 to require proof of an assertion, and if so, what documentation should be required as proof?
• Should assertions be dated, expire, or be reviewed on a regular basis?

Use this comment for post-meeting conversation.

[bruce-usab]

FWIW, Section 508 uses "required documentation" two places. When I was at USAB, we regularly got questions about it, since the language is deliberately open-ended. On occasion, an agency 508 coordinator would ask how to file their claims? That sort of detail is not part of the 508 statute, and so not in the 508 regulation. Excerpts follow for required documentation for E202.6 Undue Burden or Fundamental Alteration and E202.7 Best Meets. I think this kind of phrasing might work for WCAG3 assertions. There are other terms (e.g., undue burden, fundamental alteration, agency official) not defined in the 508 regulation. My opinion is that this works well enough, and my recommendation is that WCAG3 not be overly prescriptive regarding assertions.

The responsible agency official shall document in writing the basis for determining that conformance to requirements in the Revised 508 Standards constitute an undue burden on the agency, or would result in a fundamental alteration in the nature of the ICT. The documentation shall include an explanation of why and to what extent compliance with applicable requirements would create an undue burden or result in a fundamental alteration in the nature of the ICT.

The responsible agency official shall document in writing: (a) the non-availability of conforming ICT, including a description of market research performed and which provisions cannot be met, and (b) the basis for determining that the ICT to be procured best meets the requirements in the Revised 508 Standards consistent with the agency’s business needs.

[GreggVan]

Actually the current definition of assertion - requires no documentation. If we require documentation - then we need to define exactly what documentation is required or it is not testable. Hence - we currently only require that an assertion is made. That is quite testable because the assertion is either made or not.

what @bruce-usab is referring to - is the documentation needed if you DON'T meet a provision and want to claim that you don't need to -- or that you met it in some other fashion. That is quite different than assertions - which are provisions in themselves.

[bruce-usab]

I was responding to @rachaelbradley question:

What does “documented” mean? Available publicly or published at all?

TLDR – I am merely suggesting that for WCAG3, "documented" might not need to be nailed down.

[ChrisLoiselle]

Per the conversation on 6/3/25 in IRC:

1. How does someone publicly verify a public assertion that is based on the organization internally verifying their own assertions?
2. Verification testing - is this only used internally within organizations and entities? If assertion is not testable but is then internally verified, what is the meaning of this term in AGWG / W3C's viewpoint?
3. Assertions can be required and assertions can be supplemental ?
4. What is goal of assertions?

• To be included in a conformance report?
• If these are required, would VPAT/ ACR type of conformance reports be updated to reflect this?
• Would W3C come up with a report resembling WCAG EM that contains these assertions?
• Where would this assertion or statement live? Is it one in the same as an accessibility statement?
• Is it contained in an accessibility conformance report?
• Is it to be within an org's accessibility statement?
• Is it to be part of their organizational measures within the accessibility statement?
• Should it be part of policy?
• Should policy point toward assertions ?
• Do the assertions go above and beyond the maturity model W3C recommends?

[alastc]

Hi Chris,

It's worth reading Gregg's comment below, but to try and directly answer your questions:

1. How does someone publicly verify a public assertion that is based on the organization internally verifying their own assertions?

You can verify that they have made the assertion, you cannot verify that they have actually done the work. (Unless the person/org decides to make it public, which WCAG would not require).

2. Verification testing - is this only used internally within organizations and entities? If assertion is not testable but is then internally verified, what is the meaning of this term in AGWG / W3C's viewpoint?

I'm not sure where you get the term "verification testing" from? The assertion is testable in that you can "test" whether it has been made. The whole point of assertions is to encourage people & orgs to do things which are known to benefit accessibility, but have varied outcomes. For example, performing usability testing (with PwD) and acting on the results is beneficial, but it depends so much on context that you don't know what the results would be.

An assertion in a conformance claim would assert that some process has been followed. The organization should have some internal paper-trail to know that is the case. We can outline ways of documenting that in the informative documents.
Whilst WCAG would not require that documentation, other parts of the eco-system might (e.g. regulators). Or it might be brought to light if there were a dispute (e.g. a court case). A high-profile case where a false assertion comes to light would probably have a big impact.
I believe that other standards (e.g. security ISO 27001) are primarily internally created and non-publicly audited.

3. Assertions can be required and assertions can be supplemental ?

Let's try not to get confused with "requirements"! We need to resolve how assertions contribute to conformance, but I think a useful default position would be that you can use assertions to score in a similar way to supplemental requirements.
See slides 25-26 from the CSUN presentation.

4. What is goal of assertions?

• To be included in a conformance report?

The overall goal I put under question 2, but yes, it would be part of a conformance report.

If these are required, would VPAT/ ACR type of conformance reports be updated to reflect this?

I would assume so, but that is not our group's responsibility.

Would W3C come up with a report resembling WCAG EM that contains these assertions?

We could, although WCAG 2 didn't really include example reports or methodology from the start (2008), it essentially left it to the wider ecosystem to create these. WCAG-EM came later.

Where would this assertion or statement live? Is it one in the same as an accessibility statement?
Is it contained in an accessibility conformance report?
Is it to be within an org's accessibility statement?
Is it to be part of their organizational measures within the accessibility statement?

Again, to-be-decided, but if you create a conformance report for WCAG3, it would need to include the things you are claiming that meet the standard.

Whether and how organizations report on their accessibility isn't really our responsibility.

Should it be part of policy?
Should policy point toward assertions ?

Again, policy isn't really in our scope. An assertion might include that the organization needs a policy and/or process in place to ensure something is done, but that would be the extent.

Do the assertions go above and beyond the maturity model W3C recommends?

There is some overlap, and the maturity model is a good place to draw assertions from. For example, the model includes proof points for usability testing. Making an assertion (or assertions) about usability testing would tick that off.

I don't think there is an intent to go above the maturity model (I'm not sure what that would mean), but they could certainly include things which are not in the maturity model.

[GreggVan]

All of these questions depend on the final definition of an assertion.

There is a lot of confusion between an ASSERTION and a REQUIREMENT -- with people talking about ASSERTIONS as if they were REQUIREMENTS.

Per the original proposition -- the making of the assertion fulfils the "Assertion" requirement. If anything beyond that was testable - then THAT would be the requirement - not the assertion.

I think it is useful to demonstrate with examples the different between an ASSERTION and a REQUIREMENT

ASSERTION: - "An assertion is made that user testing of XYZ type was done"

• The ONLY test of this is that one made the assertion. No other test is required. No documentation. No verification. No impact testing.

If you WANT to test or require documentation or verification or **impact testing -- then one would not use an assertion - one would just use a simple requitement for whichever of these one wants.

REQUIREMENT "That one does user testing of XYZ type"

• the test of this would require documentation that you actually did it

OR

REQUIREMENT "That one does user testing and have internal documentation that one did.

• Test of this is that you have internal documentation

OR

REQUIREMENT: "That user testing of XYZ is done and that it have QRS Impact"

• Test of this is that it had QRS Impact.

We keep trying to attach testing to an assertion that it does not include. And if you do require more than a simple assertion - then it is no longer an assertion but a requirement.

How does someone publicly verify a public assertion that is based on the organization internally verifying their own assertions?

You don't. As soon as the assertion is made - the Assertion terms are met. If you want to require internal verification then it can be a requirement - (not an assertion) with a conformance claim that it was done and internal verification exists.

Verification testing - is this only used internally within organizations and entities? If assertion is not testable but is then internally verified, what is the meaning of this term in AGWG / W3C's viewpoint?

If you require this - then it becomes a requirement.

Assertions can be required and assertions can be supplemental ?

Confusing question. At this time the only thing we have are supplemental requirements, so there is no such thing as a "supplementaL" If you mean foundational or supplemental - I would suggest they only be supplemental for the long list of reasons posted elsewhere.

What is goal of assertions?

to get people to be aware of things they should do that are not testable and to have them get some type of credit for asserting they did something like that. (I say something like that - because if you could say exactly what THAT was - then it would be testable)

To be included in a conformance report?

Sure

If these are required, would VPAT/ ACR type of conformance reports be updated to reflect this?

Even if not required - the VPAT or ACR could be updated to allow the assertions to be included.

Would W3C come up with a report resembling WCAG EM that contains these assertions?

WCAG would need to define the possible assertions in advance to keep them from becoming trivial - if anyone could make up anything as an assertion and then get credit for it.

Where would this assertion or statement live? Is it one in the same as an accessibility statement?

Someplace public. In a conformance claim for sure. Perhaps other places.

Is it contained in an accessibility conformance report?

That is a good place. But to conform they would only have to make the assertion. No other test is needed or appropriate.

Is it to be within an org's accessibility statement?

Another good place. In fact anyplace they list their claims - or even places they don't make claims other than asserstions. not required though.

Is it to be part of their organizational measures within the accessibility statement?

Another good place. not required.

Should it be part of policy?

Another good place. not required.

Should policy point toward assertions ?

Good idea. not required.

Do the assertions go above and beyond the maturity model W3C recommends?

No - I think assertions need to go through the same stages of maturity as all other provisions.

[ChrisLoiselle]

Thanks @alastc and @GreggVan . My vote would be to have an explainer or FAQ doc that covers your answers which are included in the discussion here and relate to the slides in the Google Slides presentations.

My understanding is the slide deck was from July 2024 (when this discussion thread was formed) and the presentation last week Assertions, June 2025 along with the discussion is ongoing here in GitHub. If we are to use one as the basis to inform the other documents , please let me know. For example, if Assertions June 2025 slides will be updated with these questions and answers to have it all in a related presentation, that is fine with me.

My quote related to internal verification and testing verification came from your slide titled Examples from subgroup work (2 of 2) on the Assertions June 2025 slide deck. The word testing was specifically used thus you'd be testing internally to verify something yet an outside source would not be able to test if that information is not public. If we are to use these to "move accessibility forward" but don't have enough data for someone to validate a statement that states "we have this style guide and we use it or "we've tested for privacy concerns" , to me it comes off as a marketing aspect of "we do the right thing" and "assert". If we were to come from a perspective of whether it is a valid stance to promote accessibility in that way I guess is open for the discussion and why this issue or discussion is ongoing. It appears it depends on whether a company made an assertion but couldn't verify it publicly but only internally.

I'll leave it to the greater group to add to the discussion or include in WCAG 3 as we move forward. I just wanted to provide some insight from my perspectives of the terms used in our conversations to date.

[rachaelbradley]

I've started an FAQ on the slide deck.

[ChrisLoiselle]

Thanks @rachaelbradley , this is helpful. I do regret I have further questions. So per this slide FAQ, (understood it may be iterative in nature) , I have follow up questions:

• The assertions are supplemental yet part of a conformance report? In this context would this be similar to reporting on WCAG 2.2 A and AA but also reporting on "some" AAA within a conformance report, say from the ITI / VPAT / ACR type of template?
• In being in a conformance report, you can state you've done assertions, but it cannot be validated by a customer other than you made that statement as a matter of fact ? If one company states they've done things and a comparable company does not, are they scored differently on achieving bronze status due to not providing assertions ?
• Assertions per the slide FAQ are statements, but would be separate from accessibility statements per where assertions will be reported. Do we have a clear defined term of each of these to avoid circular references? Sorry if I've missed this.
• If policy shouldn't point to assertions as part of WCAG 3.0 scope, why would they be included only as a note ? Is it because they are deemed as supplemental and not foundational?
• If you are writing a conformance report and including assertions there, I think they would be required to be part of your policy (how you write a conformance report) or at least what makes up a conformance report
• Or are you stating the assertions are optional and supplemental and not required for a conformance statement to be generated?
• Are you looking to have assertions be part of something that ITI and the VPAT structure of reporting adopt per what we the W3C recommend ? If we are recommending supplemental to achieve a bronze and above , then it appears to me that you are requiring some supplementals to achieve a certain level of statement or achievability of accessibility (bronze level).

Apologies if I'm conflating the meanings of all of these terms. I'm trying to come from a non native user outside of the W3C walls but wanting to adopt these recommendations / best practices / guidelines.

Thanks for all your help!

[rachaelbradley]

See answers in line:

• The assertions are supplemental yet part of a conformance report? In this context would this be similar to reporting on WCAG 2.2 A and AA but also reporting on "some" AAA within a conformance report, say from the ITI / VPAT / ACR type of template?
• • Conformance in WCAG 3 is different than in WCAG 2. In order to meet the lowest level of conformance in WCAG 3 (as written now), the author must meet all the foundational requirements and some subset (To be determined) of the supplemental requirements and assertions.

• In being in a conformance report, you can state you've done assertions, but it cannot be validated by a customer other than you made that statement as a matter of fact ? If one company states they've done things and a comparable company does not, are they scored differently on achieving bronze status due to not providing assertions ?
  

• • Assuming assertions are supplemental, then one company may choose to complete a procedure such as usability testing and assert they did so, and another may chose to meet one or more supplemental requirements or another assertion to reach the lowest level of conformance. We haven't worked out how the pieces of supplemental balance each other out. That is the work for the next 4-5 months.

• Assertions per the slide FAQ are statements, but would be separate from accessibility statements per where assertions will be reported. Do we have a clear defined term of each of these to avoid circular references? Sorry if I've missed this.
  

• • That hasn't come up but we would likely call one an assertion and one an accessibility statement or add qualifiers to the assertion statement to differentiate it.

• If policy shouldn't point to assertions as part of WCAG 3.0 scope, why would they be included only as a note ? Is it because they are deemed as supplemental and not foundational?
  

• • We are not saying that policy should not point to assertions only that it is not within the scope of the standard to make policy and that because they are supplemental, they wouldn't be required. We are discussing creating a note to advise around how policy might best use into WCAG 3. One part of that might be which supplemental guidance best support which scenarios. For example, conducting a plain language review might be really important for health and emergency information.

• If you are writing a conformance report and including assertions there, I think they would be required to be part of your policy (how you write a conformance report) or at least what makes up a conformance report.
  

• • I believe we are discussing different things. If I change "policy" to "regulation" on the slides, will that be clearer?

• Or are you stating the assertions are optional and supplemental and not required for a conformance statement to be generated?
  

• • They are optional. They may or may not be included depending on what the author decides to focus on within the supplemental guidance.

• Are you looking to have assertions be part of something that ITI and the VPAT structure of reporting adopt per what we the W3C recommend ? If we are recommending supplemental to achieve a bronze and above , then it appears to me that you are requiring some supplementals to achieve a certain level of statement or achievability of accessibility (bronze level).
  

• • Likely, yes.

[GreggVan]

Good discussion.
a couple of things to ponder

RE: ASSERTIONS AND CONFORMANCE

1. we require that 'requirements' be met to meet/conform to the guidelines.

   • we do not require that you claim conformance in order to conform
   • VPATs also never claim to meet (only to support the requirements - whatever that means)

2. companies in the past - have said that they are not allowed to make conformance claims for accessibility

   • they can meet the guidelines, but are not allowed to claim that they did (see VPAT note above)

3. Assertions would SEEM to be in the same category as claims - and - unless things are changed - some companies may not allow any assertions to be made

   • this is something we need to explore and confirm or disprove very soon Much of how we proceed will depend I think on the answer

4. if we put assertions in lowest level of conformance -- and require that more than zero of them are required for conformance at that level -- we may make it impossible for some companies to conform if (but only if) some companies cannot make assertions.

RE: WILL THERE BE FORMAL WCAG DEFINED ASSERTIONS -- OR ARE THEY OPEN TO ANYONE TO CREATE THEM

a) If assertions are NOT defined by WCAG-WG then anyone can make them up.

b) if anyone can make them up -- then we cannot use them on conformance since

• we do not know what they might be so we can't determine their importance
• people can make up trivial assertions and add them up for higher level of conformance making higher levels of conformance undefined (as to quality) if not meaningless or less meaningful.

c) we could have Official and Unofficial Assertions

• Official - are defined by WCAG-WG (in a document aside from WCAG so they can be updated and added to over time)
  - these are used in determining higher levels of conformance
• Unofficial - are those defined by anyone about anything
  - These are recorded/claimed separately
  - they are not used to determine higher levels of conformance
  - but they can be useful additional information that an author adds to their claim to make it richer and to reflect and have people see any extra effort they have done.

[mraccess77]

In the past we have said it's possible to conform to WCAG without making a conformance claim. We should continue with that model in my opinion. This means assertions need to be possible outside of conformance claims. I find most organizations currently don't make formal conformance claims because many assets may not be fully conformant. However, showing progress toward conformance is important. This way organization who don't fully conform could still show effort toward assertions by putting those assertions into criterion that are met or not met.

[detlevhfischer]

@rachaelbradley

We need to resolve how assertions contribute to conformance, but I think a useful default position would be that you can use assertions to score in a similar way to supplemental requirements.

Has there been any other place where the mix of assertions and supplemental requirements has been discussed in more detail? (I just looked at the discussion threads and saw no obvious contender.) I still think the idea of scoring by making assertions or a "mix of supplemental" somewhat dubious.

The CSUN slide deck indicates that the choice of additional supplemental requirements needed to reach the base level may depend on the subject nature of the content (like "health"). Does that indicate an additional chunk of requirements that would need to be met in total to achieve conformance, for that sector? Or is is really "pick and choose"? (and throw some assertions in?)

I personally would prefer to see meeting all foundational requirements equate "bronze".

[rachaelbradley]

::chair hat on::

@detlevhfischer We discussed this as part of last year's conformance conversations but not at the level we need to in order to reach consensus on the detailed approach.

The question of exactly how the supplemental requirements and assertions will be selected is part of the conversation we need to have as soon as we have a list of requirements and assertions to inform the conversation (hopefully we will start that conversation in July).

The concern raised with bronze = foundational requirements is that it replicates the A/AA & AAA model which does not provide the flexibility that bronze = foundation plus some amount of supplemental does. There are concerns about the opposite approach as well and those are what we need to discuss and address regardless of the solution that is pursued. I have put together a discussion to capture questions and concerns about each approach.

[GreggVan]

The pull request seems to say the following which I think are problematic

1. to make an assertion you need to make a full conformance claim.

• Companies may be able to make assertions who cannot make full conformance claims. Also an assertion could be made generally for a company -- separate from conformance claims for particular products or sites

2. there is a comment about "W3C plans on providing an assertion statement generator that organizations may use to create properly formatted assertions, though it use will not be required in order to meet conformance."

• I thought we were going to define the assertions - and not allow companies to make up their own. If W3 doesnt make them - then how would we give credit for assertions. Companies could make up anything and we/they would not know how to weight them as important or trivial or non-consequential.

3. it says that they will be at all levels. We never decided that I know of that they would or could be at the lowest level. Nice if they could but if companies can't make assertions -- then that would me that companies couldnt conform. We already know that some have said in the past that they could not make claims - and assertions are similar. Maybe change this to "are being considered at all levels of conformance "
4. it says "Assertions may be used, in addition to Requirements, to meet a Guideline. Not all Guidelines include Assertions. Guidelines that include Assertions list the Assertions with the Requirements." You don't meet guidelines. They are just general statements or goals. They are mostly not testable so you can't meet them. You meet the requirements under them. Assertions can help "address" or "support" guidelines but not meet them. No?

[rachaelbradley]

Based on this and Kevin's comments in the PR, we have the following for discussion tomorrow:

• What would it look like for an organization or individual to make an assertion separate from a conformance claim?
• Should W3C provide a statement generator? I believe the suggestion for this wasn't that anyone could claim anything.
  -- To clarify this suggestion, rather that an organization could use a generator to create a properly formatted assertions based on the W3C specified options.

[rachaelbradley]

I've updated the PR to address some of these comments.

[GreggVan]

if assertions are limited to process (which seems to be our current path) then it might be good replace "process assertions" everywhere instead of "assertions". It will lead to much quicker understanding and uptake of the new term and reduce misunderstanding -- since most people will not look up the definition and just try to think / talk about making assertions about content.

I think it will get us where we want to go with this new term/concept faster and with less misunderstanding

[mbgower]

if assertions are limited to process (which seems to be our current path)

This makes sense to me. Do we have examples of assertions that are not, at their core, processes?