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. Peter Heery
  25. John Kirkwood
  26. Reinaldo Ferraz
  27. Matt Garrish
  28. Mike Gifford
  29. Loïc Martínez Normand
  30. Mike Pluke
  31. Jon Gibbins
  32. Justine Pascalides
  33. Chris Loiselle
  34. Tzviya Siegman
  35. Jan McSorley
  36. Sailesh Panchang
  37. Cristina Mussinelli
  38. Jonathan Avila
  39. John Rochford
  40. Sarah Horton
  41. Sujasree Kurapati
  42. Jatin Vaishnav
  43. Sam Ogami
  44. Kevin White
  45. E.A. Draffan
  46. Paul Bohman
  47. JaEun Jemma Ku
  48. 骅 杨
  49. Victoria Clark
  50. Avneesh Singh
  51. Mitchell Evan
  52. biao liu
  53. Scott McCormack
  54. Rachael Bradley Montgomery
  55. Francis Storr
  56. David Swallow
  57. Aparna Pasi
  58. Gregorio Pellegrino
  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. Raja Kushalnagar
  87. Jan Williams
  88. Isabel Holdsworth
  89. Julia Chen
  90. Marcos Franco Murillo
  91. Yutaka Suzuki
  92. Azlan Cuttilan
  93. Jennifer Strickland
  94. Joe Humbert
  95. Ben Tillyer
  96. Charu Pandhi
  97. Poornima Badhan Subramanian
  98. Alain Vagner
  99. Roberto Scano
  100. Rain Breaw Michaels
  101. Kun Zhang
  102. Regina Sanchez
  103. Shawn Thompson
  104. Thomas Brunet
  105. Kenny Dunsin
  106. Jen Goulden
  107. Mike Beganyi
  108. Ronny Hendriks
  109. Korede Olubowale
  110. Rashmi Katakwar
  111. Julie Rawe
  112. Duff Johnson
  113. Laura Miller
  114. Will Creedle
  115. Shikha Nikhil Dwivedi
  116. Marie Csanady
  117. Meenakshi Das
  118. Perrin Anto
  119. Brian Elton
  120. Rachele DiTullio
  121. Jan Jaap de Groot
  122. Rebecca Monteleone
  123. Ian Kersey
  124. Peter Bossley
  125. Michael Keane
  126. Chiara De Martin
  127. Giacomo Petri
  128. Andrew Barakat
  129. Devanshu Chandra
  130. Xiao (Helen) Zhou
  131. Joe Lamyman
  132. Bryan Trogdon
  133. Mary Ann (MJ) Jawili
  134. 禹佳 陶
  135. 锦澄 王
  136. Stephen James
  137. Jay Mullen
  138. Thorsten Katzmann
  139. Tony Holland
  140. Kent Boucher
  141. Phil Day
  142. Julia Kim
  143. Michelle Lana
  144. David Williams
  145. Mikayla Thompson
  146. Catherine Droege
  147. James Edwards
  148. Eric Hind
  149. Quintin Balsdon
  150. Mario Batušić
  151. David Cox
  152. Sazzad Mahamud
  153. Katy Brickley
  154. Kimberly Sarabia
  155. Corey Hinshaw
  156. Ashley Firth
  157. Daniel Harper-Wain
  158. Kiara Stewart
  159. DJ Chase
  160. Suji Sreerama
  161. Fred Edora
  162. Lori Oakley
  163. David Middleton
  164. Alyssa Priddy
  165. Young Choi
  166. Nichole Bui
  167. Julie Romanowski
  168. Eloisa Guerrero
  169. George Kuan
  170. YAPING LIN
  171. Justin Wilson
  172. Leonard Beasley
  173. Tiffany Burtin
  174. Shane Dittmar
  175. Nayan Padrai
  176. Matt Argomaniz Matthew Argomaniz
  177. Frankie Wolf
  178. Kimberly McGee
  179. Ahson Rana
  180. Carolina Crespo
  181. humor927 humor927
  182. Jackie Fei
  183. Samantha McDaniel
  184. Matthäus Rojek
  185. Phong Tony Le
  186. Bram Janssens
  187. Graham Ritchie
  188. Aleksandar Cindrikj
  189. Jeroen Hulscher
  190. Alina Vayntrub
  191. Marco Sabidussi
  192. John Toles
  193. Jeanne Erickson Cooley
  194. Theo Hale
  195. Paul Adam
  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. Elizabeth Patrick
  204. Tj Squires
  205. Nat Tarnoff
  206. Illai Zeevi
  207. Filippo Zorzi
  208. Gleidson Ramos
  209. Mike Pedersen
  210. Rachael Yomtoob
  211. Oliver Habersetzer
  212. Moaan Ahmed
  213. Irfan Mukhtar
  214. Rachel White
  215. Sage Keriazes
  216. Tananda Darling
  217. Nina Krauß
  218. Demelza Feltham
  219. Ragvesh Sharma
  220. Shunguo Yan
  221. Nora GOUGANE
  222. Tim Gravemaker
  223. Roldon Brown
  224. qin guan
  225. Alexandra Yaneva
  226. Carrie Hall

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.