Re: Comments on new conformance section -- for consideration.

Hi Sailesh,

> The content may be absolutely fine for certain groups of PWD users but still pose problems for other PWD groups.

I think it's safe to say this will always be the case, today in WCAG 2, and also in WCAG 3. It's not great, I don't think anyone is a fan of it specifically, but I'd say it's all we can reasonably do.

> So will a conformance report that brings out such an opinion not be more useful? 

In many WCAG 2 reports, evaluators do detail which issues affect which groups.

Requirements in the current draft of WCAG 3 have been tagged with functional needs categories, this should make it easier for evaluators to include them in their reporting too. 

I'm not sure if I understand what you propose, it seems to be what you're describing is compatible with the proposed conformance approach. Can't “a single statement that records pass/fail judgment” (I'm assuming we're talking passing/failing conformance with WCAG) co-exist with also making it straightforward for evaluators to describe functional limitation groups?

Best,
Hidde

> On 10 Dec 2025, at 17:05, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> With WCAG 3.0, there is a need to advance from the  WCAG 2.X mindset.
> See: https://github.com/w3c/wcag3/issues/419
> 
> So how is the conformance process  expected to help users - I mean PWD users, regulators and all other stakeholders?  
> Will a  single statement that records pass/fail judgment on the scope of content under evaluation be sufficient?
> Will it be better if that judgment is associated  with functional needs? 
> The content may be absolutely fine for certain groups of PWD users but still pose problems for other PWD groups.
> So will a conformance report that brings out such an opinion not be more useful? 
> Please consider the view proposed on Nov 14, 2025: WCAG 3.0: Conformance model - a different view.
> It is at
>  https://lists.w3.org/Archives/Public/w3c-wai-gl/2025OctDec/0059.html
> Also see the last post in the thread (so far) of Nov 20.
> 
> The thread also reflects on the role of assertions:
> https://lists.w3.org/Archives/Public/w3c-wai-gl/2025OctDec/0057.html
> Thanks very much,
> 
> 
> 
> Sailesh Panchang  
> 
> Email: sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com>
> Deque Systems Inc | - Accessibility for Good | www.deque.com <http://www.deque.com/>
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Dec 9, 2025 at 8:59 AM Bradley Montgomery, Rachael L <rmontgomery@loc.gov <mailto:rmontgomery@loc.gov>> wrote:
>> Gregg,
>> 
>> Discussion points 1-3 are best addressed as part of the conformance subgroup to inform a different proposal. We decided to move forward with this particular proposal for this draft in part to get additional feedback from regulators and companies about these points as not everyone agrees with your statements.    
>> 
>> I don’t believe we included points 4 and 8 in the draft <https://docs.google.com/document/d/1b9g5v5Hh_Z5lFRVl3hO0Q45amG7X7KVOgVbJA_m4we8/edit?tab=t.0>. Can you point me to what you want changed to address this?
>> 
>> Let’s discuss points 5 and 6 in today’s meeting. 
>> 
>> For discussion point 7, can you suggest changes to the draft section of 3.2.3 <https://docs.google.com/document/d/1b9g5v5Hh_Z5lFRVl3hO0Q45amG7X7KVOgVbJA_m4we8/edit?tab=t.0#heading=h.9dikrwdq8ja>  <https://docs.google.com/document/d/1b9g5v5Hh_Z5lFRVl3hO0Q45amG7X7KVOgVbJA_m4we8/edit?tab=t.0#heading=h.9dikrwdq8ja>to address this concern?
>> 
>> For Discussion point 9, can you bring the references to the lists you mention to today’s meeting? For this draft, we need some list to work from though it can change or be removed in a future one.  Functional performance criteria are not sufficient.
>> 
>> Thank you,
>> 
>> Rachael
>> 
>> 
>> From: Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>
>> Date: Tuesday, December 9, 2025 at 1:42 AM
>> To: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
>> Subject: Comments on new conformance section -- for consideration.
>> 
>> CAUTION: This email message has been received from an external source. Please use caution when opening attachments, or clicking on links.
>> 
>> 
>> Thoughts on Conformance Section of Draft WCAG 3
>> Gregg Vanderheiden 
>> 08-Dec-2025
>> (subject to change and revision at any moment based on
>> Discussion with other WCAG members)
>> 
>> 
>> Great to see this coming together so we have something concrete to work from.
>> 
>> Some thoughts as we move forward.
>> 
>> 
>> Preamble
>> 
>> If CORE are the ones you must meet - then these seem to be the ones that would be essential for accessibility.
>> 
>> If Supplemental - are optional — they are not required - (and therefore not essential).   
>> 
>> sometimes they are things to meet for higher levels of “award” or “recognition”.
>> 
>> 
>> Sometimes they are discussed as  “pick from list - you must do x% of them”
>> 
>> 
>> Which seems to make them  “optional requirements"
>> 
>> 
>> 
>> 
>> 
>> Discussion Point 1  -  “Optional Requirements” Is Contradictory
>> Any time you have a "pick from list - you must do x% of them”  by definition you have said that none of these are essential for accessibility.   So none of them should ever be considered for base conformance (e.g. Bronze) or something that should be required (because - by definition none of them are required 
>> 
>> you just said any one of them can be skipped and you still meet base conformance
>> 
>> 
>> so none of them are really essential
>> 
>> 
>> so we should not be requiring any of them in base conformance
>> 
>> 
>> This is to be used in “civil rights” type regulations - where you need to do these or else you are discriminating.  This is not a “well we want you to make X amount of effort. 
>> 
>> Items either are essential as minimum requirements or they are not required.  They are extra things above base conformance.
>> 
>> 
>>  
>> Discussion Point 2  -  Include “More Important” Things In Supplemental
>> If “Supplemental" are above base conformance (see point 1 as to why they would be) then it seems that testability is less important than impact. 
>> 
>> perhaps supplemental should include really important non-testable recommendations in addition to testable recommendations (since they are not required they would be recommendations ) 
>> 
>> 
>> We have a lot of cognitive, language, and learning disability recommendations (they are non-testable) that are more important than some of our testable recommendations/requirements. 
>> 
>> 
>> This would give us
>> 
>> 
>> Requirements  (what you need to do to conform.  What we believe are essential for a minimum level of accessibility. 
>> 
>> 
>> Recommendations - supplemental things you can do beyond conformance to get recognition for higher level of effort
>> 
>> 
>> these can be testable or not since they are not required. 
>> 
>> 
>> Assertions - to highlight the importance of building process into accessibility — and to give additional credit to those who implement the processes
>> 
>> 
>> 
>> 
>> 
>> Discussion Point 3  - LEVELS
>> Do we need levels of conformance?
>> 
>> In WCAG 2 we had levels of conformance ONLY because that was the only way we could get consensus.
>> 
>> 
>> The vast majority of the working group really wanted to just have 2 levels   
>> required and recommended like almost every other standard.
>> 
>> 
>> However half the group wanted AA to be merged with A and the other half wanted it to be pushed to “recommended” (AAA).  
>> 
>> 
>> So we ended up with 3 levels- and let regulators decide it A would be required  or   A + AA
>> 
>> 
>> It is not clear that we need more than 2 levels  (a shall and a should ) — or that we can even support more than one shall “level” 
>> 
>> Any use of levels will introduce at least a years delay as we debate which requirements are “required” and which are not required (recommended).
>> 
>> 
>> It also means we are asking different jurisdictions to have different levels - breaking up harmonization.
>> 
>> 
>> And since the web is not local - the effect of having different levels in different jurisdictions-  is that authors would have to follow whichever jurisdiction included the most requirements. 
>> 
>> 
>> 
>> 
>> Discussion Point 4 - DO FIRST is not equal to MOST IMPORTANT 
>> (and should be separate activity from Guidelines )
>> 
>> It has always been a good idea to have some advice about where to start
>> 
>> However this is usually not  
>> "start with the most universally important ones”
>> 
>> 
>> For beginners - it is probably a list of things that are easy to do and do not require a lot of technical knowhow
>> 
>> 
>> things that are build into almost any authoring tool as a feature (like alt text, contrast, ability to zoom, etc.) 
>> 
>> 
>> and usually things that can be detected / checked easily by tools
>> 
>> 
>> and wonderful if they can be repaired automatically- or automatically with human assistance
>> 
>> 
>> this is gamification  (starting with simple, easy to understand, easy to win/succeed right away - and get harder as you go forward.)  Early success reduces abandonment.
>> 
>> 
>> For specific content/contexts
>> 
>> 
>> some provisions may have more impact than others
>> 
>> 
>> this does not make the others optional (that is, they are not supplemental ones you can skip) because if they re required for accessibility — they are required for accessibility in this context as well for some users and some content 
>> 
>> 
>> (remember that if that type of content does not exist in this context - the provisions are automatically satisfied so there is no problem in including them)
>> 
>> 
>> it also lets one emphasize some recommendations 
>> (testable or not) that may be highly important in this context
>> 
>> 
>> For bulk new content (or newly tackling bulk old content)
>> 
>> 
>> you have to start somewhere  so good to have advice for new people doing this  (or for support to companies trying to handle this)
>> 
>> 
>> Some things that MIGHT affect the order to be recommended
>> 
>> 
>> Things that can be auto-detected
>> 
>> 
>> Things that can be auto-repaired?  or  Auto-human repaired?
>> 
>> 
>> Things that are dangerous to not fix
>> 
>> 
>> Things that are showstopers  (though remember that usability for one person is showstopper for someone with more severe disability
>> 
>> 
>> But in all cases - the overall ORDER for starting out is determined by more than just importance.   Remember that if it is required — it is by definition essential  (not optional)
>> 
>> This also does not have to do with conformance.  Nor with the guidelines and how they are organized
>> 
>> it is just a “where to start”  
>> 
>> 
>> it is an education and outreach — informative - type of document - that should be separate from the standard.
>> 
>> 
>> there should be a growing collection of them for different situations/ fields / contexts/ content types
>> 
>> 
>> And they will change over time as new tools are developed — especially AI based ones
>> 
>> 
>> it is highly likely that things that were difficult in the past can be automated  - or automated and human checked soon
>> 
>> 
>> and after that - things that need to be human checked will be able to be automated with
>> higher quality results than 80%, then 90%, then 95% of human fixers
>> 
>> 
>> So they should always be informative - and always be updated periodically.
>> 
>> 
>> 
>> 
>> 
>> Discussion Point 5 - Accessibility Supported must be defined
>> 
>> Today this is a loosely defined provision and no way to test it (since it is not defined.
>> 
>> Suggested definition
>> 
>> Accessibility Supported:   supported by the 
>> WAI List of Key Assistive Technology and User
>> Agent features. 
>> 
>> 
>> this is a periodically updated list of 
>> 
>> 
>> KEY AT features that represent required features of AT that represent the spectrum of disabilities 
>> 
>> 
>> Key accessibility features that are supported by all 4 of the 4 most popular free browsers
>> 
>> 
>> If a reference tool is created that can be used to test compatibility of web pages for compatibility of the specific features of the above named AT and User agents - this would go a long way toward making it possible to test for Accessibility Support - and
>>  also cause a bit more harmonization across AT as to what they require for Accessibility Support.   (It would also help in development of both new assistive technologies since they would know what to target — AND — more accessibility features across browsers 
>>  and a reduction in the work of authors.  
>> 
>> 
>> it can also encourage both AT and browsers to fix bugs that cause their features to not work up to the defacto standard the test tool would create.
>> 
>> 
>> It will be important to have regional WAI Accessibility Supported Lists
>> since different regions/languages may use very different AT  (or have only limited AT that will work in their region).
>> 
>> 
>> NOTE:  it is not every feature on every AT that has to be supported. Only those required to meet the WCAG requirements  (though that will usually also mean it will work with all or almost all of the other features on the AT) 
>> 
>> 
>> 
>> 
>> Discussion Point 6 -  Avoid Authors creating their own Accessibility Supported definition / list
>> 
>> It is unclear what sense it would make for authors (or any other place except a single authoritative place )  to create their own lists. 
>> 
>> there is a need for regional lists — but there should only be one for each region— and registering it with WAI as the single source is the best way for people to find the right regional one  
>> 
>> 
>> Having more than one list for a region - means that our provisions instantly become untestable - since there are more than one answer to whether something conforms depending on which list you chose to test it.
>> 
>> 
>> And having the author say which one to use makes no sense - since users are the ones that need to rely on things working with their AT and if it changes from site to site…. they do not know which AT will work work where.
>> 
>> 
>> 
>> Custom lists should only be supported in very limited closed contexts where all of the following are true
>> 
>> the web content cannot and is not ever viewed outside of the context
>> 
>> 
>> All users in the context are known to use only AT that is on the Accessibility support list
>> 
>> 
>> This is only fair if any AT a person in the context needs is added to the list so that being forced to use things on the list does not force them to use non-optimal AT for them
>> 
>> 
>> 
>> ( Note: Since this is a closed environment - it would also mean that an abbreviated list of requirements could be used — one that only included requirements for the types of content that are used in the closed context (since the other ones are all satisfied by not relating to any content used in the closed context)
>> 
>> In short - this is such an edge case — and it likely to lead to misuse that it should basically be dropped as a documented option.
>> (RE example of concern about misuse:  someone joins the company/context who needs an AT not on the custom list — which would mean they would be forced to use what is on the list or the list would have to be updated and all existing content retested with the new list - which is not likely to happen)
>> 
>> If different groups would like to propose their own accessibility supported lists - that is great.  they can be submitted to the WAI for vetting to either update the WAI’s existing lists — or to add another regional list to the collection. 
>> 
>> 
>> Discussion Point 7 -  Scope of Conformance and Unit of Evaluation
>> 
>> Unit of evaluation and scope of conformance are sometimes confused.
>> 
>> The unit of evaluation is almost always specified in each requirement.  
>> 
>> It may be each page, or a set of pages, or individual elements on a page.  
>> 
>> 
>> There is also a special unit of evaluation “processes” that are not specified in the requirement - but rather in the conformance section - which states that whenever there is a process, no part of the process is deemed conformant  if all of the parts of the
>>  process are not conformant. 
>> 
>> 
>> This is not defined by the author but by the WCAG requirements (and conformance)
>> 
>> 
>> 
>> The scope of conformance - is defined by that author.
>> 
>> it is more properly called the “scope of the conformance 
>> claim”  since it defines what scope (which pages for example, or which sections of a site, or which site(s)) the conformance claim refers to.
>> 
>> 
>> the current draft defines two ways to define scope:  
>> pages/ <https://urldefense.com/v3/__https://w3c.github.io/wcag3/guidelines/*dfn-view__;Iw!!EDx7F7x-0XSOB8YS_BQ!Zf17G2Et4cX4746v5b9aJpnyaMjYPWHpF_Dx57VFb4doAbMEeiPKRpPOGJZzZt2aXoyiL0_ba0JQfthAZAP4fIE$>views <https://urldefense.com/v3/__https://w3c.github.io/wcag3/guidelines/*dfn-view__;Iw!!EDx7F7x-0XSOB8YS_BQ!Zf17G2Et4cX4746v5b9aJpnyaMjYPWHpF_Dx57VFb4doAbMEeiPKRpPOGJZzZt2aXoyiL0_ba0JQfthAZAP4fIE$> and
>>  <https://urldefense.com/v3/__https://w3c.github.io/wcag3/guidelines/*dfn-process__;Iw!!EDx7F7x-0XSOB8YS_BQ!Zf17G2Et4cX4746v5b9aJpnyaMjYPWHpF_Dx57VFb4doAbMEeiPKRpPOGJZzZt2aXoyiL0_ba0JQfthA6SJoYrM$>processes <https://urldefense.com/v3/__https://w3c.github.io/wcag3/guidelines/*dfn-process__;Iw!!EDx7F7x-0XSOB8YS_BQ!Zf17G2Et4cX4746v5b9aJpnyaMjYPWHpF_Dx57VFb4doAbMEeiPKRpPOGJZzZt2aXoyiL0_ba0JQfthA6SJoYrM$>.
>> 
>> 
>> It should be a bit clearer that one cannot make claims about page/views in a process but where processes exist - the scope must always include all pages in the process.   
>> 
>> 
>> it currently says “all steps in process must be included but does not define what  a “step” is.    Suggest changing  “steps”   to  
>>  “page/views”. 
>> 
>> 
>> 
>> 
>> Discussion Point 8 -  Sampling, Bugs, and other standards and techniques for bulk evaluations should NOT be part of WCAG
>> 
>> What constitutes a sufficient test of a site or scope of conformance should not be part of WCAG
>> 
>> WCAG should provide the ruler to determine what is or is not accessible.
>> 
>> 
>> what is acceptable for testing a site should be left to either testing or regulatory bodies
>> 
>> 
>> it is likely that more or less rigorous testing will be specified for different types of content  (training, archival, etc.)
>> 
>> 
>> this also applies to acceptable delays before conformance when faced with large quantities of new content 
>> 
>> 
>> time to repair bugs  falls in this category as well.   Everything has bugs.  How serious a bug should be allowed and how long it should take before remediation once reported are regulatory issues - not WCAG issues
>> 
>> 
>> All of these topics are topics for regulatory bodies - not WCAG.    
>> 
>> 
>> the comments in 3.2.3 around large amounts of content,  frequently changing content, 
>> - should be removed and put into a separate  “recommendations to policy/regulatory bodies”
>> 
>> 
>> Comments about “importance to majority of users should be used in setting the requirements — but should not appear in the WCAG since it sounds like authors should judge themselves which content is most important  and only
>>  make those accessible (or - since this is in the conformance scope section) it sounds like they should only include the content in their scope of conformance that  they think is/are most important to most users.
>> 
>> 
>> it reminds me of a different but related problem where the state that kept claiming their websites were accessible to people with disabilities because all the pages about services for people with disabilities were accessible (as if people with disabilities
>>  did not have any use for the rest of the state's websites )
>> 
>> 
>> 
>> 
>> 
>> Discussion Point 9 -  Functional Limitations
>> 
>> There are more than a dozen different taxonomies that could be applied to the requirements and recommendation.   I do not think we should have any of the baked into WCAG
>> 
>> instead WCAG provisions should be tagged and “DIV-ed” (if you will)  so they can be universally pointed to and easily extracted in their whole buy other tools that can sort and filter them in different ways for different uses.     
>> 
>> 
>> The functional limitations list in the current draft is completely out of balance.  
>> 
>> It breaks some areas down into 5 areas while other are are represented by 1 or 2.   And even the 5 area breakdown is incomplete.  
>> 
>> 
>> There are much better taxonomies but they are understandably more complex as well.   
>> 
>> 
>> Both simpler and more complex taxonomies should be supported — 
>> 
>> 
>> as well as taxonomies that are along completely different dimensions. 
>> 
>> 
>> 
>> 
>> 
>> The 4 questions
>> 
>> 
>> Should the core set of requirements be approximately the same as WCAG 2.2 A & AA?   
>>   
>> 
>> 
>> If not, should it be smaller or larger?   
>>  
>>  
>> 
>> 
>> GV: it should be larger. 
>> 
>> 
>> If you think it should be a different size, what rules would you use to select the set? 
>>  
>>  
>> 
>> 
>> GV: It should have all of the A & AA that we think relevant.  Plus any new ones that we think are relevant
>> 
>> 
>> BUT it should be much less work because maybe half of the provisions will be able to be met using smart browsers and more smart AT
>> 
>> 
>> 
>> 
>> Should we include assertions within the core set? 
>> 
>> 
>> Would companies be willing to make public, attributable assertions about processes they completed?
>> 
>> 
>> GV: Not if some companies cannot make assertions.  This is a legal thing - and in the past we were told that some companies could not make them. 
>> If this is still true, then putting assertions in the core would mean that it was not possible for those companies to ever conform.    
>> 
>> 
>> 
>> 
>> Should there be additional levels within the core set of requirements? 
>> 
>> 
>> If yes, what and why?
>> 
>> 
>>     GV: No.   the core is what we think are the minimum requirements for accessibility.   Levels within it have no meaning since you cannot conform if you don’t meet the minimum.     Also see my other comments above. 
>> 
>> 
>> What is the purpose?  (see comments above)   
>> 
>> 
>> 
>> 
>> In WCAG 2, every provision within the minimum conformance level has to be met to conform at the lowest level of conformance. 
>> 
>> 
>> To conform at the lowest level in WCAG 3, every provision within the core set must be met AND then additional effort must be done to better support people with disabilities but WCAG 3 allows some flexibility
>>  on what and how that effort is provided.  
>> 
>> 
>> Does this approach work or would a stricter set of requirements with more flexibility within the methods be a preferred approach?
>> 
>> 
>> GV: core + additional effort does not make sense.
>> 
>> 
>> As discussed above
>> 
>> 
>> 1) The basis for regulations are civil rights.  Thus you need to do these things to meet minimum accessibility.
>> 
>> 
>> This is not a “we want you to put in so much effort”.  There is no legal basis for “requiring effort”.   (there is some basis for no requiring things that are too much effort - but that is a completely different thing)
>> 
>> 
>> The goal is to make sites accessible — not to force companies into a certain level of effort.  
>> 
>> 
>> 2)  As above - as soon as you have  “pick from list”  you have admitted that nothing in the list is important enough to require.  They are all optional.  
>> 
>> 
>> A site is accessible (meets minimum accessibility standard) without conforming to any one of them.  
>> 
>> 
>> If they are all optional, then they are all "not essential”.
>> 
>> 
>> If they are not essential for accessibility - then they should not be required at all.   (maybe extra credit or extra recognition - but not part of “essential for accessibility” requirements. 
>> 
>> 
>> Note: All of the “shall” or “must” or the equivalent provisions in any standard - are always required for conformance.   They are not “shall” if they are not required.     
>> 
>> 
>> if there is a choice of one or another thing - then they are put into one SHALL that says  “you shall do this or that” (where there are two ways to address a problem)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> FOR CONVENIENCE this content is also on the web at  this location <https://urldefense.com/v3/__https://docs.google.com/document/d/1OovuPqLH1xEzUPmhVgYT3rYclvbb0oVpgVAlGZGkO3E/edit?tab=t.0__;!!EDx7F7x-0XSOB8YS_BQ!Zf17G2Et4cX4746v5b9aJpnyaMjYPWHpF_Dx57VFb4doAbMEeiPKRpPOGJZzZt2aXoyiL0_ba0JQfthAGiIEDpE$>
>> and each question can be referenced with unique URLS  (see side panel)
>> 
>> 
>>