- From: Andrew Somers <andy@generaltitles.com>
- Date: Wed, 16 Dec 2020 15:34:43 -0800
- To: Alastair Campbell <acampbell@nomensa.com>
- Cc: "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>, Silver TF <public-silver@w3.org>
- Message-Id: <6145D567-7679-4389-968D-9BF4739133BB@generaltitles.com>
+1 These objections lack specificity making them somewhat un-actionable. That they are anonymous further weakens their veracity or relevance, and none seem to be the kind of issues that should hold up an initial working draft, which as I understand it is in part to provide a fixed point of reference to address such concerns. On the subject of conformance models, the objection as stated is unsupported and mere conjecture. There is nothing “risky” about a scoring method if appropriately structured and weighted. For instance a low score in one area can block or limit the total score, separately and in addition to any averaging or relevance weighting. Scoring does need clarity in terms of meaning such that levels are appropriately defined using more than one descriptor. I wrote about this a month ago — for instance a number for a level is not enough, a level needs an additional descriptor such as 4-ideal, 3-acceptable, 2-Deficient, 1-poor, 0-hard fail. The advantage of a multi-level scoring is that it provides for independent weighting of a given area or spec, and appropriately designed clarifies the mission, purpose, and importance of a particular criteria as opposed to a binary pass/fail which is inflexible and often results in a “minimum compliance” that inadvertently becomes the target goal. Andy > On Dec 15, 2020, at 6:25 AM, Alastair Campbell <acampbell@nomensa.com> wrote: > > Announcement to Silver and WCAG list > > Thank you for your patience while we work through the objections to the proposal to publish the FPWD of WCAG 3.0. We typically discuss options for resolving objections with objectors before sending the final response to the public lists. Because these objections are anonymous and because of the holiday timing, we are sending the chair's proposed solutions to the lists in an effort to make the process as transparent as possible. Our initial responses with proposed solutions are at the bottom of this email. > > If you have questions about these proposals or the objection resolution process, please send an email to AGWG Chairs <group-ag-chairs@w3.org <mailto:group-ag-chairs@w3.org>>. We hope to finish working through these objections and move forward with publication shortly after the holiday break. > > Kind regards, > > AGWG Chairs > > *** > 1. Attribution > This is a response from the Accessibility Guidelines Working Group chairs to the objection regarding acknowledgements. > A snippet of the objection is: > > the unique foundational contributions and design constructs by > > certain individuals to this document have not been adequately > > or explicitly acknowledged.It is important that this be remedied in > > this specific draft, as this is the foundational draft in which their > > work first appears. > (Full text at: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0094.html <https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0094.html>) > > In general the acknowledgements on specifications are kept flat, particularly for First Public Working Drafts, for several reasons: > · It is difficult to assess the level of effort, ideas or work from individuals. Some objective measures can be considered, but it is inevitably a subjective process. > · The contributions will vary over time, someone contributing massively at a later time may make previous contributions appear relatively smaller. This makes a multi-level acknowledgement hard to maintain. > · Documents get written, re-written and iterated by multiple people. It is rare for early stage concepts to make it through to the final document without substantial transformation and revisions from many contributors. With each version, we need to establish whether the weight of early contributions has changed, and whether to re-sort the acknowledgements section. > · Most of the work is ahead of us, there is more to do than has been done, so it is likely that early work will not attain the higher level of acknowledgement in later drafts. > > > Deciding whether to add levels of contribution is normally done towards the end of the process of maturing the specification, when it is more clear what contributions should be recognized, in what manner, from the course of development. > > We agree that people’s contributions should be acknowledged. We could bring forward the work on contributions by adding a new section within this and future versions for key contributors. For the FPWD, we would add an editor’s note stating that the next draft will contain a list of individuals before the draft goes out. We would then start the process to identify key contributors. > > The process to achieve this would be: > · The Chairs draft criteria for adding a ”key contributor”; > · The Working Group and Silver Task Force have an opportunity to review and update the criteria; > · The Chairs ask the group (including task force and community group) for nominations (allowing self-nomination) of people to be considered. Chairs ask for evidence of their contributions if necessary. > · The Chairs and team select the names they determine have met the criteria and add these to the key contributors section of the document; > · The contributions (past and present) are evaluated at each major stage of the document’s publication by the same process. > > It is important to understand that the additional level will be open to anyone in the group, and we cannot guarantee that any individual's contribution will qualify. > > The AGWG Chairs believe that it is a benefit to the development of WCAG 3.0, and part of promoting inclusiveness throughout the entire web community during review periods, to get this draft out for wide review as soon as possible. > > 2. Editors > > One of the objections received for the Silver FPWD was related to the selection of editors. As this is general information, we thought it appropriate to email the group our response. > > The objection included: > > There is a need for clarity and transparency about the specific role of editors, how they are recruited and chosen, and under what conditions they serve. > (Full text at: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0094.html <https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0094.html>) > > > The following guidance and practices exist for specification editors: > > · The Process document section 6.1.1. General requirements for Technical Reports <https://www.w3.org/2020/Process-20200915/#general-requirements> specifies that editors are appointed by a group chair, and are responsible "to ensure that the decisions of the Group are correctly reflected in subsequent drafts". > · In the Accessibility Guidelines Working Group the role of editor overlaps significantly with the role of the chair, so editors are often chairs, task force facilitators, or Team. In the case of the Silver Task force, the facilitators had stepped forward to lead the task force and edit the requirements and draft spec from the outset and have continued to be active in that role. > · Editors follow the W3C Manual of Style <https://w3c.github.io/manual-of-style/> and Chicago Manual of Style <https://www.chicagomanualofstyle.org/> amongst other Editor guidance <https://www.w3.org/2003/Editors/>. There is also style guidance specific to each group, including in the case of WCAG 3.0 the WAI EO Style Guide <https://www.w3.org/WAI/EO/wiki/Style> and the Silver Style Guide <https://www.w3.org/WAI/GL/task-forces/silver/wiki/Silver_Style_Guide>. > · Specific tasks of editors are loosely documented <https://www.w3.org/2003/Editors/> but, beyond reflecting WG consensus, generally involves soliciting and incorporating contributions from participants, tracking the consensus level for each contribution, and creating a well-structured, professional, and consistently written-document. > · To accomplish this, editors work closely and in the open with participants to converge on clear expression of intent, support participants to produce contributions that will successfully meet WG consensus, and edit material from a variety of sources and formats. > > 3. Barriers to Participation > > This is a response from the Accessibility Guidelines Working Group chairs to the objection regarding barriers to participation. > > A snippet of the objection: > > There have been barriers to participation in the First Public Working > > Draft of WCAG 3.0 that made the concurrent contribution and review by > > people with disabilities difficult… a compromise solution of adding a > > Framing Letter at the front of the FPWD as well as a related status > > update would help people who may have these concerns to find > > potential risks and feel invited to challenge them. > (Full text at: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0096.html <https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0096.html>) > > > While the AG and Silver groups strive to be as inclusive as possible, barriers can occur and we regret whenever these make it difficult for someone to participate. Over the years we've received feedback on barriers in AG, Silver, and other groups and since an inclusive environment is important we continue to welcome any and all feedback that can help us be more inclusive. > > For the concerns expressed in the objection, we would like to explore these through the processes we normally use to address such feedback. The CFC process is not set up to adequately explore and address these types of concerns. > > One goal of the Silver Task Force and Silver Community Group was to construct a new working climate that would be welcoming to more participants. Many activities were carried out to foster inclusion, such as: > · Including an equally broad set of stakeholder voices. Early work included several research projects to identify needs, and a comprehensive set of stakeholders was explicitly included in the process. > · Incubation work on WCAG 3.0 was conducted as a joint project between the Accessibility Guidelines Working Group (via the Silver Task Force), and the Silver Community Group. Joint work between Working Groups and Community Groups is unusual in W3C. The joint setup used for WCAG 3.0 reflects the specific desire to reduce barriers to participation. Invitations to participate were distributed widely, and when an under-represented user group was identified, individual invitations were also extended. > · Accessibility of the process was an important consideration during the development of WCAG 3.0. Work took place in a variety of media, both synchronous and asynchronous, and participants were able to choose the means of engagement that worked for them. If discussion or content available in one tool was not accessible to all, content was moved or adapted by leadership to make the content more accessible. > · Review of the WCAG 3.0 draft during its development followed similar procedures and principles. Since July 2020, the document was presented to the Working Group multiple times, sometimes in structured ways for specific sections, and sometimes as general reviews. An extended "deep dive" meeting in August focused on open areas of concern. All participants had the opportunity to participate in structured reviews, and various accommodations were made to support individuals when requested. > > As noted above, challenges with the social climate of the Accessibility Guidelines Working Group have been identified over the years, arising from a combination of the passion people bring to the work and a wide variety of communication styles. Chairs have worked to address specific concerns when raised, and to improve the climate systematically over time, including coaching individuals, setting expectations for the group, and reminding people of the importance of the Code of Ethics and Professional Conduct. We believe this approach has improved conditions and we always strive to continue improving. > > Because of the proactive and reactive work done to support accessible participation, supportive climate, and comprehensive review prior to the current request for consensus to publish, the chairs do not agree that a public statement as requested is appropriate. > > The chairs do agree, however, that no process is perfect, and we welcome input into ways to improve it. Therefore, a question about ways to improve participation will be included in the longer announcements and an editor’s note that accompany the First Public Working Draft. > > 4. Conformance Model > > This is a response from the Accessibility Guidelines Working Group chairs to the objection regarding conformance claims. > > > One significant issue is that conformance claims can be made by those > > using WCAG while not making content or structures sufficiently accessible > > and usable for people with disabilities. A scoring system in particular is > > risky because biases can be buried in numbers, which are less transparent, > > and these biases can be automated and amplified. > (Full text at: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0096.html <https://lists.w3.org/Archives/Public/w3c-wai-gl/2020OctDec/0096.html>) > > > With regards to the concern about the conformance model, the conformance section and requirements for a conformance section has been present throughout the drafting and consensus process over the last year. > > Conformance sections are widely used in W3C specifications and their presence is enforced by tools and transition rules. While not all guidelines include conformance specifications, including one strengthens the guidelines and stakeholders generally value the guidance provided by conformance sections. > > At this point in the process, the best approach would be to address these concerns as issues filed on the FPWD. >
Received on Wednesday, 16 December 2020 23:35:21 UTC