W3C WBS Home

Results of Questionnaire ISSUE-31/80: Text Alternative Examples - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-29 to 2011-04-05.

8 answers have been received.

Jump to results for question:

  1. Objections to letting HTML5 define the requirements
  2. Objections to using the "Techniques for providing useful text alternatives"
  3. Objections to using WCAG 2.0 to define the requirements

1. Objections to letting HTML5 define the requirements

We have a Change Proposal that lets requirements on the possible values of the text aternatives to be defined by the current text in HTML5. If you have strong objections to this Change Proposal then please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to letting HTML5 define the requirements
Ian Hickson
John Foliot This is less of a technical question, and rather more of a philosophical question.

It is my belief that creating modular components of a larger specification such as HTML5 allows for greater flexibility and responsiveness. The most current and complete author guidance emerging from the work-effort behind HTML5 is "Techniques for providing useful text alternatives" – a document that is being written in concert with the HTML5 effort, and one that has PFWG/WAI support. It is my belief that this is the best way forward to addressing the question on where and which specification should define requirements on the possible values of text alternative examples.

Given that, I object to this change proposal as the only means to endorse moving all author guidance for accessible and appropriate text alternatives to "HTML5: Techniques for providing useful text alternatives" (http://dev.w3.org/html5/alt-techniques/). I note that at this time this document is still in Editor's Draft, and any questions and concerns over appropriate language can continue to evolve around that document, speeding closure of HTML5 Issues and bringing it to Last Call.
Silvia Pfeiffer
Leif Halvard Silli I object to keeping @alt guidance in the HTML5 spec on the grounds that HTML5 should just have one spec which defines these issues. As long as @alt is defined in HTML5, we will have two specs defining the same issue - HTML5 and Steve's sepc. Thus I support Ian's view about Steves doc that we if/when we go for that option, should strip out all material regarding @alt from the main HTML5 spec.

Thus, I support that all unfinished debates and issues regarding these issuses, are moved to the Techniques document. (That document may have to be expanded a bit more.) Thus, do not necessarily say that the Techniques document is perfect and that I agree with everything there.

The benefits of the the HTML5 spec's definitions of @alt, is that it is rather simple. However, it hides a lot of complexity.
Laura Carlson Having W3C WAI specifications and W3C HTML5 specifications that provide conflicting text alternatives examples is bad. It will lead to confused authors.

Having two specifications in HTML5 with conflicting text alternatives examples is also bad. It not only will lead to confused authors, it is poor language design. HTML5 should not contradict HTML5. It adds complexity and ambiguity. This is a symptom of a language that doesn't do its job.

HTML5 (4.8.2.1.1 to 4.8.2.1.11) conflicts with "HTML5: Techniques for providing useful text alternatives" document [1] which is much more consistent with W3C accessibility guidelines, developed over many years, than the advice currently in the HTML5 draft. Ian's document follows his own personal accessibility rules based on his own personal perspective of accessibility. Some things are very wrong. Some examples between the two documents directly clash. For instance CAPTCHA [2], Webcam [3], and title [4] examples in HTML5 directly contradict examples in the techniques document [5] [6].

If it is desired to have text alternative information in both a standalone document AND in the HTML5 spec, as stated in the second option of the details section of Steve's proposal [7] we would need to ensure that both documents:

* Are in harmony and do not contradict each other.
* Do not get out of sync.
* Are consistent with W3C accessibility guidelines.

This could be accomplished with a server-side-include to replace and thereby correct the contents of 4.8.2.1.1 to 4.8.2.1.11 in the HTML spec with "HTML5: Techniques for providing useful text alternatives". Using the techniques document, as the source would also reduce maintenance of the HTML spec as the techniques document would provide content to the HTML5 spec. To insure overall W3C consistency the techniques document would need to be vetted by WAI.

The more choices you give people, the harder it is for them to choose, and the more likelihood of them getting things wrong. Too many or conflicting examples adds complexity and leads to confusion. In contrast a narrow, focused set of examples leads to clarity, which leads to more authors getting it right.

"The Paradox of Choice: Why More Is Less" (Barry Schwartz; Ecco, 2003) shows that a bewildering array of choices floods a person 's brain, ultimately restricting instead of freeing. We normally assume that more options ('easy fit' or 'relaxed fit'?) will make us happier, but Schwartz demonstrates the opposite is true. Too many choices actually makes things more difficult. Hick's Law (Hick, William E.; On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4:11-26, 1952) states the time it takes to make a decision increases as the number of alternatives increases.

More choice equals more time required, more anxiety, and difficult learnability. Simplicity is treading a line. Antoine de Saint-Exupery said, "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away." It comes across as magic when it works. That is a high achievement. It is what HTML5 should aim for.

--

Note: In response to Ian's comments on the two other proposals, "If we do this we should make sure to strip out all content regarding alt="" from the W3C HTML spec, so that there are no contradictory statements across specs." alt values are not machine checkable whereas a set of machine checkable validity options are. Automatic validators can programmatically determine the presence or absence of text alternatives on an <img> element in order for <img> to be considered valid. So there would be no conflict between specs in that regard.

References:

[1] http://dev.w3.org/html5/alt-techniques/
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9216
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9215
[4] http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203
[5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9169
[6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9174
[7] http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209
Henri Sivonen
Steve Faulkner I object to this proposal as it calls to "Change nothing" which is evidently inadequate as the working group has not reached consensus. The development of best practices for the provision of text alternatives is a work in progress, and is definitley not represented well by the current HTML5 spec text. It claims the current text in the HTML5 spec "includes detailed requirements and examples" but these are clearly lacking in scope and detail and some of them directly contradict normative advice found in WCAG 2.0 and HTML5: Techniques for providing useful text alternatives. The HTML5 specification should define when the presence/absence of the alt attribute for instances where this is machine checkable otherwise it should point developers to 'HTML5: Techniques for providing useful text alternatives' a document that provides more extensive coverage than the HTML5 spec text and harmonizes its best practice advice with WCAG 2.0.

Having HTML5 best practice text alternative advice in a document seperate from the main HTML5 specification means that important details and examples issues can be fully provided, maintained and updated without the need to update the HTML5 specification each timean update is required. It will allow the various stakeholders in the community to have continuing input into the development of the advice. Also it means that the development can continue independent of the bottleneck created by having one person controlling the editing of content of the HTML5 specification.

my objections are further elaborated in the chnage proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209
Edward O'Connor

2. Objections to using the "Techniques for providing useful text alternatives"

We have a Change Proposal would let the requirements on the possible values of text alternatives to be defined by "Techniques for providing useful text alternatives". If you have strong objections to this Change Proposal then please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to using the "Techniques for providing useful text alternatives"
Ian Hickson If we do this we should make sure to strip out all content regarding alt="" from the W3C HTML spec, so that there are no contradictory statements across specs.
John Foliot
Silvia Pfeiffer I actually like Steve's extensive document that explains clearly to authors how they should use @alt and @aria-describedby with many examples. However, I also agree that the HTML5 specification needs to fully contain a specification of all elements and attribute values of the HTML5 language. I fail, however, to understand why we cannot have both documents. The HTML5 specification can describe the technical requirements for @alt and @aria-describedby and what the values mean, and the "Techniques for providing useful text alternatives" can expand on that with all the examples it provides.
Leif Halvard Silli
Laura Carlson
Henri Sivonen
Steve Faulkner
Edward O'Connor The HTML specification should provide the requirements for the features that it defines. Web content authors, UA developers, and others consulting the spec would be done a disservice if the specification lacked a comprehensive description of <img>'s requirements, inluding those for all of its attributes.

While we support the continued publication of the "techniques for providing useful text alternatives" document, we believe it should be published in addition to, not in replacement of, the alt="" requirements already present in the HTML specification.

3. Objections to using WCAG 2.0 to define the requirements

We have a Change Proposal that propose to define the requirements for possible values of the text alternatives to be defined by WCAG 2.0. If you have strong objections to this Change Proposal then please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to using WCAG 2.0 to define the requirements
Ian Hickson If we do this we should make sure to strip out all content regarding alt="" from the W3C HTML spec, so that there are no contradictory statements across specs.
John Foliot This is less of a technical question, and rather more of a philosophical question.

It is my belief that creating modular components of a larger specification such as HTML5 allows for greater flexibility and responsiveness. The most current and complete author guidance emerging from the work-effort behind HTML5 is "Techniques for providing useful text alternatives" – a document that is being written in concert with the HTML5 effort, and one that has PFWG/WAI support. It is my belief that this is the best way forward to addressing the question on where and which specification should define requirements on the possible values of text alternative examples.

Given that, I object to this change proposal as the only means to endorse moving all author guidance for accessible and appropriate text alternatives to "HTML5: Techniques for providing useful text alternatives" (http://dev.w3.org/html5/alt-techniques/). I note that at this time this document is still in Editor's Draft, and any questions and concerns over appropriate language can continue to evolve around that document, speeding closure of HTML5 Issues and bringing it to Last Call.
Silvia Pfeiffer
Leif Halvard Silli I object ot this. HTML5 needs to provide its own text alternatives spec as the WCAG 2.0 is too general and when it provides examples, then they are not authoritative.
Laura Carlson
Henri Sivonen I object to deferring to WCAG 2.0, because doing so would make advice less detailed and less useful to Web authors. WCAG 2.0 itself doesn't contain any concrete examples, because WCAG 2.0 aims to be abstracted so highly that it is detached from concrete practicalities. Thus, it makes no sense to refer to WCAG 2.0 for any concrete specifics of a language feature. The WCAG 2.0 techniques document does not appear to be as comprehensive and does not appear to contain as useful examples as the texts proposed by the two other CPs.
Steve Faulkner
Edward O'Connor It would be inappropriate for the HTML specification to defer to WCAG 2.0 for alt="" requirements. WCAG 2.0's techniques for HTML and XHTML <URL:http://www.w3.org/TR/WCAG20-TECHS/html.html> were written with HTML 4.01 & XHTML 1.0, 1.1, and 2.0 in mind, and don't take into account the plethora of new, changed, or removed features in HTML5 & XHTML5, unlike the advice and requirements currently in the HTML specification. Even for features present in both HTML 4.01 and HTML 5, WCAG 2.0 is not as comprehensive and lacks sufficient examples for Web authors to reference.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <ion@ams.org>
  3. Richard Schwerdtfeger <schwer@us.ibm.com>
  4. Judy Brewer <jbrewer@w3.org>
  5. Wayne Carr <wayne.carr@linux.intel.com>
  6. Jason White <jason@jasonjgw.net>
  7. Liam Quin <liam@w3.org>
  8. Richard Ishida <ishida@w3.org>
  9. Chris Wilson <cwilso@google.com>
  10. Wendy Chisholm <wendc@microsoft.com>
  11. David Carlisle <davidc@nag.co.uk>
  12. James Helman <jhelman@movielabs.com>
  13. Jim Allan <jimallan@tsbvi.edu>
  14. Chris Marrin <cmarrin@apple.com>
  15. Charles McCathie Nevile <chaals@yandex-team.ru>
  16. Philippe Le Hégaret <plh@w3.org>
  17. Arthur Barstow <art.barstow@gmail.com>
  18. T.V. Raman <raman@google.com>
  19. David Singer <singer@apple.com>
  20. Cynthia Shelly <cyns@microsoft.com>
  21. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  22. Sean Hayes <sean.hayes@microsoft.com>
  23. Karl Dubost <karl@la-grange.net>
  24. Larry Masinter <masinter@adobe.com>
  25. David Baron <dbaron@dbaron.org>
  26. Lisa Seeman <lisa.seeman@zoho.com>
  27. Paul Cotton <Paul.Cotton@microsoft.com>
  28. Shane McCarron <shane@aptest.com>
  29. wu chou <wu.chou@huawei.com>
  30. Katsuhiko Momoi <momoi@google.com>
  31. Kangchan Lee <chan@w3.org>
  32. Roy Fielding <fielding@gbiv.com>
  33. Johnny Stenback <jst@mozilla.com>
  34. Janina Sajka <janina@rednote.net>
  35. Deborah Dahl <dahl@conversational-technologies.com>
  36. Frederick Hirsch <w3c@fjhirsch.com>
  37. Michael Cooper <cooper@w3.org>
  38. Glenn Adams <glenn@skynav.com>
  39. Jonathan Jeon <hollobit@etri.re.kr>
  40. David Hyatt <hyatt@apple.com>
  41. Robin Berjon <robin@w3.org>
  42. WonSuk Lee <wonsuk11.lee@samsung.com>
  43. Maciej Stachowiak <mjs@apple.com>
  44. Robert Accettura <robert@accettura.com>
  45. Jonathan Watt <jwatt@jwatt.org>
  46. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  47. Patrick Lauke <redux@splintered.co.uk>
  48. David MacDonald <David100@sympatico.ca>
  49. Jack Jansen <jack@cwi.nl>
  50. Boris Zbarsky <bzbarsky@mit.edu>
  51. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  52. Cyril Concolato <cyril.concolato@telecom-paristech.fr>
  53. Gez Lemon <glemon@paciellogroup.com>
  54. Pasquale Popolizio <p.popolizio@webprofession.com>
  55. Luca Mascaro <l.mascaro@webprofession.com>
  56. Markus Mielke <mmielke@microsoft.com>
  57. Arun Ranganathan <arun@mozilla.com>
  58. Jens Meiert <jens@meiert.com>
  59. Felix Sasaki <fsasaki@w3.org>
  60. Kazuyuki Ashimura <ashimura@w3.org>
  61. Daniel Burnett <dburnett@voxeo.com>
  62. Tomas Caspers <tomas@tomascaspers.de>
  63. Han Xu <collin@w3china.org>
  64. Sam Ruby <rubys@intertwingly.net>
  65. Jonas Sicking <jonas@sicking.cc>
  66. Mark Crawford <mark.crawford@sap.com>
  67. Doug Schepers <schepers@w3.org>
  68. Ian Fette <ifette@google.com>
  69. Michael[tm] Smith <mike@w3.org>
  70. Julian Reschke <julian.reschke@gmx.de>
  71. Kelly Ford <kelly.ford@microsoft.com>
  72. Cameron McCormack <cam@mcc.id.au>
  73. Jirka Kosek <jirka@kosek.cz>
  74. Robert O'Callahan <robert@ocallahan.org>
  75. Travis Leithead <Travis.Leithead@microsoft.com>
  76. Youngsun Ryu <ysryu@samsung.com>
  77. Sierk Bornemann <sierkb@gmail.com>
  78. Martijn Wargers <martijn.martijn@gmail.com>
  79. Simon Pieters <simonp@opera.com>
  80. James Graham <james@hoppipolla.co.uk>
  81. Lachlan Hunt <lachlan.hunt@lachy.id.au>
  82. Krijn Hoetmer <w3c@qontent.nl>
  83. Markus Fischer <markus@fischer.name>
  84. Dean Edridge <dean@dean.kiwi>
  85. Channy Yun <channy@gmail.com>
  86. Shane Thacker <shanethacker@gmail.com>
  87. Bill Mason <billm@accessibleinter.net>
  88. Vilem Malek <murphy@malek.cz>
  89. Zhihong Mao <zhihong.mao@gmail.com>
  90. Benoit Piette <benoit.piette@gmail.com>
  91. Erik van Kempen <erikvankempen@gmail.com>
  92. Jude Robinson <dotcode+w3@gmail.com>
  93. Dimitri Glazkov <dglazkov@chromium.org>
  94. Diego La Monica <d.lamonica@webprofession.com>
  95. Nick Fitzsimons <w3@nickfitz.co.uk>
  96. Josh Lawton <w3c@joshlawton.com>
  97. Giovanni Gentili <giovanni.gentili@gmail.com>
  98. Adele Peterson <adele@apple.com>
  99. Mateo Yadarola <teodalton@gmail.com>
  100. S Emerson <w3c@accretewebsolutions.ca>
  101. Andrew Fedoniouk <a.fedoniouk@gmail.com>
  102. Morten Tollefsen <morten@medialt.no>
  103. Daniel Schattenkirchner <schattenkirchner.daniel@gmx.de>
  104. Justin Anthony Knapp <justinkoavf@gmail.com>
  105. Simon Myers <Smylers@stripey.com>
  106. Samuel Weinig <weinig@apple.com>
  107. Alexey Proskuryakov <ap@webkit.org>
  108. Alejandro Fernandez <alejandro@mediadvanced.com>
  109. Doug Jones <doug_b_jones@me.com>
  110. Marc Drumm <mdrumm@wcupa.edu>
  111. Danny Liang <danny.glue@gmail.com>
  112. Arne Johannessen <arne@thaw.de>
  113. Michael Puls II <shadow2531@gmail.com>
  114. Clair Dunn <cadunn@vt2000.com>
  115. Ron Reisor <ron@udel.edu>
  116. Marat Tanalin <mtanalin@yandex.ru>
  117. Andrew Norman <idonothaveacat@gmail.com>
  118. Craig Buckler <craigbuckler@gmail.com>
  119. Brian Peppler <bpeppler@gmail.com>
  120. Matthew Turvey <mcturvey@gmail.com>
  121. Dale Hudjik <dale.hudjik@gmail.com>
  122. James Cassell <w3c@cyberpear.com>
  123. Joseph D'Andrea <jdandrea@gmail.com>
  124. Pietro Russo <p.russo@webprofession.com>
  125. Moto Ishizawa <summerwind.jp+w3c@gmail.com>
  126. Chris Adams <chris@tuesdaybegins.com>
  127. Eric Carlson <eric.carlson@apple.com>
  128. Michael Turnwall <w3c@turnwall.net>
  129. Don Kiely <donkiely@computer.org>
  130. Robert Marshall <rdm@rdmsoft.com>
  131. Jane Lee <applegoddess@gmail.com>
  132. David Child <dave@addedbytes.com>
  133. Mark DuBois <Mark@webprofessionals.org>
  134. David Choi <daaave@gmail.com>
  135. David Bills <w3@dfbills.com>
  136. Nik Thierry <me@thisemail.ca>
  137. Andrew Ramsden <andrew@irama.org>
  138. Shefik Macauley <allknightaccess@gmail.com>
  139. Joe Steele <steele@adobe.com>
  140. John Vernaleo <john@netpurgatory.com>
  141. Jeremy Keith <jeremy@adactio.com>
  142. Jedi Lin <JediLin@Gmail.com>
  143. Manu Sporny <msporny@digitalbazaar.com>
  144. Kenny Johar <kensingh@microsoft.com>
  145. Jon Hughes <jon@phazm.com>
  146. Anssi Kostiainen <anssi.kostiainen@intel.com>
  147. Samuel Santos <samaxes@gmail.com>
  148. Dean Jackson <dino@apple.com>
  149. Mohammed DADAS <mohammed.dadas@orange.com>
  150. Sally Cain <sally.cain@rnib.org.uk>
  151. Dan Romascanu <dromasca@avaya.com>
  152. David Bolter <dbolter@mozilla.com>
  153. Chris Double <cdouble@mozilla.com>
  154. Jeanne F Spellman <jeanne@w3.org>
  155. James Craig <jcraig@apple.com>
  156. MING JIN <ming.jin.web@gmail.com>
  157. Leonard Rosenthol <lrosenth@adobe.com>
  158. Philip Jägenstedt <philipj@opera.com>
  159. Adrian Bateman <adrianba@microsoft.com>
  160. Dionysios Synodinos <synodinos@gmail.com>
  161. Jean-Pierre EVAIN <evain@ebu.ch>
  162. Mark Pilgrim <pilgrim@google.com>
  163. Matt Lee <mattl@cnuk.org>
  164. Magnus Olsson <magnus.olsson@ericsson.com>
  165. Carlos Cecconi <cecconi@nic.br>
  166. Chris Pearce <cpearce@mozilla.com>
  167. Dzung Tran <dzung.d.tran@intel.com>
  168. Mark Miller <erights@google.com>
  169. Andrew Wilson <atwilson@google.com>
  170. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  171. Ojan Vafai <ojan@chromium.org>
  172. Martin Kliehm <w3c@kliehm.com>
  173. Martin McEvoy <martin@weborganics.co.uk>
  174. Aryeh Gregor <ayg@aryeh.name>
  175. Gavin Carothers <gavin@carothers.name>
  176. Eliot Graff <eliotgra@microsoft.com>
  177. Frank Olivier <frank.olivier@microsoft.com>
  178. Jonathan Griffin <jgriffin@mozilla.com>
  179. Kris Krueger <krisk@microsoft.com>
  180. Erik Isaksen <erik_isaksen@hotmail.com>
  181. Anders Bondehagen <anders@bondehagen.com>
  182. Steven Pemberton <Steven.Pemberton@cwi.nl>
  183. Raul Hudea <rhudea@adobe.com>
  184. Raghavan Gurumurthy <raghavan@adobe.com>
  185. Mayank Kumar <mayankk@adobe.com>
  186. Monikandan S <smonikan@adobe.com>
  187. Dragos Georgita <dgeorgit@adobe.com>
  188. Christopher Bank <cbank@adobe.com>
  189. Dominik Tomaszuk <ddooss@wp.pl>
  190. Ole Riesenberg <or@oleriesenberg.com>
  191. Takuya Oikawa <takuya@google.com>
  192. Jatinder Mann <jmann@microsoft.com>
  193. Robert Stern <rstern@gmail.com>
  194. Dean Leigh <dean.leigh@deanleigh.co.uk>
  195. Eihab Ibrahim <eihabibrahim@gmail.com>
  196. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  197. Ian Pouncey <w3c@ipouncey.co.uk>
  198. Jer Noble <jer.noble@apple.com>
  199. Léonie Watson <lwatson@paciellogroup.com>
  200. Masatomo Kobayashi <mstm@jp.ibm.com>
  201. Peter Beverloo <beverloo@google.com>
  202. Andrew Scherkus <scherkus@google.com>
  203. Greg Johnson <greg.johnson@gmail.com>
  204. Martijn Croonen <martijn@martijnc.be>
  205. John Jansen <johnjan@microsoft.com>
  206. Stanley Manoski <manoski@mitre.org>
  207. Jonas Schneider <js.sokrates@gmail.com>
  208. Yosuke Funahashi <yosuke@funahashi.cc>
  209. Mounir Lamouri <mlamouri@google.com>
  210. Mike Amundsen <mamund@yahoo.com>
  211. Tony Gentilcore <tonyg@google.com>
  212. Jacob Rossi <Jacob.Rossi@microsoft.com>
  213. Joseph Pecoraro <pecoraro@apple.com>
  214. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  215. Shoko Okuma <okuma@tomo-digi.co.jp>
  216. Fumitaka Watanabe <fwtnb@tomo-digi.co.jp>
  217. Yoshimitsu Tsurimaki <tsurimaki@tomo-digi.co.jp>
  218. Juhani Huttunen <juhani.huttunen@nokia.com>
  219. Bob Lund <b.lund@cablelabs.com>
  220. Tatsuya Igarashi <Tatsuya.Igarashi@jp.sony.com>
  221. John Simmons <johnsim@microsoft.com>
  222. Mathias Bynens <mathias@qiwi.be>
  223. Mark Watson <watsonm@netflix.com>
  224. Clarke Stevens <c.stevens@cablelabs.com>
  225. Mark Vickers <mark_vickers@cable.comcast.com>
  226. Sree Kotay <Sree_Kotay@cable.comcast.com>
  227. Cameron Jones <cmhjones@gmail.com>
  228. Rik Cabanier <Cabanier@adobe.com>
  229. Denis Ah-Kang <denis@w3.org>
  230. Alvar Laigna <laigna@gmail.com>
  231. Kunio Ito <kunio.ito@mail.rakuten.com>
  232. David Mays <david_mays@comcast.com>
  233. Michael Chen <michael_chen@cable.comcast.com>
  234. jongyoul Park <jongyoul@etri.re.kr>
  235. Adrian Roselli <roselli@algonquinstudios.com>
  236. Colin Ihrig <cjihrig@gmail.com>
  237. Kilroy Hughes <kilroy.hughes@microsoft.com>
  238. Reinaldo Ferraz <reinaldo@nic.br>
  239. Bill Mandel <bill.mandel@nbcuni.com>
  240. Jonas Jacek <w3c@jonas.me>
  241. Eva Lingyun Jing <jinglingyun@baidu.com>
  242. GANG LIANG <gang.liang@huawei.com>
  243. Ryosuke Niwa <rniwa@apple.com>
  244. Jason Kiss <jason@accessibleculture.org>
  245. Gian Luca Marroni <gmarroni@libero.it>
  246. Ian Devlin <ian@iandevlin.com>
  247. Greg Billock <gbillock@google.com>
  248. Xingrong Guo <guoxingrong@baidu.com>
  249. Jet Villegas <w3c@junglecode.net>
  250. Anas R. <anas.ram@gmail.com>
  251. Alexander Surkov <surkov.alexander@gmail.com>
  252. wilfred nas <wilfred@wnas.nl>
  253. Hasan Savran <hsavran@kent.edu>
  254. Ben Dalton <bendalton@gmail.com>
  255. Alessandro Bassi <apbassi89@gmail.com>
  256. Marco Kotrotsos <Marco@mlabs.nl>
  257. Brian Blakely <anewpage.media@gmail.com>
  258. Eric VonColln <eric.voncolln@navy.mil>
  259. Jason Boyd <jason@pixelboxdesign.co.uk>
  260. Jerry Jiang <jerry@ucweb.com>
  261. Arun Patole <arun.patole@motorola.com>
  262. Jungkee Song <jungkee.song@samsung.com>
  263. Huan Ren <renhuan@360.cn>
  264. Songnan Ran <ransn@ucweb.com>
  265. Rayi Lei <leiyi@baidu.com>
  266. Daniel Austin <daniel@thestarsmydestination.com>
  267. David Dorwin <ddorwin@google.com>
  268. jiexuan gao <gaojiexuan@baidu.com>
  269. Mathew Marquis <mat@matmarquis.com>
  270. Xiaoqing Yang <yangxiaoqing@baidu.com>
  271. Aaron Colwell <acolwell@google.com>
  272. Alex Giladi <alex.giladi@huawei.com>
  273. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  274. Kevin Streeter <kstreete@adobe.com>
  275. jean-baptiste henry <j.henry.ext@viaccess.com>
  276. Christian Kaiser <kaiserc@google.com>
  277. Ptah Dunbar <ptah@piratedunbar.com>
  278. François REMY <francois.remy.dev@outlook.com>
  279. Xuejian Li <lixuejian@baidu.com>
  280. Zuncheng Yang <yangzuncheng@baidu.com>
  281. Qianglong Zheng <zhengqianglong@baidu.com>
  282. Zhou Shen <shenzhou@baidu.com>
  283. Duoyi Wu <wuduoyi@baidu.com>
  284. Zheng Jia <jiazheng@baidu.com>
  285. Weifeng Feng <fengweifeng@baidu.com>
  286. Damin Hu <hudamin@baidu.com>
  287. Yang Liu <liuyang12@baidu.com>
  288. Zhixing Lei <leizhixing@baidu.com>
  289. Honggang Tang <tanghonggang@baidu.com>
  290. Kefeng Li <buaadallas@gmail.com>
  291. Manyoung Cho <manyoung@w3labs.kr>
  292. Xu Ma <maxu@baidu.com>
  293. Junzhong Liu <liujunzhong@baidu.com>
  294. Yusuke Maehama <maehama@tomo-digi.co.jp>
  295. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  296. Sheau Ng <Sheau.ng@nbcuni.com>
  297. Wei Wu <wuwei@w3.org>
  298. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  299. Ami Fischman <fischman@google.com>
  300. Arnaud Braud <arnaud.braud@orange.com>
  301. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  302. Bram Tullemans <tullemans@ebu.ch>
  303. Petr Peterka <ppeterka@verimatrix.com>
  304. lei wang <wanglei03@baidu.com>
  305. Milan Patel <Milan.Patel@huawei.com>
  306. Yiling Gu <guyiling@baidu.com>
  307. Yehuda Katz <wycats@gmail.com>
  308. Jay Munro <jaymunro@microsoft.com>
  309. Xueqing Huang <huangxueqing@baidu.com>
  310. Zefa Xiong <xiongzefa@baidu.com>
  311. shanglin chen <chenshanglin@baidu.com>
  312. Yaso Córdova <yaso@nic.br>
  313. Dongsheng Zhang <zhangdongsheng@baidu.com>
  314. Ping Wu <wuping02@baidu.com>
  315. Yao Tong <tongyao@baidu.com>
  316. Bin Chen <chenbin01@baidu.com>
  317. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  318. Patrick Ladd <Pat_Ladd2@cable.comcast.com>
  319. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  320. Billy Gregory <bgregory@paciellogroup.com>
  321. Hanrui Gao <gaohanrui@360.cn>
  322. Hao Jing <jh.jinghao@huawei.com>
  323. Glenn Deen <glenn.deen@nbcuni.com>
  324. Lei Wang <wanglei@baidu.com>
  325. Tom Handal <thandal@verimatrix.com>
  326. Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>
  327. Jose Segura <jose.segura@mail.rakuten.com>
  328. Pengcheng Guo <guopengcheng@baidu.com>
  329. Erika Doyle Navara <erika.doyle@microsoft.com>
  330. Tom Wiltzius <wiltzius@google.com>
  331. Pierre-Anthony Lemieux <pal@sandflow.com>
  332. Eric Whyne <ericwhyne@gmail.com>
  333. Xie Jianhui <xiejianhui@baidu.com>
  334. Guillermo Salazar <gsalazar1407@hotmail.com>
  335. Yujie Jiang <jiangyujie@baidu.com>
  336. Lauren O'Donovan <lauren.odonovan@gmail.com>
  337. Leslie Sikos <sikos@sikoswebconsulting.com.au>
  338. David Newton <david@davidnewton.ca>
  339. Mark Sadecki <mark.sadecki@gmail.com>
  340. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  341. Brady Eidson <beidson@apple.com>
  342. Reimundo Garcia <reimundo.garcia@hbo.com>
  343. Jerry Smith <jdsmith@microsoft.com>
  344. Michael Thornburgh <mthornbu@adobe.com>
  345. Cyril Rickelton-Abdi <cyril.rickelton-abdi@turner.com>
  346. Andrew Davis <papyromancer@gmail.com>
  347. Mick Hakobyan <mhakobyan@netflix.com>
  348. Angela Ricci <contact@thecodeplayground.net>
  349. Mallory van Achterberg <stommepoes@stommepoes.nl>
  350. Vladimir Sinelnikov <sinelnikov@gmail.com>
  351. Chris Wong <huanghoujin@baidu.com>
  352. Yiliang LIU <liuyiliang@baidu.com>
  353. David Sleight <hello@stuntbox.com>
  354. Hernan Beati <hernanbeati@gmail.com>
  355. mingqiang zhang <imcnan@gmail.com>
  356. yubo zhou <zhouyubo@360.cn>
  357. Ben Barber <barberboy@gmail.com>
  358. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  359. Grzegorz Babula <gbabula@gmail.com>
  360. xueliang fan <fanxueliang@baidu.com>
  361. Mikio Sasaki <Sasaki.Mikio@bc.MitsubishiElectric.co.jp>
  362. Niels Thorwirth <nthorwirth@verimatrix.com>
  363. David Evans <david.evans@rd.bbc.co.uk>
  364. Danny O'Brien <danny@eff.org>
  365. Joseph Karr O'Connor <josephoconnor@mac.com>
  366. Vanessa Me Tonini <vanessa@nic.br>
  367. Seth Schoen <schoen@eff.org>
  368. Jamil Ellis <jamil.ellis@hbo.com>
  369. Jim Walsh <jim@jwalshcreative.com>
  370. Jasper Valero <contact@jaspervalero.com>
  371. Greg Davis <greg.davis@pearson.com>
  372. Julio Cesar Serrano <mhysterio@gmail.com>
  373. Gabino Alonso <gabinovincent@gmail.com>
  374. Sam Langdon <sam.langdon@hachette.co.uk>
  375. Michael Kelly <mkelly@mozilla.com>
  376. Xiaoqian Wu <xiaoqian@w3.org>
  377. Yue Min <minyue@baidu.com>
  378. Min Li <limin04@baidu.com>
  379. Mark Boyle <boyle.mr@gmail.com>
  380. Sunghoon Moon <sunghoon@w3labs.kr>
  381. A.S. Krishnakumar <ask@avaya.com>
  382. Shijun Sun <shijuns@microsoft.com>
  383. Jonathan Neal <jonathantneal@gmail.com>
  384. Kei Gomita <Gomita.Kei@db.MitsubishiElectric.co.jp>
  385. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  386. diyar naozary <diyar.naozary@yahoo.com>
  387. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  388. Tetsushi Matsuda <Matsuda.Tetsushi@dh.MitsubishiElectric.co.jp>
  389. So Vang <svang@nab.org>
  390. Flavio Yanai <yanai@nic.br>
  391. Ben Peters <ben.peters@microsoft.com>
  392. Amy Brown <hello@amybrowndesign.com>
  393. Nathalia Sautchuk Patrício <nathalia@nic.br>
  394. Deblyn prado <deblyn@nic.br>
  395. Vicente García Díaz <vicegd@gmail.com>
  396. Nan Jiang <ayajiang@hotmail.com>
  397. Nolan Butcher <nolan.butcher@hbo.com>
  398. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  399. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  400. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>
  401. John Riviello <john_riviello@comcast.com>
  402. Shun-ichi Sekiguchi <Sekiguchi.Shunichi@eb.MitsubishiElectric.co.jp>
  403. Glenn Eguchi <geguchi@adobe.com>
  404. Hirofumi Nishikawa <Nishikawa.Hirofumi@cs.MitsubishiElectric.co.jp>
  405. Hiroyuki Yamada <Yamada.Hiroyuki@dn.MitsubishiElectric.co.jp>
  406. Chockalingam Muthian <chockam@gmail.com>
  407. Michelangelo De Simone <michelangelo.de-simone@nokia.com>
  408. Lukáš Čihák <lukas.cihak@mensa.cz>

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


Completed and maintained by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.123 2013-09-26 09:46:56 dom Exp $. Please send bug reports and request for enhancements to dom@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)