W3C

Site Navigation

Nearby

Results of Questionnaire Approach to publishing WCAG 3

The results of this questionnaire are available to anybody.

This questionnaire was open from 2021-08-18 to 2021-08-24.

15 answers have been received.

Jump to results for question:

Issues and Proposed Solution
Other Issues

1. Issues and Proposed Solution

Members of the AG Working Group and Silver Task Force raised concerns about the publishing schedule and approach at the 17 August 2021 Meeting. The chairs understand the issues articulated in this meeting and previous ones to be:

Concern about publishing to TR space, particularly around determining when content is 'done' enough to do so. This concern is elevated due to the request of W3C to publish on a quarterly schedule instead of AG's previous approach of publishing based on milestones.
Tension between the need to balance content creation that is necessary to evaluate conformance with agreeing upon a conformance model.
Concern about being able to move WCAG 3 forward in a timely manner while still completing WCAG 2.2, addressing all WCAG 2.x issues and successfully merging the Silver taskforce with AG.
Concerns about the different cultures in the AG Working Group, Silver Taskforce and Community Group.
Concern about the level of transparency in the development of content.
Concern about the chair and facilitators' leadership style, decision making, roles and responsibility, and communication.

The chairs propose the following solution for consideration:

Instead of focusing on publishing quarterly releases, the groups focus on discussing and approving content to an editor's draft in 2-3 week intervals. These are handled via surveys and agreement in the joint call.
At each major addition to the editor's draft, an appropriate lead for that update creates a blog entry describing the update, outstanding issues, and next steps to a new blog created for this purpose. These blog entries are announced to the AG and Silver lists, but not more widely than that.
Every 3 months, the groups review the updates since the last quarterly update. If nothing of substance is ready, we do not publish a quarterly update. Anything which is not approved is updated or removed from that update. The group agrees to final publication of new content to TR using the CFC process.
Major milestones (such as a revised conformance model, new guidelines, etc) that get published when approved by the groups are announced widely.
We fully merge the groups after WCAG 2.2 moves to publication.

We believe this proposal addresses the issues (as we've understood them) in the following ways:

Publishing to an editor's draft allows us to continue momentum in a referencable format without the concerns that come with a published update to the official document.
A blog will improve transparency by allowing members to see what is being worked and by whom, what is completed, and what the planned next steps are. This opens the opportunity for more feedback on our direction. In addition, the blog and links to an editors' drafts can be used as a reference when we want to solicit targeted comments on the newest content from non-member.
Keeping an updated, semi-public editor's draft and published working draft creates a clear distinction between when we want public comment because of a big release and when we are still not ready for that.
Maintaining quarterly check-ins for release ensures that we don't go too long without considering publication but doesn't commit us to doing so. The milestone list ensures we have agreed upon publication points.
Merging the groups will hopefully bring the best of both cultures into a single group and ensure all members are aware of what is going on. We have discussed merging after 2.2 in joint calls before, but the groups have not yet formally voted on doing so and on the timing.
This approach allows us to move both conformance and content creation forward without publishing the in-process documents in between.

Do you:

Summary

Choice	All responders
Choice	Results
Agree	8
Agree with the following changes
Disagree for the following reason or with the following alternative	3

(4 responses didn't contain an answer to this question)

Details

Responder	Issues and Proposed Solution
Laura Carlson	Agree
John Foliot	Agree
Jeanne F Spellman	Disagree for the following reason or with the following alternative	I want to recommend that we continue to follow the recommendation of W3C staff and publish quarterly on a regular cadence. This allows W3C management and the W3C Advisory Committee to see the progress of the project. A regular cadence of publishing assures contributors that if their work isn't ready for this quarter, there will be another publication in 3 months where their work can be included. Having a deadline is motivating. We did not publish the FPWD until we were given a deadline by W3C management. Deadlines help with project management by allowing us to plan what will be included in each publication and address issues related to each new or updated topic. One project in the Silver Research in 2017-2018 was to interview the chairs of other W3C working groups to learn the "best practices" of successful groups. They recommended using the W3C tools to publish more frequently with greater transparency in the project management. They recommended monthly publishing to improve transparency and to allow interested external people and groups the ability to see ideas before they were fully "baked" so that problems could be identified before too much work was invested in the topic. This "best practice" of more frequent publishing is being picked up by other WAI groups as well. ARIA in HTML is publishing 3-5 times a month. HTML Accessibility API Mappings 1.0 was published 28 times in 2019, 6 times in 2020, and 3 times in August 2021. However, when I look at the history of various individual TR documents, they are all over the map -- some are published frequently, others are not. There can be a lot of reasons for this, including whether or not they have people actively working on them. The chairs interviewed in the Silver Research also had other suggestions that we haven't implemented yet, but we would like to. They recommended using Github to assign issues to projects and having project plans that anyone can view and see what issues are being addressed and when they are scheduled. I would like to start implementing this based on our experience with the Q3 publication plan. There is a Silver wiki page for the Q3 publication (that needs to be updated with the new timeline) and the start of a Q4 planning page with the topics that did not make it into the Q3 publication plan. This could be made easier to find in Github (I just need to learn how to do it.) From the Q2 publication, I learned the importance of introducing the proposed work to AG with enough time to give AGWG multiple opportunities to look at the work and comment. From the Q3 publication, I am learning about the importance of communicating the project plan to AGWG so they know what is being worked on and when they can expect to see it. I want to keep the quarterly cadence and continue to improve it so it works better for AG members. I look forward to the completion of WCAG 2.2 and merging the groups. As Sarah said on Tuesday, the feedback from AG is valuable in refining the work. We need the expertise of AG in developing the tests for migrating the existing WCAG 2.x SCs.
Makoto Ueki	Agree	As a subgroup lead and a participant of the Silver TF, this proposal looks all good. I'm looking forward to merging the groups.
Jake Abma	Disagree for the following reason or with the following alternative	before agreeing on the approach I think we might want / need to tackle a mutual understanding / agree on the direction, see comments in 2. Other Issues
Michael Cooper		+1 to Jeanne's response. I think regular publications are important to keep momentum up and solicit more frequent reviews. I'm not sure what's expected by a blog, would we use the W3C blog? A custom blog? A wiki that's updated in a blog-like way? While I can see some value in it, I think investment to return ratio but not be optimal. I suggest we use tools to reduce investment a bit: * Put a description of the change, intended for public consumption, in the description field of a pull request. Also make the one-liner description be something that would fit into the change log well. * Use automation to update the change log from merged pull requests, and post the description somewhere, such as the blog or wiki. * For changes that are bigger than a single pull request, like a design change, we might supplement the above with dedicated messaging on that change. It seemed to me the conversation last week focused on publication strategy. I think it will be more important to identify important milestones that we expect for the project, and get consensus on what they are and what will allow them to be considered "met". Once we think that is solid, we can come back to timeline and strategies to meet it.
Sarah Horton	Agree	My understanding is that the role of the Silver Taskforce and Community Group is to engage diverse perspectives in a design-oriented process of research, experimentation, and iteration, to produce essentially “paper prototypes” for AGWG and the public to review and respond to. The groups have done amazing work and have produced innovative ideas and approaches. The concern from AGWG about the publishing schedule and approach is a great indication that it’s time to move to the next phase of the work, building on the prototypes and the feedback they have generated, and for this we need AGWG. I look forward to merging the groups and shifting our attention and focus to WCAG 3, in whatever form it takes.
Janina Sajka	Disagree for the following reason or with the following alternative	I disagree with the proposal because it seems to impose more requirements on Editor's Drafts than the W3C process document https://www.w3.org/2020/Process-20200915/#revising-wd imposes on updating working drafts. I simply don't see what good can arise from diverging from standard W3C consensus processes as described in our annually updated process document so significantly. Please note especially that Sec. 6.2.6 does NOT require group consensus to publish an updated working draft. It only requires there be enough changes to benefit from wider public review, and to document the changes. That's it. There's no blogging requirement, and no expectation that the group agrees with everything in the updated draft. Should we fail to update for 6 months we're asked to justifythat failure. This is, in my view, the expectation of greater public transparency. I value that expectation and support it. Thus I find myself in agreement with Jeanne and Michael.
Wilco Fiers		Before I decide, I'd like to see a few more details worked out: 1. What does a "fully integrated" group look like? What happens to the Silver TF/CG, and to its facilitator positions? Does this open full participation to AG up to any Silver CG members? Do CG members get to vote on AG CfCs? 2. What is the reason for only adding things to an editors draft every few weeks? Why not allow groups to open pull requests, and once ready, they'll be brought to AG and added to the editors draft right away?
Shawn Thompson	Agree
Charles Adams	Agree	I would like to keep content concerns and process concerns distinct and separate, and tackle the process concerns and solutions expressed in this survey. I support the changes listed in this survey. I support a quarterly updated editor's draft, and would like to continue to advocate for a quarterly working draft.
Andrew Kirkpatrick		I agree with Janina that we don't want to impose additional requirements apart from the W3C Process. It is of course worth keeping track of which issues are addressed and new features added to each WD, whether it results in a blog post or not. When we did this for WCAG 2.2, we set a schedule for the WD's and whatever was accepted into the editor's draft went into that. The core issue here seems to be that there hasn't been enough accepted into the Editor's draft. I would also like to know who made a commitment to publish quarterly - my understanding is that this commitment may not actually exist. Can we please clarify what "fully merge the groups after WCAG 2.2 moves to publication" means?
Shawn Lauriat	Agree	I agree with Jeanne's points and concerns, but I do not see a more viable alternative than this proposal until we have the larger WG focus entirely on WCAG 3.
Detlev Fischer
Bruce Bailey	Agree

2. Other Issues

In the previous question, we listed the chairs' understanding of the issues facing our group in publishing and working towards 3.0. What did we misunderstand or miss? Please list other issues you feel the group needs to discuss in order to move forward with WCAG 3.

Summary

Choice	All responders
Choice	Results
I am not aware of other issues	7
I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)	7

(1 response didn't contain an answer to this question)

Details

Responder	Other Issues
Laura Carlson	I am not aware of other issues
John Foliot	I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)	I would have liked to have seen a specific reference to addressing comments received via the public comment process when you state: "...creates a blog entry describing the update, outstanding issues, and next steps to a new blog created for this purpose." Since all of our comments have been tracked as github issues, a summary of closed (or proposed responses) to specific issues would be a valuable addition to the blog update.
Jeanne F Spellman	I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)	I am grateful to the work and time that the chairs are putting into WCAG3 development. They are thoughtful and considerate of the sense of the group. They are trying to manage a very large and complex project at the same time they are trying to complete 2.2. While I do not attend every meeting, I can say I have never attended a meeting where the chairs were making unilateral decisions. In my experience, the chairs are always trying to implement the decisions of the group and consider the different members and viewpoints fairly. Project management is a chair function in W3C working groups. The chairs are hard-working volunteers that deserve our gratitude. I sincerely thank Alastair, Rachael, and Chuck for their service.
Makoto Ueki	I am not aware of other issues
Jake Abma	I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)	My view so far is that looking back at the process it might not have been helpful separating the first structure setup in Silver from the complete WCAG Working Group. -------------------------- As an example to try to explain: It feels like it has been decided that we all go to Mexico by car, and now we can choose if we want to visit Tijuana, Guadalajara, or Hermosillo. Maybe not everyone in the group wants to go to Mexico but Canada, or even Europe, and not even by car (impossible for some). -------------------------- The approach so far the last months is that the framework / structure is set, templates are provided and we only need to fill them in. The proof of the approach, if it will fit properly and feels good at all, and how to score is still in the open. At the moment I think too much work is scattered around too much autonomous sub-groups, the overview is a bit gone and often group are "just following". Other ways / approaches are not discussed, maybe other people want fundamental changes to the suggestions so far. -------------------------- WCAG 2.x SERIES -------------------------- As an example, it might be good to explore if and how we can build on top of the WCAG 2.x series. Break difficult parts open, extend the testing and scoring system, change the Conformance model, but stay close to WCAG as it is and apply all learnings and conditions for Silver to make it a WCAG 3 worthy new release. The iteration on top of, and starting with WCAG 2.x, might have so much more affinity with people and resonates easier. -------------------------- Of course leaving enough room for completely other approaches too.
Michael Cooper		The chairs put a lot of time into supporting the group, and are extremely conscious about being objective and addressing known issues as best as they can. I know that may not be very visible but I want to assert that the chairs are genuinely trying to meet the group's needs and priorities.
Sarah Horton	I am not aware of other issues
Janina Sajka	I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)	I have only the highest regard for our Chairs, staff contacts, and group facilitators. I believe they do an exemplary job of steering a group of participants who often disagree, and sometimes disagree strongly. That's commendable, and I would like to see us add our public audience more closely into that process. We're far from a finished product. That's not a bad thing and doesn't reflect negatively on anyone. Widening participation to more fully encompass the public will only help, imo.
Wilco Fiers	I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)	I have significant reservations about the complexity and scope of WCAG 3. At the rate AG is progressing; writing maybe half a dozen new outcomes in a year, it'll take us a decade to complete WCAG 3. There are also major parts planned for WCAG 3 that have barely been touched. I would like to have a conversation about how realistic it is for WCAG 3 to make it to rec in a "reasonable" time frame, and what we actually consider that to be. The second major topic I think is maintenance. WCAG 3 looks like it will be significantly larger than WCAG 2 is. How realistic is it that AG will be able to do a good job of maintaining WCAG 3 and all its accompanying documents long term? What are the plans for doing so?
Shawn Thompson	I am not aware of other issues
Charles Adams	I am not aware of other issues
Andrew Kirkpatrick	I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)
Shawn Lauriat	I am not aware of other issues	I agree with Detlev's point that the cadence matters less than better understanding of the work happening, and see regular cadence of publishing as one mechanism to ensure some level of understanding across the WG of the WCAG 3 work as it progresses.
Detlev Fischer	I would like to clarify or add to an issue listed or discuss an issue not listed (see comments)	I am less concerned with the frequency of publication of drafts and more concerned with arriving at a true understanding of the new WCAG 3.0 framework – also in view of requests from MATF to port 2.X SCs to the new 3.0 format. I feel profoundly queasy about this process. For me, it all hinges on a good consensual understanding regarding the relationship between guidelines, outcomes, functional categories, methods, and tests. (See my mail from 23. August to AG mailing list).
Bruce Bailey	I am not aware of other issues