W3C

Site Navigation

Nearby

Results of Questionnaire Approve new ACT Rules, December 2022

The results of this questionnaire are available to anybody.

This questionnaire was open from 2022-12-07 to 2023-01-17.

16 answers have been received.

Jump to results for question:

  1. New Rule: Element in sequential focus order has visible focus
  2. New Rule: Text has minimum contrast
  3. New Rule: Text has enhanced contrast
  4. DONE: New Rule: HTML page title is descriptive
  5. DONE: New Rule: Image accessible name is descriptive
  6. DONE: Streamline ARIA rule approval process
  7. DONE: Menuitem has non-empty accessible name
  8. DONE: Scrollable element is keyboard accessible
  9. DONE: Iframe with interactive elements is not excluded from tab-order
  10. DONE: Update currently approved rules

1. New Rule: Element in sequential focus order has visible focus

The ACT Task Force would like to publish the following rule:

Element in sequential focus order has visible focus

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 7
I approve of the rule being published with adjustments (please comment) 5
I do not approve because (please comment) 1

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

Details

Responder New Rule: Element in sequential focus order has visible focusComments
Jaunita George I approve of the rule being published This is also likely going to generate a significant number of false positives.
Gregg Vanderheiden I do not approve because (please comment) on pixel in a different color does not mean it is visible.
1) one pixel is not really visible
2) the pixel could be one the same color with a least significant digit incremented by 1 - and it would be a different color but not distinguishable even with a magnifying glass.

I appreciate the difficulty since "visible" is not defined - (and this shouldn't have passed without a definition of visible) so I am not sure what to do here - but this in effect creates a definition of visible that is not in WCAG and therefore is not allowed any more than a more reasonable ("someone with 20:20 vision can reliably tell the focused items from the non focused items when 20 feet from the screen"
Oliver Keim I approve of the rule being published with adjustments (please comment) 1 pixel seems not enough. A larger portion is needed.
Laura Carlson I approve of the rule being published
Michael Gower I approve of the rule being published with adjustments (please comment) I think this must list Focus Order https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html in the requirements mapping, or is there something I'm missing?

Most implementations of 'return to top' put the user back at the top of the page without showing a focus indicator. Some may find it confusing if the focus went around a non-interactive heading (which is typically where focus goes). That said, in most other circumstances where focus goes on non-UI components, there's usually a visible indicator.

Focus Visible does not seem to address if it's just for UIC components. This is probably another hole that needs to be sorted out as part of WCAG 3.0.
Stefan Schnabel I approve of the rule being published with adjustments (please comment) Please add examples of machine algorithms how to test this !!!
Gundula Niemann
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki I approve of the rule being published
Detlev Fischer I approve of the rule being published with adjustments (please comment) Background: "All Examples in this rule satisfy those success criteria."

Really all? I guess this should read: "All *Passed* Examples in this rule satisfy those success criteria."
Andrew Kirkpatrick I approve of the rule being published with adjustments (please comment) Unicity is an unusual word. How about "WCAG does not require that the focus indicator for each focusable element is unique in appearance." instead of "WCAG has no clear requirement of unicity of the focus indicator for each focusable element"?

2. New Rule: Text has minimum contrast

The ACT Task Force would like to publish the following rule:

Text has minimum contrast

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 9
I approve of the rule being published with adjustments (please comment) 4
I do not approve because (please comment) 1

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

Details

Responder New Rule: Text has minimum contrastComments
Jaunita George I approve of the rule being published
Gregg Vanderheiden I do not approve because (please comment) it reads This rule applies to any visible character in a text node that is a child in the flat tree of an HTML element, except if the text node has an ancestor in the flat tree for which at least one of the following is true:
<skip exceptions>
For each test target, the highest possible contrast between the foreground colors and background colors is at least 4.5:1 or 3.0:1 for larger scale text, except if the test target is part of a text node that is purely decorative or does not express anything in human language.

PROBLEM(S)
this talks about "text". a paragraph is text. according to this test - if I have a paragraph of white text over a background of broad black and white stripes - the text passes as long as one piece of one character of the text I over the black background.

Changes suggested
1) change 'any character' to 'every character' or 'each character'
2) change to "if anti-aliasing or dithering is used - choose the darkest part of a character's stem and evaluate it against the darkest part of the background adjacent to it.
3) if the character or the background is not homogeneous - then choose the darkest pixel at different points along the stem and compare to the darkest part of the background adjacent to it.
Oliver Keim I approve of the rule being published
Laura Carlson I approve of the rule being published
Michael Gower I approve of the rule being published with adjustments (please comment) It's only tackling text, not images of text here, correct? Is it worth stating that explicitly?

The wording "highest possible contrast of every text character" put up warning bells for me, because we've tended to require _every_ pixel of all text characters to pass (ignoring antialiasing). But I don't see any situation where you have some pixels passing and others failing; even in the ones with gradient backgrounds, all characters seem to pass (or fail). We may need to explore some more examples.

Failure 8 is borderline to me. I agree the text _should_ meet contrast and that it is not "entirely decorative", but using the phrase "not only for aesthetic purposes" is unfortunate here -- and indicates why this is barely in scope. There is NO other reason to show the 'quick brown fox' phrase _except_ aesthetics. The text is there just to show what the characters look like; the nature of the font family is the information it provides (and the reason to me it fails to meet 'entirely decorative'). But the words are only there because they contain all the letters of the English alphabet. It could as easily just be the letters A-Z, so it _almost_ meets the substitute characters test.

I need to better understand the SVG in Inapplicable #4. What does it matter if it isn't in HTML? It's still text, and still on a web page.


Stefan Schnabel I approve of the rule being published
Gundula Niemann I approve of the rule being published with adjustments (please comment) The grammar in the expectation leaves it unclear, when to fulfill which contrast threshold. This should be changed.

Suggestion:
For each test target, the highest possible contrast between the foreground colors and background colors is at least 4.5:1 for smaller scale text or 3.0:1 for larger scale text, respectively, except if the test target is part of a text node that is purely decorative or does not express anything in human language.

Next, I do not agree to the exception:
When is a text purely decorative?
Text in non-human language can be subject of information as well, like examples for fonts, riddle text, encrypted text, so I recommend to drop the second exception.
Is a mathematical formula part of human language?
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki I approve of the rule being published with adjustments (please comment) +1 to 3 changes suggested by Gregg.

For the Passed Example 5 and 6, each text size can be different for some different languages. For Japanese characters, the large text size for the Example 5 should be at least 22pt and the bold text size for the Example 6 should be 18pt, as calculated in the JIS (Japanese national standard). It might be good enough to add a note to avoid misunderstanding, saying that these text sizes can be different for different languages.
Detlev Fischer I approve of the rule being published with adjustments (please comment) Should an assumptinon be added that the test is valid only for a specific viewport width, to account for the not infrequent situation of text being sufficiently contrasty at some viewport width but not at another?

I have understood the wording "highest possible contrast of every text character" as meaning that if there are conforming alternate versions (say, style switchers improving contrast), the best available contrast should be checked. But now reading other replies, that may have been the wrong understanding. If it really means that for text on image or pattern backgrounds, you are to pick the most contrasting adjacent pixel even if most others are low contrast and the text is illegible in practice, this needs to be revised. Clarify?
Andrew Kirkpatrick I approve of the rule being published But I do wonder if it might make sense to have a small text and large text version of the same test?

3. New Rule: Text has enhanced contrast

The ACT Task Force would like to publish the following rule:

Text has enhanced contrast

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 9
I approve of the rule being published with adjustments (please comment) 3
I do not approve because (please comment) 1

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

Details

Responder New Rule: Text has enhanced contrastComments
Jaunita George I approve of the rule being published
Gregg Vanderheiden I do not approve because (please comment) (same comments as for last item)
Oliver Keim I approve of the rule being published
Laura Carlson I approve of the rule being published
Michael Gower
Stefan Schnabel I approve of the rule being published
Gundula Niemann I approve of the rule being published with adjustments (please comment) Similar to above.

Suggestion:
For each test target, the highest possible contrast between the foreground colors and background colors is at least 7:1 for smaller scale text or 4.5:1 for larger scale text, respectively, except if the test target is part of a text node that is purely decorative or does not express anything in human language.

Next, I do not agree to the exception:
When is a text purely decorative?
Text in non-human language can be subject of information as well, like examples for fonts, riddle text, encrypted text, so I recommend to drop the second exception.
Is a mathematical formula part of human language?
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki I approve of the rule being published with adjustments (please comment) Same as my comment for the previous item.
Detlev Fischer I approve of the rule being published with adjustments (please comment) Same comment as to last rule testing 1.4.3.
Andrew Kirkpatrick I approve of the rule being published

4. DONE: New Rule: HTML page title is descriptive

The ACT Task Force would like to publish the following rule:

HTML page title is descriptive

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 12
I approve of the rule being published with adjustments (please comment) 1
I do not approve because (please comment) 2

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

Details

Responder DONE: New Rule: HTML page title is descriptiveComments
Jaunita George I approve of the rule being published How would this work without generating false positives? It seems like it wouldn't be able to evaluate whether the title itself is descriptive of the content.
Gregg Vanderheiden I approve of the rule being published
Oliver Keim I approve of the rule being published
Laura Carlson I approve of the rule being published
Michael Gower I approve of the rule being published with adjustments (please comment) Shouldn't a title existing be an Assumption (or pre-requisite) for this rule? It is somewhat covered in the Applicability section, but it feels a bit empty to me.

I want to note that there is no language in the requirement that the description be 'accurate' or even true.
I think including that inferred test for 'correctness' is wise in the ACT rule, but I also think the obvious problem with this proposed test is that there are NO criteria for how to judge "describes".

This is something that is vital to address in WCAG 3.0 (or at least try to). I personally think "true" is easier to test than "accurate", but both pose problems with real world assessments. Say the topic is about cats and dogs, and the title is "Dogs" ; or the title is "Cats and dogs" and the content is only cats. Those are simplistic examples, but hopefully it's obvious how while it is likely to get okay inter-rater reliability when something is truly wrong (or clearly correct), there's a lot of room in the middle when something is 'maybe'. This is less of a problem here than in 1.1.1 where there's an qualitative assessment of "equivalent purpose", but it's still a bit tricky.

I also feel like this should indicate the test is manual?
Stefan Schnabel I do not approve because (please comment) Descriptivitiy is not machine checkable. If the idea of the check is PRESENCE then the rule has to be differently worded, like "HTML page title is unique" or something similar.
Gundula Niemann I do not approve because (please comment) The test steps talk about availability of title, the examples talk about the title being semanticay appropriate. This does not match.
Is this supposed for machine testing or human testing?
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi I approve of the rule being published Future consideration 1: the icons in the Implementations section table - report column have proper alt text, however, do not distinguish for those with vision that these are 2 separate reports. Also, the icon looks similar to the icon sometimes used to indicate wifi connectivity. Recommend consideration of adding text to support the understanding of the icon.

Future consideration 2: the "web page definition (HTML)" says "Note: Web pages as defined by WCAG are not restricted to the HTML technology but can also include, e.g., PDF or DOCX documents." Recommend adding a PDF example into the Test Cases. Rationale: the way this is written is excellent for learning, and validating if you have done this correctly. PDFs can have the file name as the title that displays for the document, or the document title when opened in a PDF viewer. Demonstrating what would pass and what would fail for this scenario would be helpful to those that validate the webpages but are less familiar with PDF accessibility techniques.
Makoto Ueki I approve of the rule being published
Detlev Fischer I approve of the rule being published @ Mike's observation that there are NO criteria for how to judge "describes":

I do believe that 'describes' implies an equivalence relationship and is baseline useful here at the very least to detect clear fails.
That there are grey areas / variability / openness in assessing equivalence (as in image alternatives and elsewhere) is true, but that is an age-old problem and the very reason why it is so difficult to formalise any of this in a succinct rule.

@Gundula Niemann: the test is whether title "describes the topic or purpose of that page", which is more than checking mere availability.
Andrew Kirkpatrick I approve of the rule being published

5. DONE: New Rule: Image accessible name is descriptive

The ACT Task Force would like to publish the following rule:

Image accessible name is descriptive

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 11
I approve of the rule being published with adjustments (please comment) 1
I do not approve because (please comment) 1

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

Details

Responder DONE: New Rule: Image accessible name is descriptiveComments
Jaunita George I approve of the rule being published How much has this been tested? I would think it might generate quite a few false positives.
Gregg Vanderheiden I approve of the rule being published
Oliver Keim I approve of the rule being published
Laura Carlson I approve of the rule being published
Michael Gower I approve of the rule being published with adjustments (please comment) Like the last one, there seems to me to be an Assumption -- or more accurately, pre-requisite -- that the image _has_ a name. Maybe that's covered by the Applicability?

Even more than the last one, I think the test fails to provide any criteria for what constitutes "descriptive"; especially given the normative wording need that it "serves the equivalent purpose".

Stefan Schnabel I do not approve because (please comment) Descriptivitiy is not machine checkable. If the idea of the check is PRESENCE then the rule has to be differently worded, like "Image accessible name is not present" or something similar.
Gundula Niemann
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki I approve of the rule being published
Detlev Fischer I approve of the rule being published @ Stefan Schnabel: Descriptivitiy is not machine checkable.

True, at least not reliably and fully. But the rule does not say that the check for descriptiveness is necessarily automatic. Should the rule itself (all rules) be more explicit about this issue of what can be checked fully automatically and what cannot?
Andrew Kirkpatrick I approve of the rule being published

6. DONE: Streamline ARIA rule approval process

The ACT Task Force has several proposed rules written specifically for testing WAI-ARIA. The ACT Task Force is collaborating with the ARIA Working Group on these rules. To streamline the process of publishing ARIA-specific rules, the ACT Task Force requests standing permission from the Accessibility Guidelines Working Group to publish ARIA-specific rules as "approved", once these are approved by the ARIA Working Group.

Grant standing approval to publish ARIA-specific ACT Rules, once approved by the ARIA Working Group:

Summary

ChoiceAll responders
Results
I approve 8
I approve, under the following conditions 3
I do not approve for the following reason

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

Details

Responder DONE: Streamline ARIA rule approval processComments
Jaunita George I approve
Gregg Vanderheiden I approve, under the following conditions That the ACT task force review then and bring any that they think are questionable - after discussing with ARIA group - to the attention of the WG. (I don't expect there to be many or even any - but ACT should have the ability to have a different opinion from ARIA group.)
Oliver Keim I approve
Laura Carlson
Michael Gower
Stefan Schnabel I approve
Gundula Niemann
Wilco Fiers I approve
Todd Libby I approve
Shadi Abou-Zahra I approve
Bruce Bailey I approve
Alastair Campbell I approve, under the following conditions Please email to the WCAG list the recently updated rules that haven't been through AG surveys.
Jennifer Delisi
Makoto Ueki I approve
Detlev Fischer Do not feel in a position to assess benefits vs. risks of granting that permissiom.
Andrew Kirkpatrick I approve, under the following conditions The WG is notified of new rules that are approved by the ARIA WG and if issues are identified by AGWG members that the rules can be modified if the larger WG agrees that it is needed.

7. DONE: Menuitem has non-empty accessible name

The ACT Task Force would like to publish the following rule:

Menuitem has non-empty accessible name

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 10
I approve of the rule being published with adjustments (please comment) 1
I do not approve because (please comment)

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

Details

Responder DONE: Menuitem has non-empty accessible nameComments
Jaunita George I approve of the rule being published
Gregg Vanderheiden I approve of the rule being published with adjustments (please comment) Should the "" be removed? Might it make it look like "empty" is defined as two quotes (similar to the "" to indicated an decorative graphic in ALT TEXT .

Each target element has an accessible name that is not empty ("").
Oliver Keim I approve of the rule being published
Laura Carlson I approve of the rule being published
Michael Gower I approve of the rule being published
Stefan Schnabel I approve of the rule being published
Gundula Niemann I approve of the rule being published
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki
Detlev Fischer
Andrew Kirkpatrick

8. DONE: Scrollable element is keyboard accessible

The ACT Task Force would like to publish the following rule:

Scrollable element is keyboard accessible

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 8
I approve of the rule being published with adjustments (please comment)
I do not approve because (please comment) 1

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

Details

Responder DONE: Scrollable element is keyboard accessibleComments
Jaunita George I approve of the rule being published
Gregg Vanderheiden I do not approve because (please comment) Maybe I am missing something -- but I do not see that this test in any ways tests whether the Scrollable element is keyboard accessible/usable. Only that it is keyboard focusable (or elements in it are)
This could be that I misunderstand what a "scrollable element" is -- but it is defined in the materials and I don't see how the test ensures that I can fully scroll it from the keyboard (visually as well as functionally)
Oliver Keim I approve of the rule being published
Laura Carlson I approve of the rule being published
Michael Gower
Stefan Schnabel I approve of the rule being published
Gundula Niemann I understand a rule does not necessarily yield a complete test, is that correct?
That is, passing does not mean compliance with the corrsponding SC?
In that case I approve.
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki
Detlev Fischer
Andrew Kirkpatrick

9. DONE: Iframe with interactive elements is not excluded from tab-order

The ACT Task Force would like to publish the following rule:

Iframe with interactive elements is not excluded from tab-order

Do you agree with the proposal from the ACT Task Force to publish this rule?

Summary

ChoiceAll responders
Results
I approve of the rule being published 9
I approve of the rule being published with adjustments (please comment)
I do not approve because (please comment)

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

Details

Responder DONE: Iframe with interactive elements is not excluded from tab-orderComments
Jaunita George I approve of the rule being published
Gregg Vanderheiden I approve of the rule being published
Oliver Keim I approve of the rule being published
Laura Carlson I approve of the rule being published
Michael Gower
Stefan Schnabel I approve of the rule being published
Gundula Niemann
Wilco Fiers I approve of the rule being published
Todd Libby I approve of the rule being published
Shadi Abou-Zahra I approve of the rule being published
Bruce Bailey I approve of the rule being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki
Detlev Fischer
Andrew Kirkpatrick

10. DONE: Update currently approved rules

The ACT Task Force would like to update the existing rules. These changes include:

  1. Upgrade to WAI-ARIA 1.2 (as requested by ARIA WG) (example)
  2. New ARIA 1.2 related test cases (example)
  3. Address inconsistent language in accessibility supported section (example)
  4. Remove accessibility support note about title attributes (example)
  5. Add background on image buttons and alt attributes (example)

In all, this updates the following rules:

  1. Object element rendering non-text content has non-empty accessible name (diff)
  2. SVG element with explicit role has non-empty accessible name (diff)
  3. Element with presentational children has no focusable content (diff)
  4. Headers attribute specified on a cell refers to cells in the same table element (diff)
  5. Form field has non-empty accessible name (diff)
  6. Autocomplete attribute has valid value (diff)
  7. Element marked as decorative is not exposed (diff)
  8. HTML page has non-empty title (diff)
  9. Image has non-empty accessible name (diff)
  10. Image button has non-empty accessible name (diff)
  11. Link has non-empty accessible name (diff)
  12. Button has non-empty accessible name (diff)
  13. HTML page has lang attribute (diff)
  14. HTML page lang attribute has valid language tag (diff)

Summary

ChoiceAll responders
Results
I approve of the updated being published 7
I approve of the updated being published with adjustments (please comment) 1
I do not approve because (please comment)

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

Details

Responder DONE: Update currently approved rulesComments
Jaunita George I approve of the updated being published
Gregg Vanderheiden I approve of the updated being published with adjustments (please comment) 1) EDITORIAL - NO NEED FOR DISCUSSION - EDITOR CAN ACCEPT OR REJECT
in the following text: "... are several popular browsers that do not treat images with empty alt attribute as having a role of presentation but instead add the img element to the accessibility tree with a semantic role of either img or graphic .)
add (ALT="") in parentheses so it reads "... empty alt attribute (ALT="")...

2) what in is "MAJOR" crossed out in for Accessibility Support in " Headers attribute specified on a cell refers to cells in the same table element" but it is added in for "Image button has non-empty accessible name" and " Image button has non-empty accessible name " ??


3)
Oliver Keim I approve of the updated being published
Laura Carlson
Michael Gower
Stefan Schnabel I approve of the updated being published
Gundula Niemann
Wilco Fiers I approve of the updated being published
Todd Libby I approve of the updated being published
Shadi Abou-Zahra I approve of the updated being published
Bruce Bailey I approve of the updated being published
Alastair Campbell
Jennifer Delisi
Makoto Ueki
Detlev Fischer
Andrew Kirkpatrick

More details on responses

  • Jennifer Delisi: last responded on 9, January 2023 at 14:47 (UTC)
  • Makoto Ueki: last responded on 10, January 2023 at 10:20 (UTC)
  • Detlev Fischer: last responded on 10, January 2023 at 15:29 (UTC)
  • Andrew Kirkpatrick: last responded on 10, January 2023 at 15:29 (UTC)

Non-responders

The following persons have not answered the questionnaire:

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

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.