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. Rachael Bradley Montgomery
  53. Francis Storr
  54. Rick Johnson
  55. David Swallow
  56. Aparna Pasi
  57. Gregorio Pellegrino
  58. Melanie Philipp
  59. Jake Abma
  60. Nicole Windmann
  61. Ruoxi Ran
  62. Wendy Reid
  63. Scott O'Hara
  64. Charles Adams
  65. Muhammad Saleem
  66. Amani Ali
  67. Trevor Bostic
  68. Jamie Herrera
  69. Shinya Takami
  70. Karen Herr
  71. Kathy Eng
  72. Cybele Sack
  73. Audrey Maniez
  74. Arthur Soroken
  75. Daniel Bjorge
  76. Kai Recke
  77. David Fazio
  78. Daniel Montalvo
  79. Mario Chacón-Rivas
  80. Michael Gilbert
  81. Caryn Pagel
  82. Achraf Othman
  83. Helen Burge
  84. Fernanda Bonnin
  85. Christina Adams
  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. Olivia Hogan-Stark
  111. Rashmi Katakwar
  112. Julie Rawe
  113. Duff Johnson
  114. Laura Miller
  115. Will Creedle
  116. Shikha Nikhil Dwivedi
  117. Marie Csanady
  118. Meenakshi Das
  119. Perrin Anto
  120. Rachele DiTullio
  121. Jan Jaap de Groot
  122. Rebecca Monteleone
  123. Ian Kersey
  124. Peter Bossley
  125. Anastasia Lanz
  126. Michael Keane
  127. Chiara De Martin
  128. Giacomo Petri
  129. Andrew Barakat
  130. Devanshu Chandra
  131. Xiao (Helen) Zhou
  132. Joe Lamyman
  133. Bryan Trogdon
  134. Mary Ann (MJ) Jawili
  135. 禹佳 陶
  136. 锦澄 王
  137. Stephen James
  138. Jay Mullen
  139. Thorsten Katzmann
  140. Tony Holland
  141. Kent Boucher
  142. Abbey Davis
  143. Phil Day
  144. Julia Kim
  145. Michelle Lana
  146. David Williams
  147. Mikayla Thompson
  148. Catherine Droege
  149. James Edwards
  150. Eric Hind
  151. Quintin Balsdon
  152. Mario Batušić
  153. David Cox
  154. Sazzad Mahamud
  155. Katy Brickley
  156. Kimberly Sarabia
  157. Corey Hinshaw
  158. Ashley Firth
  159. Daniel Harper-Wain
  160. Kiara Stewart
  161. DJ Chase
  162. Suji Sreerama
  163. Lori Oakley
  164. David Middleton
  165. Alyssa Priddy
  166. Young Choi
  167. Nichole Bui
  168. Julie Romanowski
  169. Eloisa Guerrero
  170. George Kuan
  171. YAPING LIN
  172. Justin Wilson
  173. Leonard Beasley
  174. Tiffany Burtin
  175. Shane Dittmar
  176. Nayan Padrai
  177. Niamh Kelly
  178. Matt Argomaniz Matthew Argomaniz
  179. Frankie Wolf
  180. Kimberly McGee
  181. Ahson Rana
  182. Carolina Crespo
  183. humor927 humor927
  184. Samantha McDaniel
  185. Matthäus Rojek
  186. Phong Tony Le
  187. Bram Janssens
  188. Graham Ritchie
  189. Aleksandar Cindrikj
  190. Jeroen Hulscher
  191. Alina Vayntrub
  192. Marco Sabidussi
  193. John Toles
  194. Jeanne Erickson Cooley
  195. Theo Hale
  196. Gert-Jan Vercauteren
  197. Karla Rubiano
  198. Aashutosh K
  199. Hidde de Vries
  200. Julian Kittelson-Aldred
  201. Roland Buss
  202. Aditya Surendranath
  203. Avon Kuo
  204. Elizabeth Patrick
  205. Tj Squires
  206. Nat Tarnoff
  207. Illai Zeevi
  208. Filippo Zorzi
  209. Gleidson Ramos
  210. Mike Pedersen
  211. Rachael Yomtoob
  212. Oliver Habersetzer
  213. Irfan Mukhtar
  214. Sage Keriazes

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.