W3C

Site Navigation

Nearby

Results of Questionnaire WCAG 3.0 - Issue Responses

The results of this questionnaire are available to anybody.

This questionnaire was open from 2021-12-22 to 2022-01-18.

14 answers have been received.

Jump to results for question:

  1. 380 - Question on Clear Words Revised
  2. 169 - Consider "accessible name" instead of "alternative text"
  3. 257- Meaningful Text Alternatives
  4. 457 - ITI Comments on flexible conformance
  5. DONE: 256 - Clear Words vs Plain Language
  6. DONE: 359 - Measuring words question
  7. DEFUNCT: 380 - Question on Clear Words

1. 380 - Question on Clear Words Revised

In issue 380, melaniephillip asks "Will a tool like dictionary lookup provided at the OS or browser level be a sufficient technique for Method: Use Clear Words?". We discussed this on January 4th and Alastair proposed a revised response, which is below:

Thank you for your comment. Most tools available today do not solve the overall issue of the necessity of writing with clear words so can’t be a sufficient technique. It may be a partial technique. Currently, the browser lookup function definition often does not provide the correct context for the content. We are closing this issue but are adding a label (input-for-future-version) to ensure the group considers your point as we move forward and look at techniques.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 5
Agree with some adjustments 2
Something else 2

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

Details

Responder 380 - Question on Clear Words RevisedComments
Léonie Watson
Alastair Campbell
Jeanne F Spellman
Detlev Fischer
Rachael Bradley Montgomery
John Foliot Something else Respectfully, this group has not reached consensus on a requirement for Clear Words in WCAG 3, and any response to that idea is premature, as there is a very real possibility that a Clear Words requirement will not be part of the final WCAG 3 effort.

We should not be responding to any comments on this topic until such time as we have vetted and reached consensus on any requirements, and I reject this response as inappropriate.

************
See also:
https://github.com/w3c/silver/issues/579
https://github.com/w3c/silver/issues/580
https://github.com/w3c/silver/issues/581
https://github.com/w3c/silver/issues/582
https://github.com/w3c/silver/issues/583
Julie Rawe Agree with the response
Shawn Lauriat Agree with the response
Gundula Niemann Agree with the response
Rain Breaw Michaels Agree with the response
Michael Gower Something else While I agree with the concept that inline definitions doesn't solve clear words, the current state of the material in the Develop tab of Clear Words (https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#develop-button) in combination with this response, is going to lead to a lot of confusion.
Is there any concept of this being a sufficient _developer_ technique?
Bruce Bailey Agree with the response
Andrew Kirkpatrick Agree with some adjustments I don't think that we can say whether this conforms until we know the conformance model. I would say:

Thank you for your comment. We are not sure whether browser-based dictionary lookup would satisfy the method at this point. The Working Group has concerns that current implementations may not fully meet user needs, and as the WCAG 3.0 conformance model and this method mature we will work to clarify whether or not this will be sufficient.
Laura Carlson Agree with some adjustments Until JF's issues are resolved suggest we reply, "We are closing this issue but are adding a label (input-for-future-version) to ensure the group considers your point as we move forward and look at techniques." We should make sure the section is labeled "exploratory".

2. 169 - Consider "accessible name" instead of "alternative text"

In issue 169, WilcoFiers stated "The term "alternative text" is a little data, and is very specific to images on the web. Accessible name is the more general term that seems to be more broadly used." The full proposed response is below:

Thank you for your comment and suggestion. We recommend continuing to use the term “alternative text” or “alt text.” The term “alternative text” captures the fact that alt text is intended to serve the same purpose as the image, rather than simply describing it. “Accessible name” might lead developers to think they must only provide a label for an image (e.g., “A graph.”). “Accessible description” might lead developers to assume they should describe the appearance of the image, rather than its meaning or purpose. In our experience, the term “alt text” is frequently used by content creators and developers producing other non-HTML-based products (e.g., PDF, Word, PPT, etc.).

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 5
Agree with some adjustments 2
Something else 6

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

Details

Responder 169 - Consider "accessible name" instead of "alternative text"Comments
Léonie Watson Something else I agree with Wilco and so do not agree with this response. The correct term is accessible name, of which an alternative text is just one type. This relationship should be made clear throughout WCAG 3.0 because it is not so in WCAG 2.x and it constantly confuses people when the terminology changes.
Alastair Campbell Something else Agree with Rachael's suggestion, and suggest we add that to the issue and request the sub-group to consider that.

It does raise a question about the overall structure of the guidelines, where does the accessible name for controls fit?
Jeanne F Spellman Agree with the response
Detlev Fischer Agree with the response
Rachael Bradley Montgomery Something else Have you considered "Text alternative" instead of "alternative text"? I believe that phrase is used elsewhere and provides more implementation flexibility than "alternative text" without changing the meaning.
John Foliot Agree with some adjustments I actually would prefer to see the term "textual alternative(s)" used, which separates the requirement from the technique: textual alternatives for raster images can also be furnished using ARIA (aria-label, aria-labelledby), however for vector images (SVG) there are multiple techniques depending on how the SVG is being used in the larger page/screen.

I can, however, accept the proposed response if the larger group is in consensus.
Julie Rawe
Shawn Lauriat Agree with the response
Gundula Niemann Agree with the response
Rain Breaw Michaels Agree with the response
Michael Gower Something else I see the phrase "text alternative" in 3.0 but not "alternative text". I think "text alternative" is far preferable to "alternative text" and definitely preferable to "alt text". I also think "text alternative" is more easily understood than "accessible name", and also feel that they are not necessarily synonymous.
Bruce Bailey Agree with some adjustments I agree with the concept expressed in the proposed response that "alt text" is a reasonable and meaningful term shorthand term for informed people to use. It is very casual while being simultaneously nonsensical. As a term of art, it works quite well.

I agree with the proposed response that "Accessible name" and "Accessible description" are problematic.

I am not comfortable with the response's use of "alternative text" because that phrasing (at least for me) implies a specific approach derived from an accommodation-oriented mindset and regulatory use of the term "alternative version".

For the proposed response, I recommend replacing "alternative text" with "text alternative is available" (or maybe even "textual alternative".
Andrew Kirkpatrick Something else agree with Alastair's suggestion
Laura Carlson Something else Agree with Rachael's suggestion.

3. 257- Meaningful Text Alternatives

In issue 257, gregrgay states "This guideline should state up front that a "meaningful" text alternative is required, rather just a text alternative. Recognizing that decorative images may not be meaningful, then perhaps "appropriately meaningful" or "appropriate" or "equivalent" would generalize better to more situations." The full proposed response is below:

Thank you for your comment and suggestion. While we agree with the points raised, the title should be kept as-is. A method document will provide an explanation on how to meet the guideline. This document will provides concrete examples of how to meet the guideline, with clear examples of what is meant with "appropriate," "equivalent" or "meaningful." We will keep your points in our mind.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 6
Agree with some adjustments
Something else 7

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

Details

Responder 257- Meaningful Text AlternativesComments
Léonie Watson Something else I do not agree with this response. I think it's important to include an adjective in the guideline itself, though I would use "appropriate" instead of "meaningful", for the reasons stated in the proposed response.
Alastair Campbell Something else It does appear that the issue-poster was asking for an update to the guideline text, not the title.
As such, it does seem to be a good idea to include "equivalent" or "appropriate", with an update to the informative documentation to say what that means.
Jeanne F Spellman Agree with the response
Detlev Fischer Something else I think it is currenty difficult to solve this for Silver since the granularity of guidelines overall is not clear yet.
Currently, for example we have 1.1.1 and 4.1.2 and possibly also 2.4.6 which may overlap in certain contexts.
A draft of all guidelines and how they divide the cake would be needed for this. I suggest to postpone answering.
Rachael Bradley Montgomery Agree with the response
John Foliot Something else I do not believe the commentor was speaking to the 'title' of this Guideline, but rather to the actual functional outcome of the Guideline. Greg did not write "The Title of this guideline should state up front...", but rather his comment speaks to the content of the Guideline: "This guideline should state up front..."

Contextually, I agree that text alternatives should be meaningful (alt="picture" helps no-one), however again, "meaningful" is a subjective determination that will be difficult to accurately and consistently measure, and so the use of "meaningful" will likely need to remain non-normative.

I reject the current response as proposed.
Julie Rawe
Shawn Lauriat Agree with the response
Gundula Niemann Agree with the response
Rain Breaw Michaels Agree with the response
Michael Gower Something else I would like to advocate that the existence of a text alternative be one requirement, and that the quality of the text alternative be another requirement. Not only Is the first much easier to confirm through automation, but the existence of the alt is an implementation check, while the quality of the alt is a design check.
Bruce Bailey Agree with the response I am sympathetic to the several survey comments that this guideline should be for "equivalent text alternative". But are we sure that is to be the requirement? Descriptive Identification -- which is decidedly *not* an equivalent text alternative -- is (sometimes) not only sufficient but the best practice.
Andrew Kirkpatrick Something else A nice short guideline is desirable, but "Guideline: Provide text alternative for non-text content." could benefit from the addition of equivalent: "Guideline: Provide equivalent text alternative for non-text content."
Laura Carlson Something else Agree, with @awk's suggestion: "Guideline: Provide equivalent text alternative for non-text content."

Also agree with Michael Gower that we consider 2 requirements: "existence of a text alternative be one requirement, and that the quality of the text alternative be another requirement."

4. 457 - ITI Comments on flexible conformance

In issue 457, ITI stated "A flexible conformance approach might be a vehicle for addressing the more complicated issues involved in 3rd party content conformance, as well as flexibility in describing the main/primary functions of a web page or view vs. the secondary or tertiary ones. However, multiple conformance models would likely make conformance claims more complicated and confusing. There should be one model for conformance, based on rating and scoped by documenting the sampling, processes, and any other testing performed with an easy way to calculate the conformance level. If it is too complicated, it will be difficult for policy makers to understand what conformance levels can be reasonably expected for technologies to attain that can be included in regulations. More clarity in the specific proposals is needed to give a more detailed response to the question." The full proposed response is below:

Thank you for your ideas. The Silver Task Force agrees with you that we do not want to make the conformance too complicated. The group continues to vote down having multiple conformance models. While we work through the process of creating a conformance model and way of putting together a conformance claim, it will continue to start off more complicated than we want. As we work through arriving at a more solid conformance model and conformance claim process, we can then start refining and simplifying them. We are closing this issue but are adding a label input-for-refinement to ensure the group considers your point as we move forward.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 4
Agree with some adjustments
Something else 2

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

Details

Responder 457 - ITI Comments on flexible conformanceComments
Léonie Watson
Alastair Campbell
Jeanne F Spellman
Detlev Fischer
Rachael Bradley Montgomery Agree with the response
John Foliot Something else Respectfully, this comment is not about the "conformance [being] too complicated", but rather seeks a conformance model that is >>flexible<< - a very different requirement. Additionally, I have a concern with the statement, "The group continues to vote down having multiple conformance models." - can the group please reference one or more of those votes?
(Noting as well that at the W3C, we use a consensus model and not a straight up or down vote, and so more accurately, the group has not yet found consensus on the conformance model.)

I would prefer that we defer responding to this comment until such time as we have actually resolved conformance and scoring - the current proposed response is not responding to the concern expressed in the comment.
Julie Rawe
Shawn Lauriat Agree with the response
Gundula Niemann
Rain Breaw Michaels Agree with the response
Michael Gower
Bruce Bailey Agree with the response
Andrew Kirkpatrick
Laura Carlson Something else I would prefer that we defer responding to this comment until such time as we have actually resolved conformance and scoring or close the issue and reply, "We are closing this issue but are adding a label (input-for-future-version) to ensure the group considers your point as we progress". We should make sure the section is labeled "exploratory".

5. DONE: 256 - Clear Words vs Plain Language

In issue 256, gregrgay requested we change the guideline title from "clear words" to "plain language." The subgroup responded that there was the potential for confusion based on already existing standards by that name. The full proposed response is below:

Thank you for your comment. This was originally considered, but the decision was made that Plain Language is comprised of a comprehensive set of writing requirements that would be too large to include in one guideline. We were also concerned about causing confusion where there are laws and regulations that refer to plain language. For example in the United States, there's the Plain Language Writing Act of 2010 and plainlanguage.gov serves as a resource for federal agencies in the United States. This guideline is part of the first public working draft of WCAG 3.0 and we expect for it to mature over time. We acknowledge that what we are including in this guideline references more than just clear words, so as we work on this guideline and align it more to the [Making Content Usable](https://www.w3.org/TR/coga-usable/) document from COGA, it may get renamed.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 5
Agree with some adjustments 4
Something else 2

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

Details

Responder DONE: 256 - Clear Words vs Plain LanguageComments
Léonie Watson Agree with the response
Alastair Campbell Agree with some adjustments Given the usage of the term "plain language" in other parts of the guideline documentation, it would help if the "Get started" page had a line about the difference and what is meant by it in relation to Clear words.
I suggest updating the response to say that will be included, and that would clear many of JF's points.

Regarding the comments on subjective evaluations, this should be treated separately. There is lots to do on this (and other) guidelines. I wouldn't expect this guideline to look as it does now by the time WCAG 3 matures, but it is an excellent test case for developing WCAG 3. It (is intended to) meet a real and huge user-need, but more difficult to test. That's why we need this guideline to be included during development.

As a reminder, we have agreed to:

- Mark these guidelines as "exploratory";
- Define requirements for the guidelines to be included by CR;
- Drop guidelines that don't get consensus as 'mature'.
Jeanne F Spellman Agree with the response
Detlev Fischer Agree with some adjustments I would drop the part "This guideline is part of the first public working draft of WCAG 3.0 and we expect for it to mature over time..." and onwards. Seems a bit vague and unnecessarily apologetic.
Rachael Bradley Montgomery Agree with the response
John Foliot Something else I am, and have been for some time, fundamentally opposed to the direction this draft guideline is taking. As currently envisioned, it will never be able to be accurately measured or evaluated - the outcomes will always be 100% subjective.
We have received multiple notes and comments expressing concern over subjective evaluations already., which this Working Group ignores at our own peril.

To this particular issue, despite the proposed wording of this response, the actual Guideline *repeatedly* uses the expression "Plain Language" throughout the draft, including:

1) Summary
Clear words guideline uses research-based strategies to improve the experience of individuals with cognitive and learning disabilities. Clear words help create more accessible content. Writing and editing in >>>plain language<<< means using...

How
* Follow principles for >>>plain language<<<.
https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#get-started-button

2) Planning responsibilities
Prior to finalizing the project budget, consider possible costs associated with developing accessible content, written in >>>clear language<<<. (Q: what is the difference between clear language and plain language?)
... If possible, secure content authors or editors with experience writing in >>>plain language<<<
...Provide training on how to develop content that uses >>>plain language<<< principles. Determine if you will create a style guide to clearly communicate the unique needs of your content. Plan and schedule iterative >>>plain language<<< quality assurance checks throughout the project cycle. Schedule time for cycles of editing.
...If your content requires legal review, bring in legal experts early so they agree with using >>>plain language.<<<
https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#plan-button

3) Design responsibilities
...If needed, design visually distinct >>>plain language<<< summaries before blocks of text
https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#design-button

4) Resources
* Publications Office of the EU: How to write clearly - International resources for >>>plain language<<<
* Federal >>>Plain Language<<< Guidelines - US government official website
https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#resources-button


ADDITIONALLY, the current draft is convoluted and confusing - it speaks to writing in plain language, until the time you get to the "Develop" tab, where it then starts to speak of "inline definitions" and "inline definition are displayed in a modal" - neither or which are actually techniques or requirements for writing in plain language (or "clear words" - whatever we mean by that - we have not done a good job of defining what we mean by that term either)

I also (personally) reject the current example provided in the draft - the "plain language" example misses a number of critical information points, including where the recommendation comes from, as well as removing a number of examples significantly different than "brisk walking"

FINALLY, the current test method for this Guideline is unworkable as presented. It seeks a "...common word list for your language (of) ...at least 3000 words". (https://www.w3.org/WAI/GL/WCAG3/2020/methods/clear-words/)
Where does this list come from, who determines whether the words on the list are common, and common to whom? A 3000 word list of terms common to a nuclear physicist will not contain words common to a Grade 3 student, and the current proposal for using a tool such as Simplewriter does not in any way account for internationalization issues, nor does it measure with any accuracy the legibility and comprehensiveness of a sentence written - it is simply looking for words on a list, completely out of context to the end result.

Julie Rawe
Shawn Lauriat Agree with the response
Gundula Niemann
Rain Breaw Michaels
Michael Gower Agree with some adjustments Perhaps cross-references would be useful?
Bruce Bailey Agree with some adjustments Please consider keeping the response active voice.

I suggest replacing "the decision was made" with "we came to the deliberative conclusion".
Andrew Kirkpatrick Something else Agree with other comments that this seems premature - I'll agree that we can change the name now but only if we also agree not to use this change as a reason that it can't be changed again after further work on the guideline.
Laura Carlson Agree with the response It seems premature to begin processing outside comments on the content of WCAG 3 that the AG working group itself hasn't reviewed and commented on yet. If I recall correctly, we only agreed to the structure for the document. We haven't agreed to the content or direction for this section.

It might help to survey the AG Group on the section before we start responding to people outside of the group.

But with that said, I agree if the section is marked as "exploratory". Thanks for the reminder, Alastair.

6. DONE: 359 - Measuring words question

In issue 359, paulairy asks "Is it feasible to test using a readability feature, like the one included with Grammarly?" The full proposed response is below:

Thank you for your comment. The Clear Words subgroup agrees with John Rochford. The current state of readability tools are not supported by current research. There are new tools being developed that the group is looking into and hope to include in a future draft. We are not opposed to readability tools per se, but current tools, such as Flesch-Kincaid are not designed to meet the needs we’re targeting.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 7
Agree with some adjustments 3
Something else 1

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

Details

Responder DONE: 359 - Measuring words questionComments
Léonie Watson Agree with the response The response is OK, but the lack of adequate tooling will become a problem if it does not materialise in time for Rec.
Alastair Campbell Agree with some adjustments Suggestions started with @@:

Thank you for your comment. @@ This guideline is still in early development, how it is going to be tested is not yet agreed. In general the Clear Words subgroup agrees with John Rochford. The current state of readability tools @@may not be sufficient. There are new tools being developed that the group is looking into and hope to include in a future draft. We are not opposed to readability tools per-se, but current tools, such as Flesch-Kincaid are not designed to meet the needs we’re targeting.
Jeanne F Spellman Agree with the response
Detlev Fischer Agree with the response
Rachael Bradley Montgomery Agree with some adjustments I would add a link to John Rochford's comment in github to help it be clear what this response is referring to or remove the second sentence.
John Foliot Something else Until such time as the larger Working Group has properly vetted the direction of this proposed Guideline, we should not be responding to comments related to the Guideline.
Julie Rawe
Shawn Lauriat Agree with the response
Gundula Niemann
Rain Breaw Michaels
Michael Gower Agree with some adjustments The user didn't ask if they _could_ test with tools. They asked if it was feasible to test with tools.
Given the responses, I think the response should initially state that it is feasible, but current tools are not considered adequate for real world usage.
Bruce Bailey Agree with the response
Andrew Kirkpatrick Agree with the response
Laura Carlson Agree with the response Agree, if the section is marked as "exploratory".

7. DEFUNCT: 380 - Question on Clear Words

In issue 380, melaniephillip asks "Will a tool like dictionary lookup provided at the OS or browser level be a sufficient technique for Method: Use Clear Words?". The full proposed response is below:

Thank you for your comment. The group discussed this and we do not think a browser lookup function is sufficient to meet user needs. First, these tools are available today and they do not solve the overall issue of the necessity of writing with clear words. If we were to say that using browser lookup functions was a sufficient technique, there would be no incentive for authors to provide clear language. The lookup function definition often does not provide the correct context for the content. Also, the number of steps required to use a browser lookup function can be too complex for people who need to look up multiple words. The fatigue factor for people with certain types of disabilities can be too great.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 7
Agree with some adjustments 1
Something else 2

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

Details

Responder DEFUNCT: 380 - Question on Clear WordsComments
Léonie Watson
Alastair Campbell Agree with some adjustments At first I wasn't sure whether the question was about authoring or on the user-agent end, but I think (and am now assuming) that Melanie is asking whether the end-user could look up words, rather than asking the author to adjust them.

In that context, I agree with the response, those tools are available now and are not sufficient for the user-need.

I would just update "group" to "sub-group".

In response to other comments...

JF: It's too early to talk about formal objections, it isn't being put forward in that context. You raise good questions that should be put into issues, such as:
- Does the implementation require authors to apply context, is that why browser tools aren't (currently) sufficient?
- How to balance accuracy with plainness (and evaluate that).
- How does the developer guidance fit with the rest.

Laura: We're processing comments, some are from people outside the group, some are from inside the group. We agreed the structure of the document, but group members are encouraged to review and comment on the content, that is partly what we are processing.



AWK: I'm not sure if you are wanting to change the name? Nothing is set, this is "exploratory" content.
Jeanne F Spellman Agree with the response
Detlev Fischer Agree with the response
Rachael Bradley Montgomery Agree with the response
John Foliot Something else "The group discussed this and we do not think a browser lookup function is sufficient to meet user needs." - I am not sure which group is being referenced here, but I cannot find any AG minutes related to this discussion (but if they exist I'd like to see them please).

I reject the current proposed response because today the current Guideline specifically speaks to a function similar to what Melanie is asking about, specifically on the Develop tab where it states:

"Technical responsibilities
Ensure that inline definitions are accessible by:

* Make inline definitions keyboard accessible
* Once activated (either by keyboard or hover), ensure definitions remain open until the user closes them.
* Design one click to the definition and one click return.
* When inline definition are displayed in a modal, all the accessibility requirements of a modal should be included

Yet, the proposed response states, "If we were to say that using browser lookup functions was a sufficient technique, there would be no incentive for authors to provide clear language. (Clear language? What is that?)... The fatigue factor for people with certain types of disabilities can be too great."

The current response appears to reject a browser or OS based "dictionary lookup", while at the same time offering as a developer technique the requirement to provide inline definitions. It is unclear where any difference here is - the function of the inline definition function? (where the local author can create a modal pop-up to display a definition, but the OS or browser cannot?)

Again, a basic reading of the current draft, and it is clear that there remains significant confusion, even within the Working Group over what the actual goal is, how we will achieve that goal, and how we will be able to evaluate content created by others to ensure it meets our desired goal. I will once again suggest that it is too early to respond to any question related to Clear Words / Clear Language / Plain Language (whatever term we finally decide on - we currently use all three in our current draft).

I will respectfully suggest that this Guideline is extremely immature and unworkable, and without a significant rethink of this Guideline I fear it will be met with a Formal Objection later in the process.
Julie Rawe
Shawn Lauriat Agree with the response
Gundula Niemann
Rain Breaw Michaels
Michael Gower Agree with the response
Bruce Bailey Agree with the response
Andrew Kirkpatrick Something else Having a built-in tool to address this need would be ideal. We might want to say that current tools evaluated aren't enough, but not that "we do not think a browser lookup function is sufficient to meet user needs". If the goal is that unusual words can be defined in one click, does it matter how it is provided?
Laura Carlson Agree with the response Agree, if the section is marked as "exploratory".

More details on responses

  • Léonie Watson: last responded on 4, January 2022 at 08:24 (UTC)
  • Alastair Campbell: last responded on 4, January 2022 at 13:56 (UTC)
  • Jeanne F Spellman: last responded on 4, January 2022 at 14:32 (UTC)
  • Detlev Fischer: last responded on 4, January 2022 at 15:59 (UTC)
  • Rachael Bradley Montgomery: last responded on 14, January 2022 at 02:14 (UTC)
  • John Foliot: last responded on 14, January 2022 at 13:21 (UTC)
  • Julie Rawe: last responded on 14, January 2022 at 13:48 (UTC)
  • Shawn Lauriat: last responded on 14, January 2022 at 17:56 (UTC)
  • Gundula Niemann: last responded on 17, January 2022 at 14:37 (UTC)
  • Rain Breaw Michaels: last responded on 18, January 2022 at 13:53 (UTC)
  • Michael Gower: last responded on 18, January 2022 at 14:50 (UTC)
  • Bruce Bailey: last responded on 18, January 2022 at 15:44 (UTC)
  • Andrew Kirkpatrick: last responded on 18, January 2022 at 16:34 (UTC)
  • Laura Carlson: last responded on 18, January 2022 at 16:49 (UTC)

Non-responders

The following persons have not answered the questionnaire:

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