W3C

Site Navigation

Nearby

Results of Questionnaire Charter Approach

The results of this questionnaire are available to anybody.

This questionnaire was open from 2022-05-03 to 2022-05-31.

43 answers have been received.

Jump to results for question:

  1. Moving forward with initial AC review
  2. DONE: Support for Approach
  3. DONE: Single Group Charter - Missing Content
  4. DONE: Single Group Charter - Confusion Points
  5. DONE: Two Group Charters - Missing Content
  6. DONE: Two Group Charters - Confusion Points
  7. DONE: Work Distribution

1. Moving forward with initial AC review

After reviewing the drafts, please indicate your current position.

Summary

ChoiceAll responders
Results
I support this direction and these drafts going forward for initial review 5
I support this direction and these drafts going forward for initial review with the following adjustments (see comments) 5
I do not object to this direction and these drafts going forward for initial review. (The same as a 0 vote in call)
I object to this direction (see reasons in comments)
Something else (see comments)

Details

Responder Moving forward with initial AC reviewComments
Janina Sajka
Paul Bohman
Gundula Niemann
Jaunita George
Poornima Badhan Subramanian
Jennifer Strickland
Katie Haritos-Shea
Detlev Fischer
Jonathan Avila
Alastair Campbell
Léonie Watson
Ela Gorla
Rachael Bradley Montgomery
Andrew Somers
Wilco Fiers
Steve Faulkner
Melanie Philipp
Andrew Kirkpatrick
John Rochford
Makoto Ueki
Oliver Keim
Stefan Schnabel
Charles Adams
Sarah Horton
Jake Abma
Sally Britnell
Jennifer Delisi
Rain Breaw Michaels
Patrick Lauke
Kimberly Patch
JaEun Jemma Ku
Francis Storr
Gregg Vanderheiden
John Foliot I support this direction and these drafts going forward for initial review with the following adjustments (see comments) Under the heading 2. Scope >> 2.1 WCAG 3, I request an editorial change. Specifically the bullet point:

* At least one example of each type/category of testing,

Change to:

* At least one example of each type/category of testing <ins>or evaluation method</ins>,

Justification: We do not yet have consensus on whether or not we will have more than one type of *test* (we are about to start the "Exploratory" phase on that topic soon, and I personally struggle with the limitations of that term: tests SHOULD NOT resolve to an answer that is the equivalent of "maybe"), and as others have already noted, from a legislative perspective we may not have the ability to have other forms of testing that does not meet the requirements of 'testable, repeatable, measurable'. (This may also track-back to ISO requirements as well - TBC)

I believe it would be prudent to leave this deliverable/scope as more flexible than currently described.
Michael Gower I support this direction and these drafts going forward for initial review with the following adjustments (see comments) WCAG2ICT, Understanding/Issues and ACT are listed under both 2.2 Non WCAG 3 Scope and 3.2 Other Deliverables. Maybe those lists aren't intended to be exclusive of each other, but it does appear there's redundant info.

It seems like ACT is as well listed under 3. Deliverables > 3.1 Normative Specifications (so 3 separate times). Was it intended to have no date for expected completion here?
Jeanne F Spellman I support this direction and these drafts going forward for initial review
Shadi Abou-Zahra I support this direction and these drafts going forward for initial review Minor comments for editors' discretion:

#1. Section 2.1 says "wide review(s) of WCAG 3 will include the following ... An approach on testing emerging technologies". However, section 1.2 lists "Creating new guidelines for emerging technologies" as an example challenge, which may or may not be addressed by WCAG 3. This seems to be a slight contradiction, or at least precluding that WCAG 3 will include guidelines and test methods for emerging technologies.

#2. Section 1.2 says "AG WG will ... Know what will and will not be part of WCAG 3 ... have decided how the remaining parts of WCAG 3 will be delivered (all at once, in phases, or as modules.)". This also seems to preclude the outcome of the process -- parts remaining from what? Maybe better to have the final bullet say "have decided how WCAG 3 will be delivered (all at once, in phases, or as modules.)" instead?

#3. Section 1.2 says "Any requirement or challenge without a demonstrated solution that has AG WG consensus by the end of the next charter will be excluded from WCAG 3". This sounds quite harsh and could potentially have unintended consequences. Maybe soften this a bit to say something along the lines of "AG WG will review the requirements for WCAG 3 by the end of the charter period, to assess removing or revising requirements and challenges without demonstrated solution that has AG WG consensus"?
Bruce Bailey I support this direction and these drafts going forward for initial review with the following adjustments (see comments) My strong preference would be to have the WCAG2ICT activity under 3.1 -- but since it is not TR track, that might not be appropriate. If WCAG2.ICT cannot be under 3.1, please consider another way to give that work more prominence.

I would prefer stronger characterization under 3.2 Other Deliverables as "may be created" when items are expected to be given a significant about of group time or be a priority (e.g., errata). I agree that it is important to list other deliverables which are in scope and *might* (or might not) be create.

I appreciate having 11.1 Charter History. Benchmarks mentioning chairs seems a little uneven though. Can chairs-at-the-time be added to the earlier entries?
Laura Carlson I support this direction and these drafts going forward for initial review with the following adjustments (see comments) I'm a bit concerned about the reference to the third party content, but as long as there's no particular view expressed in the charter, it is okay to keep it as a discussion point as long as we also keep the current text in Section 1.2:

"Any requirement or challenge without a demonstrated solution that has AG WG consensus by the end of the next charter will be excluded from WCAG 3".
Shawn Lauriat I support this direction and these drafts going forward for initial review
Todd Libby I support this direction and these drafts going forward for initial review
Ben Tillyer I support this direction and these drafts going forward for initial review
Mary Jo Mueller I support this direction and these drafts going forward for initial review with the following adjustments (see comments) See suggested edit to the draft decision policy to remove the phrase "In order to work through objections," for better readability of the sentence. I'm not sure I understand the "not adding something to the documentation" example in the follow-up sentence after that phrase as an example of a careful approach to objections.

2. DONE: Support for Approach

Please indicate what approach, if any, you support and why.

Summary

ChoiceAll responders
Results
I support keeping AG a single group because (reasons are in comments) 14
I support splitting AG into two groups because (reasons are in comments) 20
I do not have a strong opinion (add thoughts to comments if desired)

Details

Responder DONE: Support for ApproachComments
Janina Sajka
Paul Bohman
Gundula Niemann
Jaunita George
Poornima Badhan Subramanian I support keeping AG a single group because (reasons are in comments) It might be easy to incorporate the feedbacks or suggestions received as part of WCAG 2 to WCAG 3 if we work as a single group. Also, once the WCAG 2.2 is released, the next 2.x version may not release soon relatively. IMO, single group can focus on WCAG 2 & 3 in different sub-groups as WCAG 3 COGA, WCAG 3 Mobile, WCAG 3 Low Vision, etc.
Jennifer Strickland I support splitting AG into two groups because (reasons are in comments)
Katie Haritos-Shea I support keeping AG a single group because (reasons are in comments) Splitting the group would seem like a mistake - breaking up the community and discussion. More importantly it would be the same as trying to do WCAG 2.1 and WCAG 3/Silver -- we CANNOT manage it, Keep the group and all its talent and focus on WCAG 3. We need everybody focused on this. Yes, it is much harder to build an entirely new standard - that is why we need all to turn their focus to it. Do NOT publish any other transitional document, that just splits us and wastes more time. Only WCAG2ICTwill need to be set up in the following charter period - not this one.
Detlev Fischer I support keeping AG a single group because (reasons are in comments) If WGAG 3 is to eventually replace WCAG 2.X and not be completely separate, I believe there should be just one working group. I can't see how consensus on a meaningful transition of requirements from 2 to 3 can be ensured in any other way. Splitting will just increase the grind.
Jonathan Avila I support keeping AG a single group because (reasons are in comments) It appears that splitting the group would allow folks to create a WCAG 2.x that is better organized -perhaps 2.3? - but perhaps not backwards compatible. I fear this is not a good use of time and likely isn't needed. WCAG 2.2 will add 8 new A and AA criteria to 2.1. I believe in the end you will find that you won't be able to do all of the things that you want in WCAG 2.3 and they will be deferred to WCAG 3.0 anyway. We've already been down this path before and the group decided to combine with WCAG 3.0 as most of the things we need to do won't fit into the 2.x model.

If things won't fit into the 2.x model then why keep kicking the can down the road and dividing the limited time people have. If we work on 2.x further it will only continue to splinter the efforts and make folks choose 2.x work over 3.0 work.

I agree that WCAG to non-web ICT is important - but given it's limited scope I believe it can be done within a single charter. If 1 charter means the low vision work has to be folded in - that is fine with me as the challenges it faces aren't really about the needs of users - but how to combine the complexities into guidance that addresses multiple things into one piece of guidance.
Alastair Campbell I support splitting AG into two groups because (reasons are in comments) I think the switch between 2.2 and 3 during meetings *should* be causing cognitive-whiplash due to the different in approach needed.

Unfortunately it is not, the group is applying the same level of scrutiny & word-smithing to new content in WCAG 3. That slows progress to a crawl. Our approach needs to be much faster, we should follow a more standard W3C process where changes go into the editor's draft immediately, issues are raised, and we return to things on a regular basis.

To mitigate the concerns people have about premature usage of WCAG 3.0, the new group can help differentiate WCAG3 from the "use in production" WCAG2 (as well as the show/hide labelling that is already in place).

Also, I'm not sure people realise but at the leadership level (chairs + silver facilitators + PM + staff contact) our meetings also split between WCAG 2 & 3, so there are 7 people sitting through both. Splitting groups would mean more focused meetings and less overhead per person.

For those concerned about splitting the groups meaning less people, I think it is the other way around. A consequence of the slow-progress (due to our WCAG 2 based approach) is that we are loosing people who want to contribute to WCAG 3.

A couple of comments raised that: The main decision is really be about whether we invest time in a WCAG.final. I think there are several levels it is worth outlining:

1. Maintenance, i.e. tackling github issues. I think we can (and should) do this whichever approach is taken. It would be limited to non-normative changes at this level, and not all issues would be resolvable.

2. Releasing a cleaned-up BUT backwards-compatible WCAG 2.x (2.2a?), which would clear most (but not all) WCAG 2.x issues.

3. Releasing a cleaned-up and not backwards-compatible WCAG 2.final, which could clear all the WCAG 2.x issues.

The last level could include: Merging (or better separating) overlapping criteria (e.g. non-text contrast & focus appearance); and possibly using an updated colour contrast formula (e.g. APCA).

To state my personal bias and outlook, I am very torn between working on a refined WCAG 2.x and a new WCAG 3.0. I'd like to do both.
Léonie Watson I support splitting AG into two groups because (reasons are in comments) I agree with the reasons given. There is a lot of work to be done and it makes sense to enable both areas of activity to progress without being encumbered by the other.
Ela Gorla I support splitting AG into two groups because (reasons are in comments) Each project requires huge effort and energy. Having two separate groups will help members channel energy and time into a single project.
Rachael Bradley Montgomery I support splitting AG into two groups because (reasons are in comments) There is no perfect option but I think splitting the groups has the best chance of successfully meeting the varied goals of the current AG group, particularly if members want to complete more work on WCAG 2 than basic maintenance and some issue cleanup. The working assumption if we split into two groups is that the group working on WCAG 2 would close after 1 or 2 charter periods, depending on how a final/clean version of WCAG 2 is defined (see Alastair’s comment).

The AG group rightly uses a very thoughtful decision process to make changes to WCAG 2. I believe this process is appropriate for a standard that is already referenced in laws worldwide. This process hinders the quick turnaround innovation needed for WCAG 3. To create an innovative standard, I believe we need to be using a much faster process that does not rely on approving every possibility in synchronous meetings and that incorporates regular public review. The standard W3C decision process, which allows for continuous edits and asynchronous feedback using the editor's draft, is well tested and much more appropriate to the transformative, innovative work needed for WCAG 3. In previous meetings, concern has been raised that because of the longstanding nature of AG, the public will expect the editor's draft to only reflect full group consensus. Breaking the group apart would help make a clear distinction between the two groups' processes and expectations.

Bruce asked if it was deliberate that only the WCAG 2 has the AG decision policy. It is. If we decide to stay as a single group, I believe we have to drop the AG decision policy and approach to creation if we want to succeed in creating WCAG 3.

I also believe breaking the group into two also allows each group to focus on one type of work (legacy or transformative) and be a cohesive group doing so. I believe that this focus will reduce overhead for members, even those who are splitting their time, and increase participation as a result. Members who can’t be in both groups can still participate through lateral group reviews and submitting GitHub issues.

We have tried doing both types of work with one as a taskforce. It did not work well because the entire group makes the decisions but not everyone is involved in the taskforce. As a result, there is constant revisiting and rework (with the associated lost time and frustration).

Based on interest expressed on the previous survey, the WCAG 3 work has dedicated participants – there is little risk of it having enough interest to move forward. Some members also expressed an initial intent to focus on WCAG 2. The work pace can be set based on how many people commit time to actively work on it. If something changed and WCAG 2 does not have enough interest to form a group or if that charter failed to move forward, the WCAG 2 maintenance and upkeep would have to land somewhere – the result would be the single charter option we have proposed.

Because WCAG 3 is pulling apart the WCAG 2.2 SC and addressing gaps as part of the process and because as currently scoped a clean version of WCAG 2 would not include new guidance, I do not believe that the work is interdependent.
Andrew Somers I support splitting AG into two groups because (reasons are in comments) I only "lean" in favor of a split. Nevertheless, for me the following are key issues for the charters, split or no split.

1) WCAG 2 backwards compatibility: this is a huge problem, and consideration needs to be given to remove (or extensively modify) this requirement for subsequent versions.

2) WCAG 2 as a legal statute: WCAG 2 is in some places being codified into law. This shifts the significance from a guideline or recommendation to a legal standard. However, the current process is not well equipped for maintaining a standard that is robust to withstand a high level of legal scrutiny. This may eventually result in unintended consequences, and adverse repercussions, and should not be taken lightly.

In this regard, A and AA are being promoted as law, and in some cases some A and AA SCs have no business being codified into law. Experimental and "optimistic" guidelines need to be excluded from legal codification — perhaps by being placed in the AAA category.

3) If there is a split, then WCAG 2 needs a charter that permits future versioning without mandating complete backwards compatibility, and allow for more flexible evolution and independent deprecation of SCs, as needed to maintain relevance or to correct existing errors and issues.

4) If there is a split, WCAG 3 needs to be completely free of concerns relating to 'migrating" anything from WCAG 2. In favor of the split is allowing WCAG 3 to develop unencumbered by legacy criteria, and (hopefully) instead be more connected to technology developments in CSS and user agents. (Ideally be in the driver's seat of future CSS and related technologies — being connected to the whole of HTML/CSS/etc technologies as a driving force of change is the path toward inclusivity).

5) Split or no split, currently there is insufficient liaison with CSS and other areas of W3C standards, and too many aspects of the WCAG guidelines are reactionary or following in the shadows of the other standards, instead of defining best practices that need to start with other standards such as CSS. Simply tacking-on a guideline as a band-aide is not the best practice.

For instance: stating that a mouse-cursor and a finger-touch is the "same thing" is inappropriate. An argument that "an author can not determine if an interface is mouse or touch" is not persuasive. Instead, the first step that needs to be taken is to ensure that such a media query (or other mechanism) does in fact exist, as opposed to stating that all interfaces must abide by touch standards.(or in other cases, by some lowest common denominator which only exists due to lack of relevant CSS or other needed technology).

This is a cart before the horse problem, and one that appears to result in reactionary and non-inclusive, instead of evolutionary and inclusive, guidelines.



Wilco Fiers I support keeping AG a single group because (reasons are in comments) I think this is setting ourselves up for failure. The goals we've set for the next charter for WCAG 3 are ambitious. We need as much effort into that as we can possibly get away with. A WCAG 2 WG is going to take time / people away from WCAG 3. Last week's survey clearly showed that. Doing WCAG 2 and WCAG 3 in parallel hasn't worked the last two charters. I don't see a reason why this would be any different.

It's also fairly odd to split the group that way. From last week's survey we can clearly see that almost two thirds would join both groups. How are these still separate groups if they have so much overlap between them?
Steve Faulkner I support splitting AG into two groups because (reasons are in comments) Agree with reasons cited in 4. background material
Melanie Philipp I support splitting AG into two groups because (reasons are in comments) I have nothing to add to the other comments above in support of splitting the group and my previous comments from last week's survey (below).
Andrew Kirkpatrick I support keeping AG a single group because (reasons are in comments) Splitting into two groups would be a mistake. The challenges that we have with WCAG 2.x and WCAG 3 are due to the main WG and the TF not working closely enough, and I believe that further separation will strain the people and organizations that are already struggling to engage with both development efforts. In addition, the administrative effort associated with rechartering is non-trivial and would henceforth be doubled.

The group should be focused on finishing WCAG 2.x this year and then moving to focus 95% of its energy on WCAG 3 and reducing WCAG 2.x to 5%.

We are already at a point in time where there is some risk of countries/organizations adopting incrementally different standards (2.0 vs 2.1 vs 2.2). When WCAG 3.0 comes out I do not believe that we want to have a WCAG 2.3 that is still new - we want to have there be one option for choosing a standard and having that be the basis for future improvements.
John Rochford I support splitting AG into two groups because (reasons are in comments) Separate groups will move our work forward faster.
Makoto Ueki I support splitting AG into two groups because (reasons are in comments) The development of WCAG 3 and maintenance of WCAG 2 series would be different kind of work. I assume the AGWG will complete WCAG 2.2 until the next charter will start on 1 November 2022.

- I've been participating in the Silver Task force for last 3 years.
- I don't think I've been catching up with the AGWG work, especially for WCAG 2.2.
- I'm not sure how much the rest of the work for the WCAG 2 series will remain and have to be done.

Once WCAG 2.2 become the W3C Recommendation, both AGWG participants and Silver TF participants must focus on WCAG 3. At this moment, the larger main group (AGWG) is mainly working on WCAG 2.2 and has more participants than the Silver TF.

We should change this balance as soon as possible. It would be better if the New WG (new larger main group) will work on WCAG 3 and the "task force" will work on WCAG 2 series. We can call the latter task force the another WG if needed.

In other words, this is an image of a reversal of the current allocation of human resources. And both groups should work more closely.

I can live with the single group. The key point is the balance in the distribution of participants. I think it would be good if more human resources than the current task force are engaged in the development of WCAG 3.

AGWG has been spending two hours for Tuesday call every week. Silver TF has been spending one hour for Friday call every week. And Tuesday call has been the joint meeting for both recently.

I would suggest that Tuesday's 2 hours call will be for WCAG 3 only and Friday's 1 hour call will focus on WCAG 2 maintenance if it makes sense. In this case, I'll participate in the Tuesday call. The days doesn't matter though.

And we can have any task forces/sub groups for each if needed.
Oliver Keim I support keeping AG a single group because (reasons are in comments) less effort for coordination, good flexibility for task management and associating people.
Stefan Schnabel I support keeping AG a single group because (reasons are in comments) Otherwise there is a danger for the two streams to de-synchronize.
Re-syncs to avoid this would require separate meetings/effort and will increase the workload.

Single tasks for WCAG3 can be organized within subgroups centrally monitored.
Charles Adams I support splitting AG into two groups because (reasons are in comments) I support a two group solution.

The current WCAG 2 approach is excellent for supporting an existing standard that has been adopted in laws and regulations around the world. This approach, however, is not well suited for exploration and evaluation of new approaches and innovations which is a requirement for WCAG 3.

The W3C processes are better suited for faster, more iterative development which will benefit WCAG 3, but is not well suited for supporting an existing standard that has been long established and referenced throughout the world. WCAG 3 is intended to be transformative. This goal requires greater exploration of approaches and ideas that did not work well for WCAG 2, and will not be guaranteed successes. WCAG 3 deserves the right to revisit and explore any concept that did not work for WCAG 2, and needs a process and support that allows for teams to re-examine such ideas. WCAG 3 also needs to explore and try out new and imaginative concepts, and needs the freedom to spend resources on ideas which may or may not be deemed successful.

The requirements for WCAG 2 and 3 are very unique and different, and this chair has observed that the blending of the required approaches does not facilitate success.

As an additional note, my limited understanding is that there may be patent concerns with two separate groups on the same line of standards. Those of us who are not experts in patent legalities may need to seek legal opinions.
Sarah Horton I support splitting AG into two groups because (reasons are in comments)
Jake Abma I support keeping AG a single group because (reasons are in comments) Separate groups did not work well till now, don't understand why to continue this way.

We need the knowledge of all the people combined.
Sally Britnell I support splitting AG into two groups because (reasons are in comments) More work could be progressed with a smaller group of people.
Jennifer Delisi I support splitting AG into two groups because (reasons are in comments) While I do not like the concept of splitting into two groups, my personal opinion is this comes down to scoping and resources available.

But, I have concerns about the split, that some of the diversity of thoughts may be difficult to maintain:

1. We have people that disagree on topics in the current group. How will we ensure that a group of those have felt unsteady, unsure, or did not feel certain choices were appropriate, will be represented in each group? The beauty of everyone together is the rigor of review. We must not lose that if we break into 2 groups. We must have those that have voiced concerns in each group.

2. While moving the COGA, low vision and mobile work into WCAG 3 has a good focus for the new approach, they are each a part of all we do. We want inclusion and consideration of these wherever possible. I believe that we should continue to have members of the WCAG 2 group that focus in each of these areas as well.

2.A. Also: those with cognitive disabilities are involved in WCAG 2 as testers, teachers of WCAG 2, developers...The inclusive nature of having one group meant the review process has kept this in mind, with more voices as time has gone on. When reviewing the language used in WCAG 2, the support materials, and even the test processes - having some participants with this focus will ensure greater accessibility of WCAG 2. I do not doubt the intent of group members. What worries me is that there are less people reviewing at the different stages. Less reviewers could mean that more things are missed.

3. Those with the skills and interest in the ACT work will be necessary contributors as some of the testing concepts mature for WCAG 3. While we are moving towards a new, changed format for WCAG 3, much of the world will still be comfortable, familiar with WCAG 2. The ACT group's expertise will be essential for identifying gaps, bridging gaps for audience members with the perception of the previous testing style. This group's expertise will be needed, and in my opinion, we cannot wait for WCAG 2 to wrap up to have them represented in the work being done for WCAG 3. Many times having input in the design phase or early project stages ensures that changes can be made before they are more difficult and time consuming.

4. Finally, if some join the WCAG 2 group because they are not comfortable with the direction of WCAG 3, I see this as a possible problem for its future success. There must be a way to be sure that, as close as we can, get to "the group" being in alignment for WCAG 3.
Rain Breaw Michaels I support splitting AG into two groups because (reasons are in comments) The mental work needed to refine V2 and to explore and revise V3 is very different. This separation enables group leadership to focus participants and conversations in the direction needed for the work of the specific group. This will also reduce the confusion arises for newer members why trying to understand why certain considerations remain out of scope for V2.
Patrick Lauke I support splitting AG into two groups because (reasons are in comments) While WCAG 3 will (hopefully) be a revolutionary and much more robust framework, it feels like we'll still be with 2.x for quite a long time, and having a dedicated group to work on much needed maintenance (just looking at github... ~500 open issues, ~170 open PRs, ~ 240 branches) and triage for all the non-normative materials and things like WCAG2ICT (which still has not been updated to account for new 2.1 SCs) is still relevant and necessary.
Kimberly Patch I support splitting AG into two groups because (reasons are in comments)
JaEun Jemma Ku I support keeping AG a single group because (reasons are in comments)
Francis Storr I support keeping AG a single group because (reasons are in comments) I don't think having two groups is working to progress WCAG 3, and it increasingly feels like progress will continue to be slow and somewhat divisive unless much more attention is given to it. I also realize that WCAG 2.x cannot be abandoned as there continues to be GitHub issues raised, a backlog of almost 500 existing issues, and many other "non-reported" maintenance issues such as dealing with link rot in Understanding and Techniques documents, and updating content as related specifications (e.g, ARIA) change. I'm assuming that these kinds of updates fit under the description of "Minimal WCAG 2 maintenance" rather than the Two Group "Extensive …" description. Creating a "WCAG 2.Final" feels like a grind that would slow down the progress we need to make to make the content more accessible.
Gregg Vanderheiden I support keeping AG a single group because (reasons are in comments) - People interested in Accessibility writ large would need to participate in both activities anyway. Very confusing to split discussions across two groups. And WCAG 2x will be essential in WCAG 3 if it is to be accepted by standards orgs - that have already crafted their accessibility standards and policies around WCAG2.

- If WCAG is going to have the name WCAG it should follow from the same working group and processes -- especially if there is any desire for WCAG 3 to be adopted like WCAG 2 was. There were/are reasons for those processes. They are key to adoption.

- If quicker turn around is desired - we can release working drafts for comment more frequently within the AG. No need to create a new group to decide to release more frequently.

- I hear a major reason is that it is too hard to get new things through the AG working group. If the problem with releasing more frequently is the level of rigor and documentation or such that the current AG working group requires - then we need to increase rigor etc of the submissions - not form a new group to circumvent it. Any new group should have the same rigor as the AG - again especially if it wants similar adoption.

- I also hear discussion about changing the decision process.... often to align more with the practices of voluntary technical standards of W3C. There is a big difference between *voluntary* technical standards and accessibility standards that are intended to be adopted in regulation - which is decidedly not voluntary. They need to follow very different paths / procedures.

Also note that technical standards often are accompanies by formal objections. WCAG 2 had none - and it was a major reason that it was widely adopted. Not resolving objections before final release only weakens a non-voluntary standard and puts barriers in the path to adoption because the objections have to be considered and resolved post release - possibly with changes to the standard as it moves to adoption - which leads to lack of harmonization.

If the major arguments for a new group are related to having a different (easier get things through) process that leaves objections on the table -- or that it is too much work (these standards are all killers) I dont think they are good reasons.

My major concern is that (for WCAG 3) we have not seen any progress on coming up with event conformance model. The lack of progress does not seem to be the AG. It is that it is an incredibly difficult topic. And not having the full AG to look at it and work on it - will not get there faster.

Getting things through the AG is not the problem or WCAG 3. It is figuring out how to solve this incredibly difficult problem of trying to get designers to look at more than just testable guidance - when the only kind that you can require (and that any policy setting group would adopt as required) are provisions that are testable -- where a designer can determine clearly and objectively if/when they have met the requirement.

Three cheers for WCAG 3. Lets stop having two groups and get the full power of the full combined group to work on this. It will be painful since we really want the impossible. But we NEED to make some tough decisions and move forward. We need to set criteria that will lead to successful adoption - then make proposals that meet the criteria AND push us beyond what WCAG 2x has been able to do

My thoughts
John Foliot
Michael Gower I support keeping AG a single group because (reasons are in comments) To me, with the majority of WG members now pivoting to 3.0 work -- which is something I thought the Silver TF has been advocating for for a couple of years -- we have an opportunity to better unite work. That's not to say that we can't have sub-groups tackling problems in parallel. But making the separation between the TF and WG even more formally adopted seems counter productive.
Jeanne F Spellman I support splitting AG into two groups because (reasons are in comments) 1) Progress has been incremental since 2020 when the first request to publish FPWD was sent to AG. In two years, we have no new guidelines and little forward progress on Conformance. The little progress has taken herculean effort by the chairs. Splitting the groups may not solve this problem, but no other solution has worked so far.
2) The structure of the Silver Task Force and AG relationship results in AG criticizing or rejecting work. As a whole, AG doesn't do the work. This results in publishing decisions being made by people who have not studied or understand the issues. AG rejected a years worth of work by 10-15 experts for uninformed reasons.
3) The AG decision policy allows a single person or a small group of people to block work for months or years. It encourages wordsmithing instead of developing new material or ideas. Attempts to streamline the decision policy resulted in proposals to make the decision policy even heavier.
4) Innovative work needs more frequent publishing to keep the work on track with the public. We are publishing less and less and are on track to not meeting the minimum publishing frequency requested by W3C (every six months).
5) Splitting the groups gives an opportunity for new people to participate who don't currently participate in AGWG largely because of the decision policy.
Shadi Abou-Zahra
Bruce Bailey I support splitting AG into two groups because (reasons are in comments) As reflected in these draft charters, it seems to me that the decision is not between single or two groups, but if we are agreeing to take on additional work (extensive v minimal 2 maintenance, 2 support materials, and wcag 2 final). If we give ourselves all three tasks, then we need two groups. If we give ourselves none of the three tasks, then its one group.

So I am reading this survey question to be asking if we commit to additional work or not. I am okay either way.

Editorial question: Is it quite deliberate that only Two Group WCAG 2 Charter has "AG Decision Policy"?
Laura Carlson I support keeping AG a single group because (reasons are in comments) Uniting in one group courageously opens the way for better accessibility solutions. This is because truth becomes clear and is mutually revealed through more perspectives. Because we are limited human beings, we need all perspectives to help us understand and to open our minds to see circumstances more objectively.

Power, synergy, and improved accessibility results from the harmony of uniting. Every effort should be made to avoid division and come together in purpose. We should strive to work together despite any differences. Any conflict can become steppingstones to stronger solutions when we make a commitment to understand each other and work together.

If the groups splinter, the WCAG 3 group would lack the wisdom, perspective, and experience of WCAG veterans and WCAG 2 group would lack the agile and fresh mindset of forward thinkers. Both would be lesser. Both would produce poorer standards. As has been said before, united we stand; divided we fall... and people with disabilities would suffer the consequences.
Shawn Lauriat
Todd Libby I support splitting AG into two groups because (reasons are in comments)
Ben Tillyer
Mary Jo Mueller

3. DONE: Single Group Charter - Missing Content

This charter incorporates the conversations to date and continues the single group path we have been discussing to date. The scope of work focuses on WCAG 3 and includes WCAG2ICT and maintenance of WCAG 2.x.

After reviewing the proposed AGWG charter if we remain as one group, what additional content should be added to represent the direction of the work?

Summary

ChoiceAll responders
Results
No content needs to be added 9
Additional content is listed in the comments 11

Details

Responder DONE: Single Group Charter - Missing ContentComments
Janina Sajka
Paul Bohman Additional content is listed in the comments The approach that I'd like to see is this: keep the whole group together, but with only 1 goal in the short term, which is to write a "final" version of WCAG 2.x that would essentially be the clearest, least ambiguous version of WCAG 2.x possible, with the intent of modernizing it where necessary, without rewriting the entire document from scratch. This would require going back through the unresolved questions that have piled up over the years, and forcing a decision/interpretation on topics that have languished in the gray areas, with multiple interpretations possible. We would allow for some minimal (but necessary) rewrites to the normative language to eliminate ambiguities, and because we'd be tinkering with the normative language. we'd have to call this WCAG 3.0, due to the breaking changes. In principle, the intent would be to create "WCAG 2.final," but any breaking changes would require us to call it 3.0. What we now call 3.0 would have to be numerically pushed up to 4.0. So it would be "all hands on deck" to get the modern interpretation of 2.x out, we'd call it 3.0, and only then would the group go back to working on 4.0 (previously known as 3.0). A couple of the areas in 2.x that need to be rewritten -- or explicitly clarified -- in the normative language include 1.3.1 and 4.2.1, but there are others. I'd like a modern take on landmarks, dynamic content updates (e.g. single page apps), and custom controls, to name a few specific points. We don't need a massive rewrite of WCAG 2.x to accomplish this, but we do need a few breaking changes that would require us to call it 3.0. Once we're satisfied that we have the best version of 3.0 (2.final) possible, with modern considerations taken into account, then we can move on to a more open-ended rewrite, which would eventually become WCAG 4.0. But until 3.0 (2.final) is done, any effort to work on (what I'm calling) 4.0 will be a distraction. We need to put the best minds together to come up with the absolute best version of WCAG 3.0 (2.final) that we can come up with, so that we have a solid point of departure for 4.0.
Gundula Niemann Additional content is listed in the comments The topics covered in both options should be the same.
According to Rachael's summary the topics differ. For example, low vision and Coga do not seem to be part of the one charter option (while they are mentioned in the suggested charter).
Jaunita George No content needs to be added
Poornima Badhan Subramanian Additional content is listed in the comments Design & Development techniques or requirements to satisfy for each guideline.
Jennifer Strickland Additional content is listed in the comments If we remain as one group we need to clarify the different approaches that must be applied to the work: for WCAG 2.2 (etc) the work should be more structured for delivery; for 3, it is important that we are able to explore alternative approaches and not be constrained by formats previously used. In addition, 3 must draft an initial approach to scoring because it is really blocking all the other efforts.
Katie Haritos-Shea No content needs to be added
Detlev Fischer Additional content is listed in the comments Regarding section "By the end of the 2022 - 2024 charter AG WG will:"
What I feel is missing here is a clear commitment to pinning down the new architecture of WCAG 3 - how the "parts" of WCAG 3 that are mentioned here several times are going to be organised in a consistent structure. In my view, the current five draft guidelines and its sketchy outcomes fail to provide a tangible feeling for such a structure. Actually, they do the opposite. Seeing, on the same level of granulaity, a guideline like "Structured content" with a huge scope next to others like "Captions" or "Visual Contrast of Text" with a narrow scope gave me that nauseating feeling that the overall structure of WCAG 3 was utterly unclear. I see this as the major blunder of this first draft.
So, I feel the commitment to arrive at a consensus top level categorisation for WCAG 3 (what we had in the principles in WCAG 2) is missing. I do feel that making an effort to arrive at a birds eye view of WCAG 3 will be crucial to give confidence to WG members that the time spent on transitioning the current SCs is actually time well spent. I do not have that confidence right now, so I am reluctant to put in work.
A top level approach could also lead to a recoginition that a finer granularity is preferable to what we now call "guideline". The ground work of mapping SCs to user needs that has begun is useful for that, but I would stresss we need top-level work as well, and ASAP. So in the charter, a clearer commitment on devising the overall architecture of WCAG 3 (including the conformance model, not down to the last detail, but overall) would be more convincing than the rather vague commitments made in the current draft.
Jonathan Avila
Alastair Campbell
Léonie Watson
Ela Gorla
Rachael Bradley Montgomery
Andrew Somers
Wilco Fiers No content needs to be added
Steve Faulkner
Melanie Philipp Additional content is listed in the comments Whether we have two separate WGs or a TF within one WG, I don't have a strong opinion. I do feel strongly that we *must* address the open issues in the WCAG github repo regarding interpration of WCAG for Web Content for reasons I conveyed last week. (See below) I would like to see the next charter (whether combined or separate) be clear about addressing those issues.

There is something to be said for separating the WGs as the work efforts for cleaning up WCAG 2.X and developing WCAG Next (Silver) require two very different mindsets and workflows. Gaining consensus on work may be simpler with a clear separation between the WGs.

Other comments that apply to any chartering scenario:

1. Any work on WCAG 2.X should be backwards compatible - no breaking changes.
2. Addressing WCAG 2.X issues should take priority over work that addresses non-normative guidance such as WCAG2ICT and other mentioned documents. This is not to say they can't be done in parallel, but if resources are an issue, work affecting normative interpretation should take priority.
3. Consider an option for a tranistional WCAG document that makes 2.X what we wish it were through changes to things such as "problematic SCs" (e.g. 1.3.1), techniques, the conformance model, and other aspects. Since this would not be backwards compatible with WCAG 2.X, we would need to increment this version to WCAG 3.
4. Why are there different Decision Policies for WCAG 2 and WCAG 3 work?

-----------------

Addressing WCAG 2.X Github issues

The wcag repo has years of issues asking for information on interpreting or applying WCAG in various scenarios. I personally spend hours digging through the wcag repo for answers to these types of questions: All. The. Time. All too often, I see that some back and forth may happen, representing the (often conflicting) opinion of a few people, many times referencing other related, also unresolved questions. Official resolution happens infrequently.

Without guidance from AGWG on questions of applicability or interpretation in the WCAG Github repo, people are left unable to apply WCAG consistently. As a standard referenced by regulations and legal decisions across the globe [as opposed to (all?) other W3C recs], *serious* progress on answering questions of the application or interpretation of WCAG to Web Content really *must* happen.
Andrew Kirkpatrick No content needs to be added
John Rochford No content needs to be added
Makoto Ueki
Oliver Keim
Stefan Schnabel
Charles Adams
Sarah Horton
Jake Abma No content needs to be added
Sally Britnell No content needs to be added
Jennifer Delisi
Rain Breaw Michaels
Patrick Lauke
Kimberly Patch
JaEun Jemma Ku Additional content is listed in the comments - Relationship between WCAG 2 and WCAG3
- Timelines for WCAG 3
Francis Storr
Gregg Vanderheiden
John Foliot Additional content is listed in the comments I would like to see some edits to section 1.2 "Focus for the 2022 - 2024 Charter".

* Specifically in the first collection of bullet points, that we remove the phrase "website conformance" as I believe the mandate for WCAG 3 goes beyond "websites" to include other forms of digital content, and the term conformance is already included in this bullet point.

* Additionally, as confirmed in Section 2 - 2.1 WCAG 3 "WCAG 3 Conformance Model": "In this charter period, AG WG will define the scope of the conformance model for WCAG 3".

As such, I would also like to see this added as a specific deliverable in the second collection of bullet points here:

"By the end of the 2022 - 2024 charter AG WG will:

* Know what will and will not be part of WCAG 3,
* have a timeline for delivering WCAG 3,
* have defined a conformance model, and
* have decided how the remaining parts of WCAG 3 will be delivered (all at once, in phases, or as modules.)
Michael Gower Additional content is listed in the comments I actually think there is something that needs to be _removed_:
> develops supplemental guidance, beyond that in the normative guidance, that describes enhanced accessibility for certain scenarios (such as Making Content Usable for People with Cognitive and Learning Disabilities), and

I do not think it is realistic for us to promise development of supplemental guidance. We may instead think of saying we want to maintain existing supplemental guidance. Even that may be over-promising what is actually done in this charter.
Jeanne F Spellman Additional content is listed in the comments The Motivation section heavily emphasizes "Web". I would like to see that softened - for example, pointing out that the principles of web accessibility also apply to other digital technologies and provide consistency of user expectations. In Out of Scope is a bald "does not provide normative guidance on non-web technologies" - Can this be removed?

Focus: Rewriting existing guidelines (resources and time)

Scope: "publish a wide review draft" One wide review draft in two years should not be acceptable to the AC. I think we have to schedule multiple wide review drafts in two years.

Normative Specifications - the list of functional needs should include vestibular disorders (appropriately phrased)
Shadi Abou-Zahra
Bruce Bailey No content needs to be added My (mostly) editorial suggestions to the previous version were incorporated, thank you.

I think what Paul Bohman describes in this survey response as WCAG2.final is similar to the need I perceive for what I have been calling WCAG 2.5 or 2.9. I understand if such an undertaking does not have much of an appeal for AGWG. Further down in this survey, AWK notes "the plan of record is that WCAG 2.2 is the last in the series."
Laura Carlson No content needs to be added
Shawn Lauriat
Todd Libby
Ben Tillyer
Mary Jo Mueller Additional content is listed in the comments If WCAG 3 is to be broader than just the Web, the current charter language doesn't reflect it.

4. DONE: Single Group Charter - Confusion Points

After reviewing the proposed AGWG charter if we remain as one group, what content needs to be removed or corrected as it will cause confusion about the direction of the work?

Summary

ChoiceAll responders
Results
No content needs to be removed or corrected 10
Corrections are listed in the comments 8

Details

Responder DONE: Single Group Charter - Confusion PointsComments
Janina Sajka
Paul Bohman Corrections are listed in the comments Taking into account my comments from the previous question, I would want the charter to be very clear that we have 2 goals, to be accomplished in sequence, not concurrently.
Goal 1: Write the best possible version of WCAG 2.x, taking into account the need for clarification on modern issues and technologies. We'd call this 3.0.
Goal 2: Write the next, forward-thinking versions of the guidelines, and call it 4.0
Gundula Niemann
Jaunita George Corrections are listed in the comments I'm a little concerned about the reference to the third party content question, but as long as there's no particular view expressed in the charter, I'm fine with keeping it in as a discussion point. I do agree with others that the specific references to websites should be revisited. What we think of as the web has evolved in recent years and we need to be flexible enough to recognize and support new kinds of digital content.
Poornima Badhan Subramanian Corrections are listed in the comments UX Design focused Accessibility Group
Jennifer Strickland Corrections are listed in the comments If we remain as one group we need to clarify the different approaches that must be applied to the work: for WCAG 2.2 (etc) the work should be more structured for delivery; for 3, it is important that we are able to explore alternative approaches and not be constrained by formats previously used. In addition, 3 must draft an initial approach to scoring because it is really blocking all the other efforts.
Katie Haritos-Shea Corrections are listed in the comments REMOVE: Additional WCAG 3 Publications.
If a transitional document between WCAG 2.2 and WCAG 3.
Detlev Fischer Corrections are listed in the comments See below.
Jonathan Avila
Alastair Campbell
Léonie Watson
Ela Gorla
Rachael Bradley Montgomery
Andrew Somers
Wilco Fiers No content needs to be removed or corrected
Steve Faulkner
Melanie Philipp Please see my comments in the first question
Andrew Kirkpatrick No content needs to be removed or corrected
John Rochford No content needs to be removed or corrected
Makoto Ueki
Oliver Keim
Stefan Schnabel
Charles Adams
Sarah Horton
Jake Abma No content needs to be removed or corrected
Sally Britnell No content needs to be removed or corrected
Jennifer Delisi
Rain Breaw Michaels
Patrick Lauke
Kimberly Patch
JaEun Jemma Ku No content needs to be removed or corrected Actually my answer is "I don't know enough to suggest either the removal or the correction"
Francis Storr
Gregg Vanderheiden
John Foliot No content needs to be removed or corrected
Michael Gower No content needs to be removed or corrected It seems to me it's a fairly malleable document. I do increasingly feel that a transitional or intermediary document is in order, which can be worked on in tandem with new requirement, to help clarify how existing guidance is translated into WCAG 3. However, this seems sufficiently captured by:

> If a transitional document between WCAG 2.2 and WCAG 3 is to be created, a first draft of it will be published by the end of the charter.

I do suspect we'll need to spend more time considering revamps to the Conformance Requirements section. I think there is some room for improvement in here, particularly as we consider a broader scope than 'web pages'.
Jeanne F Spellman No content needs to be removed or corrected
Shadi Abou-Zahra
Bruce Bailey Corrections are listed in the comments 3.1 last bullet:
> as well as sensory disorders and combinations of *these*.

I think "these" refers to the five preceding bullets. If that is the case, I would suggest putting the last six bullets as children to a COGA parent bullet. This would, IMHO, balance out the first four bullets.

I am not really comfortable combing "individuals without vision and with partial vision" and "without hearing and with partial hearing" as I feel the a11y requirements are different enough often enough. I would prefer to see those as four bullets rather than two.
Laura Carlson No content needs to be removed or corrected
Shawn Lauriat
Todd Libby
Ben Tillyer
Mary Jo Mueller Corrections are listed in the comments The WCAG 3 Normative specifications section does not need to provide a list of user needs. The simple description, "WCAG 3.0 supports this evolution by focusing on users’ functional needs. Following these guidelines will make content more accessible to people with a wide range of functional needs." is enough to get the point across without having to go into more detail. This would also address Bruce's comment on splitting the bullets for vision and hearing disabilities. I do agree that the listing in separate bullets the cognitive user needs and not the needs of other sensory disabilities does not recognize that a user's functional needs can be quite different between them.




Editorial comment: Misspelling of "verfiication" should be "verification".

5. DONE: Two Group Charters - Missing Content

This set of charters breaks apart the single charter into two pieces. The WCAG 3 work goes to the AG 3 group (name is TBD) and the WCAG 2 work goes to the AG 2 group (name is TBD). The scope of the WCAG 3 work remains similar but the WCAG 2 group includes additional work on a WCAG 2 final that closes all outstanding issues and creates a clean, final version of the WCAG 2 series. The WCAG 2 group continues with the existing decision policy while the WCAG 3 group uses the standard W3C decision policy.

After reviewing the AG 2 WG Charter and AG 3 WG Charter, what additional content should be added to represent the direction of the work?

Summary

ChoiceAll responders
Results
No content needs to be added 4
Additional content is listed in the comments 11

Details

Responder DONE: Two Group Charters - Missing ContentComments
Janina Sajka
Paul Bohman Additional content is listed in the comments Put the charter for 3.0 aside, except to rename it 4.0, until 3.0 (2.final) is complete.
Gundula Niemann Additional content is listed in the comments The topics covered in both options should be the same.
According to Rachael's summary the topics differ. Yet this might be a wrong impression.
Jaunita George Additional content is listed in the comments
Poornima Badhan Subramanian
Jennifer Strickland Additional content is listed in the comments For AG 3 WG, "In this charter period, AG 3 WG will define a working conformance model for WCAG 3." — I understand that to mean the scoring and conformance. If I understand correctly, that's great. If not, I do hope the group will consider making a priority what the conformance scoring model will look like so that we can make progress in our sub-groups. The lack of this information results in a lot of churn.
Katie Haritos-Shea NO to AG 2 WG Charter and NO to AG 3 WG Charter
Detlev Fischer The sooner we can agree a convincing new top-level architecture for WCAG 3, the sooner we can transition WCAG 2 substantive requirements to this new structure and tackle issues / close gaps there.
So I prefer to see WCAG 2.X work embedded in WCAG 3, in a joint WG. Rather than sketching a "transitional document between WCAG 2.2 and WCAG 3" (which feels as yet another meta document saying what will or should happen rather than doing it) I think we should focus on replacing ASAP the confusing current draft of WCAG 3 with its uneven five draft guidelines and strange structure, with one that give a substantive feel of the new architecture and the substantive *overall* content, covering all of WCAG 2.X in a revamped form, simplifying, merging, and regrouping requirements where possible. Not in any great detail throughout, but a convincing sketch of the *overall* building.
Jonathan Avila
Alastair Campbell
Léonie Watson
Ela Gorla
Rachael Bradley Montgomery
Andrew Somers
Wilco Fiers Additional content is listed in the comments I think ACT needs to be part of both groups, not just 2.x.
Steve Faulkner
Melanie Philipp Please see my comments in the first question
Andrew Kirkpatrick Additional content is listed in the comments Rationale for why this makes sense. I'm not convinced - it feels like it adds a layer of bureaucracy. I think that the group might benefit from more consolidation (e.g., close TFs that are primarily incubation-focused) instead of breaking the group into more parts.
John Rochford No content needs to be added
Makoto Ueki
Oliver Keim
Stefan Schnabel
Charles Adams
Sarah Horton
Jake Abma Additional content is listed in the comments
Sally Britnell No content needs to be added
Jennifer Delisi
Rain Breaw Michaels
Patrick Lauke
Kimberly Patch
JaEun Jemma Ku Actually, I don't see what are the changes other than chair names between two charters. Can we get the summary of differences?
Francis Storr
Gregg Vanderheiden
John Foliot Additional content is listed in the comments In Accessibility Guidelines 3 Working Group Charter:

I would like to see some edits to section 1.2 Focus for the 2022 - 2024 Charter.

* Specifically in the first collection of bullet points, that we remove the phrase "website conformance" as I believe the mandate for WCAG 3 goes beyond "websites" to include other forms of digital content, and the term conformance is already included in this bullet point.

* Additionally, as confirmed in Section 2 - 2.1 WCAG 3 "WCAG 3 Conformance Model": "In this charter period, AG WG will define the scope of the conformance model for WCAG 3".

As such, I would also like to see this added as a specific deliverable in the second collection of bullet points here:
"By the end of the 2022 - 2024 charter AG WG will:

* Know what will and will not be part of WCAG 3,
* have a timeline for delivering WCAG 3,
* have defined a conformance model, and
* have decided how the remaining parts of WCAG 3 will be delivered (all at once, in phases, or as modules.)

Michael Gower Additional content is listed in the comments I don't see how the first bullet of AG 3 "Rewriting existing guidelines" can be achieved if it is running in parallel with a divorced activity in AG 2 that is revamping and consolidating all wcag 2.x material.

Either that would seem to cause redundant work or, misalign primary goals of the two charters.

I also feel like it would be extremely hard to do some of the work in the 2 charter while maintaining full backward compatibility. My preference is to consider WCAG 2 completed as of the end of the current charter. The transition of the WCAG 2 material to a WCAG 3 format should be part of the upcoming charter, but should be categorized as WCAG 3 effort.
Jeanne F Spellman Additional content is listed in the comments See comments on question 2.
Shadi Abou-Zahra
Bruce Bailey No content needs to be added I am sorry to miss the conversation today [5/10/2022]. From the comments to this survey, I am feeling swayed that the two-charter approach seems too duplicative. Additional content (which I do not have suggestions for) might disambiguate the activities.
Laura Carlson Additional content is listed in the comments Rationale is missing for why a break is needed, why have 2 different decision policies, and why merging the 2 groups won't work.
Shawn Lauriat
Todd Libby
Ben Tillyer
Mary Jo Mueller No content needs to be added

6. DONE: Two Group Charters - Confusion Points

After reviewing the AG 2 WG Charter and AG New WG Charter, what content needs to be removed or corrected as it will cause confusion about the direction of the work?

Summary

ChoiceAll responders
Results
No content needs to be removed or corrected 5
Corrections are listed in the comments 9

Details

Responder DONE: Two Group Charters - Confusion PointsComments
Janina Sajka
Paul Bohman Corrections are listed in the comments The charter for (what I'm calling) 4.0 can't be finalized until 3.0 (2.final) is finalized.
Gundula Niemann
Jaunita George No content needs to be removed or corrected
Poornima Badhan Subramanian
Jennifer Strickland No content needs to be removed or corrected
Katie Haritos-Shea Do NOT FORM TWO GROUPS
Detlev Fischer Mentioning "Additional WCAG 3 Publications" seems to invite specuation that the main work may not be going too well.
See my answers above.
Jonathan Avila
Alastair Campbell
Léonie Watson
Ela Gorla
Rachael Bradley Montgomery
Andrew Somers
Wilco Fiers Corrections are listed in the comments "Address all public issues" seems overly ambitious. I think it's better to avoid being anything nearly this specific.

I like the idea of taking WCAG 2 and updating / modernising it to address open issues. I think that's a more promising way to build WCAG 3 then the blue-sky approach we're currently taking. That said, I think what's worse than either of those is to try and do both. The past two charters we've tried to divide our time between WCAG 2 and WCAG 3, and it has slowed us down tremendously. Two working groups isn't going to change how much effort either of those projects will take.
Steve Faulkner
Melanie Philipp Please see my comments in the first question
Andrew Kirkpatrick Corrections are listed in the comments WCAG 2.3 - the plan of record is that WCAG 2.2 is the last in the series. Have we changed that?

Where do all of the task forces live?
John Rochford No content needs to be removed or corrected
Makoto Ueki
Oliver Keim
Stefan Schnabel
Charles Adams
Sarah Horton
Jake Abma
Sally Britnell No content needs to be removed or corrected
Jennifer Delisi
Rain Breaw Michaels
Patrick Lauke
Kimberly Patch Corrections are listed in the comments The AG 3 5.1 document references 2.X instead of 3

Also note that this survey lists the AG 3 charter as "3" in question 7 above and as "new" in this question rather than "3".
JaEun Jemma Ku Again, I don't see how two charters are different.
Francis Storr
Gregg Vanderheiden
John Foliot No content needs to be removed or corrected
Michael Gower Corrections are listed in the comments I see little value in the separated charters. I much prefer the existing charter. I do not see how it is possible to have these charters running in parallel, when there are obvious dependencies between them.

I do think much of what is laid out in AG 2 can be tackled as a separate _stream_ inside the AG3 charter, but I believe both reswizzling of WCAG 2.x and new requirements/considerations considered for WCAG 3 realize real benefit from being worked on in tandem WITHIN THE SAME GROUP. Especially early on in the next charter period, some people will undoubtedly be concentrated on how WCAG 2 can be rethought to align it with more recent WCAG 3 directions. The innovations that are considered during this transition should inform and be informed by work of incorporating new considerations bulleted in the AG 'New focus' items, especially:
- Adding guidance to address known gaps in WCAG 2,
- Creating new guidelines for emerging technologies,and
Jeanne F Spellman Corrections are listed in the comments I would like to see a short paragraph at the top of each charter in the Motivation section briefly explaining the rationale for splitting the groups. Otherwise, it takes a sharp eye to see the difference between the two charters.
Shadi Abou-Zahra
Bruce Bailey Corrections are listed in the comments 3.1 same comment as above (Q3. Single Group Charter - Confusion Points) regarding bulleted list of functional needs.
Laura Carlson Corrections are listed in the comments Clarification is needed on if the AGWG will be completely divorced from the Silver TF. Will the Silver TF become its own and separate WAI Working Group? If so, why the AGWG is not creating the next major version of the WCAG specification.
Shawn Lauriat
Todd Libby
Ben Tillyer
Mary Jo Mueller Corrections are listed in the comments I am confused by the desire to split into two working groups. It is concerning that this could introduce a wider gap between the terminology, requirements and guidance which will increase the difficulty of transitioning to WCAG 3. While I do understand the desire to be able to be more agile and do more research and try very new things, I think this can still be done under a single working group with Task Forces.

7. DONE: Work Distribution

If we decide to split into two groups, are you most likely to work on...

Summary

ChoiceAll responders
Results
WCAG 2 1
WCAG 3 9
Both - emphasis on WCAG 2 4
Both - emphasis on WCAG 3 6
Both - equal split 7

Details

Responder DONE: Work DistributionComments
Janina Sajka WCAG 3 Splitting into two groups only acknowledges the practical reality and I don't think there will be a problem explaining our reasons to the public. WCAG 3 needs flexibility to innovate, publish often, and change our minds based on feedback and trial implementations. WCAG 3 has no guarantee of success. All we know is that we have good reasons to try new approaches. On the other hand WCAG 2.x has decades of success that deserves to be protected by careful approaches to additions and enhancements. An amicable split into two working groups is the best path forward because it acknowledges and supports these disparate working process needs.
Paul Bohman WCAG 2 I would consider working on a final "best" version of 2.x, and call it 3.0.
Gundula Niemann Can't make that decision now.
Jaunita George Both - equal split I do feel like we need to clean up WCAG 2.x. We do have a Github with a number of issues and those are not getting resolved right now. We won't have a more final version of WCAG 3.0 until 2026, so it makes sense to support WCAG 2.x until then and then help organizations migrate to the new standard.
Poornima Badhan Subramanian Both - equal split
Jennifer Strickland Both - emphasis on WCAG 3 I want to help in WCAG 2, but the reality is that I will probably only work on 3.
Katie Haritos-Shea WCAG 3
Detlev Fischer Both - equal split I do not support the split so this is impossible to answer well.
Jonathan Avila WCAG 3
Alastair Campbell Both - emphasis on WCAG 2
Léonie Watson
Ela Gorla
Rachael Bradley Montgomery WCAG 3
Andrew Somers Both - emphasis on WCAG 3
Wilco Fiers Both - emphasis on WCAG 2
Steve Faulkner Both - emphasis on WCAG 2
Melanie Philipp Both - emphasis on WCAG 2
Andrew Kirkpatrick Both - emphasis on WCAG 3
John Rochford WCAG 3
Makoto Ueki
Oliver Keim
Stefan Schnabel
Charles Adams
Sarah Horton
Jake Abma Both - equal split
Sally Britnell Both - emphasis on WCAG 3
Jennifer Delisi
Rain Breaw Michaels
Patrick Lauke
Kimberly Patch WCAG 3 (As a member of one of the working groups)
JaEun Jemma Ku Both - emphasis on WCAG 3
Francis Storr Both - equal split I would like to start with an equal split on 2 and 3, but once the amount of WCAG 2.x GitHub issues reduces (to a TBD number, but let's say maybe 50-100 open issues), I would want to start skewing my time towards WCAG 3.
Gregg Vanderheiden
John Foliot WCAG 3
Michael Gower Both - equal split Given my concerns above, i do not see how a split of this type is even supportable. If it proceeded, I believe the most insight on possible directions can be realized early on with a wcag 2>3 transition document, and that is where I would put greater effort in the first part of the charter, with the intention of focusing more on new content as the transition document becomes more mature.
Jeanne F Spellman WCAG 3
Shadi Abou-Zahra
Bruce Bailey Both - equal split
Laura Carlson Both - emphasis on WCAG 3
Shawn Lauriat
Todd Libby
Ben Tillyer
Mary Jo Mueller WCAG 3 Since Michael Gower focuses on WCAG 2, I would focus on WCAG 3.

More details on responses

  • Janina Sajka: last responded on 2, May 2022 at 16:36 (UTC)
  • Paul Bohman: last responded on 2, May 2022 at 19:55 (UTC)
  • Gundula Niemann: last responded on 3, May 2022 at 12:30 (UTC)
  • Jaunita George: last responded on 3, May 2022 at 14:40 (UTC)
  • Poornima Badhan Subramanian: last responded on 4, May 2022 at 17:53 (UTC)
  • Jennifer Strickland: last responded on 4, May 2022 at 18:28 (UTC)
  • Katie Haritos-Shea: last responded on 4, May 2022 at 20:02 (UTC)
  • Detlev Fischer: last responded on 5, May 2022 at 12:19 (UTC)
  • Jonathan Avila: last responded on 5, May 2022 at 12:32 (UTC)
  • Alastair Campbell: last responded on 5, May 2022 at 13:48 (UTC)
  • Léonie Watson: last responded on 5, May 2022 at 16:05 (UTC)
  • Ela Gorla: last responded on 5, May 2022 at 16:26 (UTC)
  • Rachael Bradley Montgomery: last responded on 5, May 2022 at 17:54 (UTC)
  • Andrew Somers: last responded on 5, May 2022 at 23:10 (UTC)
  • Wilco Fiers: last responded on 6, May 2022 at 11:26 (UTC)
  • Steve Faulkner: last responded on 6, May 2022 at 11:37 (UTC)
  • Melanie Philipp: last responded on 6, May 2022 at 16:33 (UTC)
  • Andrew Kirkpatrick: last responded on 6, May 2022 at 18:19 (UTC)
  • John Rochford: last responded on 6, May 2022 at 21:03 (UTC)
  • Makoto Ueki: last responded on 9, May 2022 at 07:54 (UTC)
  • Oliver Keim: last responded on 9, May 2022 at 12:16 (UTC)
  • Stefan Schnabel: last responded on 9, May 2022 at 12:16 (UTC)
  • Charles Adams: last responded on 9, May 2022 at 15:04 (UTC)
  • Sarah Horton: last responded on 9, May 2022 at 18:13 (UTC)
  • Jake Abma: last responded on 9, May 2022 at 18:47 (UTC)
  • Sally Britnell: last responded on 9, May 2022 at 19:45 (UTC)
  • Jennifer Delisi: last responded on 9, May 2022 at 19:56 (UTC)
  • Rain Breaw Michaels: last responded on 9, May 2022 at 20:17 (UTC)
  • Patrick Lauke: last responded on 9, May 2022 at 20:25 (UTC)
  • Kimberly Patch: last responded on 9, May 2022 at 21:19 (UTC)
  • JaEun Jemma Ku: last responded on 9, May 2022 at 21:39 (UTC)
  • Francis Storr: last responded on 9, May 2022 at 22:53 (UTC)
  • Gregg Vanderheiden: last responded on 10, May 2022 at 05:06 (UTC)
  • John Foliot: last responded on 26, May 2022 at 13:55 (UTC)
  • Michael Gower: last responded on 30, May 2022 at 18:27 (UTC)
  • Jeanne F Spellman: last responded on 30, May 2022 at 20:35 (UTC)
  • Shadi Abou-Zahra: last responded on 31, May 2022 at 09:06 (UTC)
  • Bruce Bailey: last responded on 31, May 2022 at 09:43 (UTC)
  • Laura Carlson: last responded on 31, May 2022 at 12:22 (UTC)
  • Shawn Lauriat: last responded on 31, May 2022 at 13:47 (UTC)
  • Todd Libby: last responded on 31, May 2022 at 14:51 (UTC)
  • Ben Tillyer: last responded on 31, May 2022 at 15:04 (UTC)
  • Mary Jo Mueller: last responded on 31, May 2022 at 16:07 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Chris Wilson
  2. Lisa Seeman-Horwitz
  3. Shawn Lawton Henry
  4. Chus Garcia
  5. David MacDonald
  6. Gez Lemon
  7. Peter Korn
  8. Preety Kumar
  9. Georgios Grigoriadis
  10. Romain Deltour
  11. Chris Blouch
  12. Jedi Lin
  13. Glenda Sims
  14. Ian Pouncey
  15. David Sloan
  16. John Kirkwood
  17. Reinaldo Ferraz
  18. Matt Garrish
  19. Mike Gifford
  20. Loïc Martínez Normand
  21. Mike Pluke
  22. Justine Pascalides
  23. Chris Loiselle
  24. Tzviya Siegman
  25. Jan McSorley
  26. Sailesh Panchang
  27. Cristina Mussinelli
  28. Sujasree Kurapati
  29. Jatin Vaishnav
  30. Sam Ogami
  31. Kevin White
  32. E.A. Draffan
  33. 骅 杨
  34. Victoria Clark
  35. Avneesh Singh
  36. Mitchell Evan
  37. biao liu
  38. Scott McCormack
  39. Denis Boudreau
  40. Rick Johnson
  41. David Swallow
  42. Aparna Pasi
  43. Gregorio Pellegrino
  44. Nicole Windmann
  45. Ruoxi Ran
  46. Wendy Reid
  47. Scott O'Hara
  48. Muhammad Saleem
  49. Amani Ali
  50. Trevor Bostic
  51. Jamie Herrera
  52. Shinya Takami
  53. Karen Herr
  54. Kathy Eng
  55. Cybele Sack
  56. Audrey Maniez
  57. Arthur Soroken
  58. Daniel Bjorge
  59. Kai Recke
  60. David Fazio
  61. Daniel Montalvo
  62. Mario Chacón-Rivas
  63. Michael Gilbert
  64. Caryn Pagel
  65. Achraf Othman
  66. Fernanda Bonnin
  67. Jared Batterman
  68. Raja Kushalnagar
  69. Jan Williams
  70. Isabel Holdsworth
  71. Julia Chen
  72. Marcos Franco Murillo
  73. Yutaka Suzuki
  74. Azlan Cuttilan
  75. Joe Humbert
  76. Charu Pandhi
  77. Alain Vagner
  78. Roberto Scano
  79. Kun Zhang
  80. Regina Sanchez
  81. Shawn Thompson
  82. Thomas Brunet
  83. Kenny Dunsin
  84. Jen Goulden
  85. Mike Beganyi
  86. Ronny Hendriks
  87. Breixo Pastoriza Barcia
  88. Olivia Hogan-Stark
  89. Rashmi Katakwar
  90. Julie Rawe
  91. Duff Johnson
  92. Laura Miller
  93. Will Creedle
  94. Shikha Nikhil Dwivedi
  95. Marie Csanady
  96. Meenakshi Das
  97. Perrin Anto
  98. Stephanie Louraine
  99. Rachele DiTullio
  100. Jan Jaap de Groot
  101. Rebecca Monteleone
  102. Ian Kersey
  103. Peter Bossley
  104. Anastasia Lanz
  105. Michael Keane
  106. Chiara De Martin
  107. Giacomo Petri
  108. Andrew Barakat
  109. Devanshu Chandra
  110. Helen Zhou
  111. Bryan Trogdon
  112. Mary Ann (MJ) Jawili
  113. 禹佳 陶
  114. 锦澄 王
  115. Stephen James
  116. Jay Mullen
  117. Thorsten Katzmann
  118. Tony Holland
  119. Kent Boucher
  120. Abbey Davis
  121. Phil Day
  122. Julia Kim
  123. Michelle Lana
  124. David Williams
  125. Mikayla Thompson
  126. Catherine Droege
  127. James Edwards
  128. Eric Hind
  129. Quintin Balsdon
  130. Mario Batušić
  131. David Cox
  132. Sazzad Mahamud
  133. Katy Brickley
  134. Kimberly Sarabia
  135. Corey Hinshaw
  136. Ashley Firth
  137. Daniel Harper-Wain
  138. Kiara Stewart
  139. DJ Chase
  140. Suji Sreerama
  141. Lori Oakley
  142. David Middleton
  143. Alyssa Priddy
  144. Young Choi
  145. Nichole Bui
  146. Julie Romanowski
  147. Eloisa Guerrero
  148. Daniel Henderson-Ede
  149. George Kuan
  150. YAPING LIN
  151. Justin Wilson
  152. Tiffany Burtin
  153. Shane Dittmar
  154. Nayan Padrai
  155. Niamh Kelly
  156. Matt Argomaniz Matthew Argomaniz
  157. Frankie Wolf
  158. Kimberly McGee
  159. Ahson Rana
  160. Carolina Crespo
  161. humor927 humor927
  162. Samantha McDaniel
  163. Matthäus Rojek
  164. Phong Tony Le
  165. Bram Janssens
  166. Graham Ritchie
  167. Aleksandar Cindrikj
  168. Jeroen Hulscher
  169. Alina Vayntrub
  170. Marco Sabidussi
  171. John Toles
  172. Jeanne Erickson Cooley
  173. Theo Hale
  174. Gert-Jan Vercauteren
  175. Karla Rubiano
  176. Aashutosh K
  177. Hidde de Vries
  178. Julian Kittelson-Aldred
  179. Roland Buss
  180. Aditya Surendranath
  181. Avon Kuo
  182. Elizabeth Patrick
  183. Nat Tarnoff
  184. Filippo Zorzi
  185. Mike Pedersen
  186. Rachael Yomtoob

Send an email to all the non-responders.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.