- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Fri, 12 Dec 2025 14:38:22 -0500
- To: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
- Cc: "Bradley Montgomery, Rachael L" <rmontgomery@loc.gov>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, Hidde de Vries <hidde@hiddedevries.nl>
- Message-ID: <CAJi9Cqq4e9=juuDKe7H1n0GEu7tMx3_iOrjHVzqPfLvNGaTRjA@mail.gmail.com>
Sir, I respectfully submit: 1. My email above does not suggest that the conformance report / claim state how well a page meets a particular functional need. The measurement will still be with respect to the guidelines and requirements and the result will reflect only that. No more. The functional needs are merely a grouping mechanism for the requirements / criteria set out in WCAG 3.0. The satisfied / partly satisfied / Not satisfied result against a particular functional need only indicates the result of testing the related requirements listed in WCAG 3.0. If all requirements corresponding to a functional need pass, the result is "Satisfied". As previously clarified, a requirement may be associated with more than one functional need and the result for a different functional need may be "partly satisfied" because not all requirements for that need pass. 2. True, an individual may have more than one functional need. In that case for that individual, the results against all applicable needs will have to be considered. The statement from the WCAG preamble will surely still apply: "Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability" ... as noted in WCAG 2.X. 3. Nor have I ever suggested that authors should be trying to pick and choose among the guidelines to decide which ones are important or not. [This might happen with the bronze-silver-gold rating scale (as per my understanding so far)because the rating depends on meeting specific percentages of certain requirements]. Yes, the endeavor will be to meet as many if not all requirements. Once done with the dev work for the present time, the evaluation might reveal gaps against specific functional needs if the suggested functional-need based conformance report is adopted. 4. Furthermore, digital accessibility does require access to supported user agents/ browsers and assistive technologies. So a user with a disability who does not use a required / supported AT will always encounter a barrier. Without employing a screen reader a blind person would not be able to access digital content, comprehend structure or text equivalence even when the content has been developed using the FAST framework. Thanks and best wishes, Sailesh Panchang Email: sailesh.panchang@deque.com Deque Systems Inc | - Accessibility for Good | www.deque.com On Wed, Dec 10, 2025 at 7:13 PM Gregg Vanderheiden RTF < gregg@raisingthefloor.org> wrote: > I don’t think one can ever make a comment about how well a page meets a > “functional” group — and it is also mostly meaningless. It implies that > people have just one “functional” limitation. So if you have muiltiple > limitations you don’t fit purely into any group. So we would only be > reporting on how accessible the page was for the limitation - not for any > group (or else you are just reporting on how it is covered by individuals > with "pure" singular limitations) > > For example, one might feel that One had a page that worked well for > individuals who had the functional limitation of blindness, but they > would've left out everyone who has any type of hearing disability, physical > disability, cognitive language, or learning, disability, etc. In fact, > there are many individuals who are blind, who are unable to use screen > readers, or the screen reading capabilities in smartphones at all. So all > of the things that we do that we think would make it accessible to these > people do not make it accessible to people with that functional limitation > at all. > > I think the functional limitation aspect is of little or no real use in > the guidelines. If we are worried about making sure that we have guidelines > that cover all functional areas, that is fine. We can use the functional > limitations to help guide our work. However, I wouldn't use this shortlist, > I would use something more like the FAST list to see if we've covered all > of the different needs. Or better yet the long list of needs that were > generated as part of the WCAG3 works so far. But that would not include > putting them into the guidelines. The guideline should just be the > guidelines. Author should not be trying to pick and choose among the > guidelines to decide which ones are important or not. As such. they > shouldn't be trying to balance or test or assert or evaluate the ability of > their pages to work for single functional limitations. If they want to know > if they work for people with disabilities, they should bring in a spectrum > of people with disabilities and have them test. These people will have > multiple disabilities and represent real people and not theoretical pure > functional limitations that people guess at whether their pages will work > for or not. > > Best > > Gregg > > On Dec 10, 2025, at 8:05 AM, 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 > Deque Systems Inc | - Accessibility for Good | www.deque.com > > > > > > > > > > > > > > > On Tue, Dec 9, 2025 at 8:59 AM Bradley Montgomery, Rachael L < > 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> >> *Date: *Tuesday, December 9, 2025 at 1:42 AM >> *To: *w3c-waI-gl@w3. org <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 >> >> 1. >> >> the web content cannot and is not ever viewed outside of the context >> 2. All users in the context are known to use only AT that is on the >> Accessibility support list >> 1. >> >> 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 >> >> >> 1. 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 >> >> >> >> 2. 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. >> >> >> >> 3. 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) >> >> >> >> 4. 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) >> >> >> >> >
Received on Friday, 12 December 2025 19:38:38 UTC