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

> On Dec 9, 2025, at 4:25 AM, Lisa Seeman <lisa1seeman@gmail.com> wrote:
> 
> What is hugely missing here, is that 2.x failed to support all disabilities.

Hi Lisa

I agree that cognitive needs to be our top priority in WCAG3 

But I  wish you would stop saying that 2.x failed to support all disabilities or failed to work as hard on cognitive. 

If you mean just mean that WCAG2 does not solve the problem for people with all disabilities, no one disagrees with that. We even have that written directly into the preamble of WCAG2 that that is true. And it is true for individuals with every type of disability.

If you mean that cognitive was given short shrift - that is not true.  And it does not help anything to keep asserting it.

 There are more provisions for cognitive than there are for most any other disability.   The problem is that there are many things that people with cognitive disabilities need that we have not been able to provide solutions for.  AND the fact that we did not have good cognitive AT in the past.   Not that it was not worked on or felt to be important. 

If you look - you will see that blindness has very few provisions dedicated only to people who are blind.  
There are many provisions for making content accessible to assistive technologies (but those work for all assistive technologies or all disabilities - including cognitive).   
The only reason that AT compatibility provides accessibility for some who are blind - is that they bring their own AT to bear and the AT makes the pages accessible.   
 The same approach has and can be used for cognitive. 
Some provisions provide direct cognitive access 
and a many more allow cognitive access via Assistive technologies.   Especially now that we are getting better cognitive AT

(Note that the provisions often attributed to access for blind do not cover all people who are blind either.  
They only work for those who are blind and can deal with complex things like screen readers.   
I know many blind people who cannot use screen readers — and have no access to web content either.

John Slatin did two studies, I  id one , and Alastair did one — and all of us found that there were not fewer cognitive provisions than other groups, but actually more if you evaluate them with the same criteria (direct vs via AT).

I DO agree - that we there are critical things that are needed by people with cognitive disabilities that we have not been able to figure out how to make requirements for.  
Testability and threshold are both problems that have prevented us from having more requirements.
(The whole reason I  am working on WCAG 3 in retirements is that I am trying to figure out how to get more good guidance for people with cognitive disabilities into WCAG 3.    
And I  am also in my retirement working on an alternate approach that would be really great for people with cognitive disabilities.   One that would remove/solve both the testability and threshold issues. 

By “the threshold issue" I  mean the following.   
Just for discussion sake, let's say all people with intellectual disabilities, fell into five levels. 
If we could find a measure of simplicity (of text for example)...
which level of simplicity should we require  (what level of simplicity would be what was required?)
If you said 3, then people who were 4 and 5 would have to use text that was simpler than what they need (and they would have to be losing the information between level 3 and the level they were able to handle. 
And the content would still not be simple enough for people at levels 1 and 2. 
So do we discriminate against levels 1 and 2 and leave them behind?  (and simultaneously force levels 4 and 5 to use oversimplified text?)

Also, (as we have all experienced) once we understand something at a simple of a we can often understand it at a more complex level. How many times have you not understood something until someone said "let me give you a simple example”.   Then, once you've seen a simple version of the concept, the broad or more complex idea they were trying to express is suddenly clear. 
Thus, even for a single person there is no correct level of simplicity. 
There is the level that is needed for them to understand something new, 
and then there is a different level that they can handle once they understood it at the simpler level or if they are already familiar with the concepts.

I suggest that a much better approach 
is to work to have it so that each user can adjust both the language level — and in level of inteface complexity - to whatever level they need.
and this would be done at the user agent level (browser or AT) so that it could be set by the user and used across websites
and would allow users to select the type of interactors that they prefer and have consistency not just in a website but across websites

I think we should push for smart assistive technologies or smart browsers 
that can take whatever the content is on the page and present it to the individual at whatever level they need to be in order to be understood. 
This would not only eliminate the need for us to have a "testable" level of readability or consistency (which I think we will never have) 
but also eliminate the threshold problem described above. 
It would allow individuals to be able to adjust the text to whatever level works for them. 
Moreover they could do it dynamically 
so that they would only have to ask for simpler versions of pages that they had trouble with, 
and would only have to simplify sites as much as they needed to to understand it. 
Also, as noted above, once they understand the site basically,  they may be able to turn the complexity up to a higher level and still understand the site more completely.

This is the equivalent to having AT for someone who is blind or has low vision 
and has the ability to adjust the magnification to what they need but not more 
or to adjust the reading speed or other factors to be matching what they need but no more.


> The only way we as a group felt we could make this style of  conformance work was by not requiring equitable inclusion for all the groups who need inclusion.

This is true.  But it is not cognitive vs physical vs blind.    
There are people in all ’types of disabilities that cannot use content that meets WCAG. 

> The result is millions of people need "help" from a support person to use sites and content that are labeled as accessible.

Yes - I agree — nothing should be labelled as accessible.  
It should only be labeled as conforming to the minumum accessibility standards. 

> The conformance proposal in WCAG 3 fourses policy makers to decide what groups they are giving accessible content to on a basic level and on a usable level.

Do not understand this sentence.     
I don’t understand how the standard forces policy makers to make any decisions about which groups they are supporting.   The standard is fixed - there is no deciding among groups by policymakers that I  know of.  Can you explain what you mean here? 

> Clearly they should give all levels.

Do not know what you mean by "they should give all levels “.   
Do you mean that each page should be presented in all levels of complexity? 
Since cognitive disabilities are a continuum and many dimensional this would sound like every page would have to be presented many times over in different forms. 
Again, I think the way to solve this problem is to have tools that can present the content to the person in the form that that particular individual needs it.    Note again that if users can adjust websites to the level they need — , there is no need for testability and no need for any particular threshold to be chose as "good enough”.

> Many sites, like critical service providers may now give full inclusion.

I do not believe that there is any site that gives full inclusion. 
That is,  there is no site that is accessible to all people with all types degrees and combinations of Disability. 
So I'm not quite sure I understand your sentence or what you intend here.

> But if they dont, at least we are not making a global choice on their behalf, and telling them they did a good job whilst they leave out  millions of the most vulnerable. 

I don't understand this sentence. 
Can you explain what you mean?

> Please do not take a step backwards. 

I don't see anything that I have been proposing here, or in any of my comments or posts as being a step backwards. 
They are all intended to move us forward … and to find things that will actually work and actually be adopted and actually increase the accessibility of websites, especially to people with cognitive language and learning disabilities. At least that's my intent and the whole reason I'm working on WCAG3.

It is also the reason why I am pushing for the alternate approach to accessibility (Users being able to use AI and advancing tech to have each web page/process presented to them in the form that is best, most familiar, and easiest for them to use. 
And because this approach does not require testability or thresholds, neither of these are barriers to using any or all of the strategies that the various coga groups and individuals have been proposing.   And then - the limits to what is accessible will be the limits of what we know about how to make content accessible to each and every individual with their individual type, degree, and combination of disabilities.

All the best.

Gregg 

PS — please do not confuse someone who is pointing out holes in something — as someone who is punching holes in them. 
They are only pointing to the holes that are already there.   
Imagine we are launching a new boat.  (a new Accessibility Boat).    
If there are holes in the boat -we WANT people to point them out before we launch.   
They are not punching holes in the boat.  They are only pointing to things they think are holes.   
If they turn out to not be holes — no harm.   
If they are holes and we can patch them.  (Better to do that before launch.)  
It will do no good to launch the boat if it won’t float.   Even if it does have lots of great features. 

I am only trying to identify holes — and as much as I  can – also suggest solutions. 

> 
> On Tue, Dec 9, 2025 at 8:42 AM Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
>> 
>> 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/views <https://w3c.github.io/wcag3/guidelines/#dfn-view> and processes <https://w3c.github.io/wcag3/guidelines/#dfn-process>.
>> 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://docs.google.com/document/d/1OovuPqLH1xEzUPmhVgYT3rYclvbb0oVpgVAlGZGkO3E/edit?tab=t.0> 
>> and each question can be referenced with unique URLS  (see side panel)
>> 
>> 
>>