W3C WBS Home

Results of Questionnaire ISSUE-142: No alternative text description for video key frame (poster) - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-10 to 2011-03-17.

4 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal for no poster short alternative text
  2. Objections to the Change Proposal to introduce a new child element to the video element.

1. Objections to the Change Proposal for no poster short alternative text

We have a Change Proposal to specify that there is no poster short alternative text. If you have strong objections to adopting this Change Proposal, 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 the Change Proposal for no poster short alternative text
Laura Carlson What this all boils down to is the ability to access content. If <video poster> provided no content <video poster> would not exist.

This change proposal states: "we provide the possibility of indicating an image which is more indicative of the content". [1]

HTML5 should have a mechanism to provide that indication to people with disabilities. Currently it does not. <firstframe> provides that possibility. It offers a mechanism to equitably obtain that same content currently in <video poster> to people with disabilities.

[1] http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/NoPosterAlt&oldid=9214
Kornel Lesinski
Philip Jägenstedt
Leif Halvard Silli I strongly object. This CP doesn't ensure that unsighted always can be provided access to:

A) sufficient or equal info before deciding to run a video;
B) alternative text for info that sighted get even without running the video;
(Point A) and B) are different sides of same coin.)
C) Also see Comments under C) below.

DETAILS:

A) <img>s are consumed instantly (by AT users too). But videos are consumed in 2 steps, where step 2 (running the video) depends on evaluation of
1) costs of running the video (time costs, quality costs/technical limits);
2) perceived benefits (info on the video's subject & "teasers")
PROBLEM 1: Different defaults: The benefits are more diffult to evaluate without a firstframe image than with a firstframe image. But, luckily for sighted, there always *is* a firstframe image even without whether @poster or <firstframe src=*>. Solution: a <firstframe src=* alt=*> with the authoring guidelines John propososes (see his General Principles section: http://www.w3.org/html/wg/wiki/ChangeProposals/PosterElement#General_Principles), helps authors to provide for unsighted what sighted get by default.
PROBLEM 2: Different needs: Just as for <img>, what unsighted need in text format is different from what sighted need in text format. E.g. imagine that the video's firstframe displays text. Solution: <firstframe alt=*> allows authors to take care of the difference.
PROBLEM 3: Same expectations: The firstframe image creates useful expectations about what to see: When starting a video, the exciting scene (or info) on the firstframe image might be preceded by dull footage or advertising. Someone who sees the firstframe image (all the sighted!) or at least read its description, would be less likely to stop playing the video early than someone with minimal clue about what to expect. Solution: <firstframe> allows authors to build up similar expectations within the unsighted audience as within the sighted audience.

B) To a sighted, the firstframe image can have value in itself. Speaking for myself, when news articles contain video I tend to "jump over" them, but I still eagerly consume their firstframe images. Thus, a firstframe image without a description is information-loss for the unsighted. An HTML standard where <img src=ExitingMoment > is covered by @alt and its usage guidelines, but were <video src=VideoWithAnExitingMomentAsTheFirstframeImage > does not have similar possibilities or guidelines, would be a missed opportunity.

C) Comments to certain claims:

C1) CP says: "it should be described as part of the description of the video element itself". But by which feature? <track> is synced with the video file and not with the still picture of the firstframe image. It should be as easy to change the firstframe text as it is to change the firstframe image - one shouldn't need to edit whether a <track> file or a video source file. John's CP also demoes that the firstframe could specify for whom the film is suitable: one should not need to read a longer, general video description to locate this. Plus that some of the firstframe's teaser effects could be lost if the firstframe text is mixed together with a general description of the video.

C2) The CP claims that because the firstframe image is "conceptually part of the media resource itself" it "should be described as part of the description of the video element itself". However, from a different angle, a firstframe image description *would* then be a video description, if but of a detail of it.

C3) The name: <firstframe> at first seemed unoptimal (e.g. because John's CP says that it could be used for <audio>). However, if we ignore <audio> (which has no image feature), and instead consider Sylvia Pfeiffer's point (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c76) that the user don't know whether the image stems from (in John's proposal) <firstframe src> or the movie file, then <firstframe> make very good sense.

C4) CP says that "'poster' is the term commonly used in the industry". May be. But for example such a thing as <param name="poster" value="*"> does not seem to exist for whether QuickTime, MediaPlayer or Flash.

C5) Comment on a poll comment by Philip Jägenstedt: Whether the firstframe image text must accurately reflect the firstframe image or simply be a text that could serve as a useful textual teaser, seems like an authoring guide question. For instance, if the video's firstframe shows what this CP describes as "a fade from black, the green MPAA rating, the roaring lion, etc", then it may not make sense to *require* the firstframe text to reflect this. John's CP says the author in such cases MAY omit <firstframe> (note: <firstframe> always requires @alt). However, if the author doesn't omit it, could the author then provide a text that was a tad more useful than the firstframe image itself? My answer would be: Yes, but then the author should also update the firstframe image.

2. Objections to the Change Proposal to introduce a new child element to the video element.

We have a Change Proposal to introduce a new child element to the video element.

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 the Change Proposal to introduce a new child element to the video element.
Laura Carlson
Kornel Lesinski * The proposal confuses poster frames with movie posters. It is not purpose of this attribute to serve as a movie poster, and I have not seen any indication of this happening in practice.
* In my experience most videos don't have carefully chosen poster frames that are good description of the video, and many videos have accompanying description which makes description of poster frame unnecessary.
* Description of only a single frame — which sometimes is not even chosen by the video author — can be misleading about video's content.
* I think it's unreasonable to expect that authors would describe both video and poster frame separately, and author's effort is better spent on describing the video itself.
* In case when poster frame is especially interesting, its description could be made part of the video description (it seems unlikely to me that one would like to learn about the poster and not about the video).

The proposal is mainly based on concern that authors *could* use image that contains unique and valuable information about the video. However, this does not happen in practice:

Poster frames on sites like YouTube or Vimeo are just one of the frames of the video. These frames are not specially crafted images that would be a good proxy for the entire video contents. Sometimes these frames capture unimportant scenes from the video, or taken out of context give wrong impression of the video. Such accidental misleading poster frames are a problem for me (sighted user), and I don't think we should be giving *equally bad* experience to users who can't see them.

Some video poster frames, e.g. on InfoQ website, are just website's logo, which tells nothing about the video itself, and website name is obvious from context.

On Guardian and NY Times websites videos seem to have manually chosen poster frames. However, these videos are accompanied by very good descriptions, which are much better than descriptions of poster frames could be (e.g. video about climate change affecting sea life has poster frame with a fisherwoman — even a pefect description of the poster frame would be only an incomplete description of the video).

Videos on movie-oriented websites don't use movie poster for poster frame. Trailers often start with screen describing video rating, and less often logo of a movie studio. This is valuable information, but description of the first frame would only coincidentally contain it (and e.g. if video has rating screen, then users would not get information about movie studio and vice-versa). Instead of relying on poster frame containing *some* information and poster frame description copying it, we should encourage authors to provide information in more reliable and straightforward manner (e.g. Apple trailers website always includes both rating and studio information in movie description, and poster frames are not reliable source of that information).
Philip Jägenstedt I strongly object to describing the poster frame separately from the video to AT users. This distinction is not made for sighted users, who have no way of knowing if what they are seeing is the first frame of a video or a poster frame. The poster frame is "intended to be a representative frame of the video" and as such, the description of the video should also be a suitable description of the poster frame. If the poster frames brings attention to any specific aspect of the video, it would be appropriate for the video's description to also stress that aspect. Making the suggested disctinction would encourage inappropriate use of the poster frame.

I strongly object to removing the poster attribute, as it is already implemented by browsers and used by web pages. Adding a short text alternative for the placeholder/poster image (which I object to) does not require changing this part of the syntax.

As a necessary consequence, I also object to renaming the concept from "poster frame" to "first frame", even though I acknowledge that "poster frame" is by no means a perfect name for the feature.

I object to introducing a <firstframe> void element that is likely to appear before the <source> elements. In all browsers that do not implemented support for <firstframe>, any following <source> elements would become child elements of <firstframe> and thus would not be considered in the resource selection algorithm. In effect, that video would be completely broken in those browsers. (Yes, this is also a problem with <track> and introducing new void elements in general.)

The fact that authors can use any image as the poster frame is not sufficient justification. Any frame of the video can also contain arbitrary content, yet there is no mechanism for providing short text alternatives for specific frames on the HTML level. Further, it seems highly unlikely that people who use the poster incorrectly (to include content that is not representative of the video resource itself) would be aware enough to make the effort of making that inappropriate use accessible.

Finally, just like the poster attribute can be used incorrectly, it's possible to use multiple <source> elements with media attributes so that wildly different videos are used depending on the environment. Yet, there is no suggestion to provide a separate text alternatives for each <source>. I object to catering for abuse of the poster attribute but not doing the same for <source> elements.

Comments on Leif Halvard Silli's objections not covered by the above:

There is no disagreement that short text alternatives for the video are important.

There is no contradiction between "conceptually part of the media resource itself" and "should be described as part of the description of the video element itself". The point is quite clear: a short text alternative that is representative of the video would also be suitable as a short text alternative for the poster frame, as the poster frame is representative of the video. No one has suggested that the poster frame be explicitly described in the short text alternative of the video, on the form of "The poster frame contains... and the video itself is about...". That would just as inappropriate as having a separate description for the poster frame.

That <video> does not have a (dedicated) short text alternative is part of the point. Having a dedicated short text alternative for the poster frame but not for the video itself is extremeley backwards. Thus the suggestion that discussion "move on to short and long text alternatives for a media resource as a whole". Note that aria-labelledby and aria-describedby are mentioned as potential solutions in the <firstframe> proposal. This is outside the scope of ISSUE-142, though.
Leif Halvard Silli

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