W3C WBS Home

Results of Questionnaire ISSUE-204: How to exempt ARIA attributes from the rule that prohibits reference to hidden elements? - Straw Poll for Objections

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: pcotton@microsoft.com, rubys@intertwingly.net, mjs@apple.com, mike@w3.org

This questionnaire was open from 2012-07-26 to 2012-08-03.

5 answers have been received.

Jump to results for question:

  1. Objections to permitting @aria-describedby to point at elements hidden by @hidden.
  2. Objections to change the @hidden section to permit ARIA attributes to reference hidden elements.

1. Objections to permitting @aria-describedby to point at elements hidden by @hidden.

We have a Change Proposal that proposes to allow the ARIA @aria-describedby attribute to point at elements hidden by the @hidden attribute. This proposal says authors 'SHOULD NOT reference hidden content which would lose essential meaning when flattened'. It also differs in wording from the other proposal. See the proposals for details. 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 permitting @aria-describedby to point at elements hidden by @hidden.
Simon Myers
Richard Schwerdtfeger I object to this statement:

"Because authors sometimes need to provide a complex description of a page element for users of Assistive Technology without any forced visual encumbrance or default visual indicator, HTML should allow this to be done in the most straightforward manner, by enabling aria-describedby="" to point at elements hidden with the hidden="" attribute. "

Rationale: Although the intent of this proposal is to allow for the common use case for hidden descriptions in ARIA, the use of the word should or the attempt to dictate the authoring practices of another specification leads to a number of very serious issues:

1. The use of the word should vs. must leaves impression of doubt on whether authors should use use aria-describedby to reference hidden content. The ARIA specification does Implementation in Host Languages (http://www.w3.org/WAI/PF/aria/host_languages). Nowhere in here does it state that other specifications can redefine how authors should use ARIA.

2. This provides yet another place where the WAI-ARIA specification team needs to keep track of authoring guidance. We have both an authoring practices guide as well as a user agent implementation guide. The HTML specification must not be dictating the implementation of another spec. by authors or user agents unless agreed upon by members of that working group for this reason.

3. WAI-ARIA is a cross cutting technology. Any restrictions should be addressed in WAI-ARIA so that they may be applied to other host languages.

I object to this text:

"When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user."

For this reasons:

The use of hidden content is indeed directly relevant to the page. The use of aria-describedby to reference hidden content is a very commonly used implementation of ARIA where additional help information is provided to assistive technology vendors without visually impacting the UI. There is extensive implementation of using aria-describedby, by authors and browsers, to reference hidden content in forms to provide help information. Often, hidden information is provided to screen reader users to provide additional keyboard shortcut information that a sighted user may not desire to use as they operate a pointing device. This additional keyboard information may be provided in a Web application's documentation as well, but for a blind user they need help immediately for these short cuts as a productivity measure, yet exposing this information to a sighted user could clutter up the user interface and make it difficult to use.

Furthermore, assistive technologies have the option of not speaking the help information all the time as the user becomes familiar with the application.

The use case for using hidden content to describe HTML elements was first introduced by Freedom Scientific. Customers wanted JAWS to speak additional help information in forms defined by the author and special non-standard attributes were defined to do this in the past. We have incorporated this functionality in WAI-ARIA for this reason.


2. I object to the wording of this statement:

"While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe."

aria-describedby is a global attribute and can be used to describe or provide additional information on ANY HTML element. It is not confined to describing images. This highlights yet another problem with another specification defining how another specification should be used.

This statement is in direct violation of what is intended by the ARIA specification. Furthermore, the ARIA implementation guide clearly states how hidden content is to be mapped to platform accessibility APIs in the cases where content is hidden. In these cases it is mapped to the accessible description (a string of text extracted from the hidden web content).

This guidance is wrong and it gives the impression that authors not following this guidance are doing something wrong - which they are NOT.

As chair of the WAI-ARIA standards effort in PF this guidance also has a direct negative impact on the WAI-ARIA specification to which HTML does not control.

3. I object to this statement:

User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby="".

This creates an undue burden on assistive technologies. Assistive technologies, such as screen readers would need to provide navigation of hidden content to make this worth while. This would mean that the AT would have to produce something similar to an accessibility tree or DOM that the browser already does and then walk it. That is a huge burden and we don't want to have ATs start to become browsers. Unless the user agent is going to provide a vehicle to render the hidden content referenced by aria-describedby in the future then the HTML5 specification should not make this statement. We should not be requiring ATs to reproduce the functionality of the browser which includes parsing content into their own DOM. This was done in the past in the early versions of IBM's Home Pager Reader and the fact is that the web is constantly evolving and this model cannot be sustained.

Given the impact on the WAI-ARIA specification and the extensive negative impact on IBM products I will push for a formal objection by IBM of the HTML 5 specification if this change proposal goes through.
Benjamin Hawkes-Lewis + Objection

I object to the proposed text -

“User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby="". However, because historically some User Agents have flattened hidden content when exposing such content to Assistive Technology, authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.”

- because it contradicts WAI-ARIA 1.0’s normative requirements for calculating the accessible description for a node in the accessibility hierarchy. These require user agents to expose content referenced by @aria-describedby as *plain text* (i.e. flattened). The text above presents such flattening as an historical implementation detail, rather than a specified requirement.

http://www.w3.org/WAI.new/PF/aria/roles#descriptioncalculation
John Foliot I object to this change proposal, and in particular this section:

"User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby=""."

This can result in harmful behaviors, particularly with regard to tab focus requirements. WCAG 2 mandates that all tab-focus-able elements be visually noted when focus is place on that element. Allowing tab focus (due to full rich semantic exposure) will result in sighted users tabbing to tab-focus-able elements that are out of visual range. (2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA) http://www.w3.org/TR/WCAG/#navigation-mechanisms

Further, for certain structural elements such as tables, the flattening effect that hidden content experiences, renders those tables as completely unusable to non-sighted users, as the inherent X,Y comprehension model of tables will be lost.

I have posted an example page that illustrates these problems at http://john.foliot.ca/html5/w3c/hidden.html
Janina Sajka Additional Comment to John Foliot's Test Page:
The lost focus behavior is particular relevant not to screen reader users, but to sighted users
who read the video display, but whose disabilities prevent them from using a mouse (or other pointing device)--people who use keyboard navigation, e.g. TAB/Shift+TAB to navigate.

2. Objections to change the @hidden section to permit ARIA attributes to reference hidden elements.

We have a Change Proposal that proposes to allow the ARIA @aria-describedby attribute to point at elements hidden by the @hidden attribute. This proposal says authors 'SHOULD avoid using hidden elements for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.)'. It also differs in wording from the other proposal. See the proposals for details. 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 change the @hidden section to permit ARIA attributes to reference hidden elements.
Simon Myers I object to adopting this change proposal because of the ‘SHOULD avoid’ clause quoted above: the explanation for it given in the change proposal is because some user agents currently flatten the text, suggesting that this is always unacceptable.

This would be an unnecessary restriction on authors, since it is based purely on a hidden element containing certain other elements, rather than taking the effect of those elements into account. In contrast with the other change proposal (which proposes a restriction on losing essential meaning), this change proposal would restrict certain mark-up even if it loses no meaning at all when flattened, and so causes no disadvantage to anybody at all, even in current user agents.

For example, consider this mark-up — which contains a list, so would be restricted by this change proposal:

<p>My salad yesterday included these ingredients:
<ul>
<li>sausage,
<li>bacon,
<li>black pudding,
<li>tomato,
<li>lettuce,
<li>dressing.
</ul>

When flattened, the text of that mark-up becomes:

My salad yesterday included these ingredients: sausage, bacon, black pudding, tomato, lettuce, dressing.

Flattening the text has not caused any essential meaning (in fact, any meaning at all) to be lost, so nobody is disadvantaged by their software giving them the flattened version. As such, there's no advantage to anybody in an author avoiding using such mark-up, even in a hidden element where it risks being flattened.

The risk of flattened text putting certain users at a disadvantage is adequately covered by the other change proposal, which restricts mark-up which would cause essential meaning to be lost (and only that).

I further object to this change proposal because the restriction it proposes is phrased as “SHOULD avoid”. This is a confusing way of expressing it, since it doesn't use the RFC2119 language used for other restrictions in ‘HTML5’. In particular, it isn't clear whether “should avoid” carries the same meaning as “should not”, or there is some nuance of difference, and such lack of clarity makes interpreting the spec harder for authors and implementers.

And I further object to the definition of structured text being given by example, thereby leaving room for differences of opinion on whether a particular element is structured or not. ‘HTML5’ currently defines terms it uses precisely, explicitly listing members of sets and which elements count as which type of content. If a restriction on elements within hidden elements were to be added to ‘HTML5’ then for it to be unambiguously and interoperably implemented (for example, in validators) then it should be defined with the same rigor.

Finally, I object to the list of example elements using both “eg” and “etc”, since this is nonsensical. If ‘HTML5’ is to place a restriction on certain elements being used in hidden elements, and that restriction is to be defined by example, then the example should make sense. Using either “eg” at the start of a list of actual elements, or a list of actual elements followed by “etc” conveys the meaning that the elements listed are only a subset of those the term applies to. Using “eg” and “etc” together is making the claim that “etc” is an example of structured text, which it isn't. Having nonsense in the spec is an impediment to it being followed by both authors and implementers.
Richard Schwerdtfeger I object to this normative statement residing in the HTML specification. This belongs in the WAI-ARIA specification and it would be a very good issue to address in ARIA 1.1:

"Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements. For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate. "

This is a normative statement in the HTML5 specification for WAI-ARIA. The WAI-ARIA specification should impose this restriction and not the HTML5 specification. WAI-ARIA is a cross-cutting technology and these restrictions should apply anywhere that WAI-ARIA is used, like SVG. I would rather this be opened as an issue for ARIA 1.1 which is designed to address gaps related to HTML5 and they will be picked up in the accessibility work on SVG.
Benjamin Hawkes-Lewis + Objection 1

I object to the proposed text -

“User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby="". However, because historically some User Agents have flattened hidden content when exposing such content to Assistive Technology, authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.”

- because it contradicts WAI-ARIA 1.0’s normative requirements for calculating the accessible description for a node in the accessibility hierarchy. These require user agents to expose content referenced by @aria-describedby as *plain text* (i.e. flattened). The text above presents such flattening as an historical implementation detail, rather than a specified requirement.

http://www.w3.org/WAI.new/PF/aria/roles#descriptioncalculation

+ Objection 2

I object to the text -

“When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive”

- because shifting to a language of relevance to one of visibility incorrectly implies @hidden is presentational and specific to the visual medium. Traditionally, presentational features like "display: none" have been abused to hide irrelevant DOM subtrees from most users. Defining @hidden in terms of relevance gives HTML an unambiguous semantic enabling clear communication from authors to user agents about what parts of the DOM tree are relevant for rendering and interaction.

The rubric "content to be reused by other parts", from first Change Proposal, should be sufficient to overcome concerns that the language of irrelevance implies @hidden descriptions somehow aren't important to assistive technology users.

+ Objection 3

I object to the proposed text -

"Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate."

- since this contradicts the spec elsewhere, which fully defines the result (navigation occurs, but the user agent does not bring the hidden area to the user's attention, for example by scrolling it into view). For a detailed walk-through of the spec on this point, please see:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0166.html
John Foliot
Janina Sajka Objection: It is inappropriate to base any HTML 5 behavior on the current
ARIA specifications because the current ARIA specifications are normative for HTML 4 only. Work has not yet
begun on ARIA for HTML 5, except as has been negotiated with the PF-WG expressly for use in HTML 5 specifications. If the HTML-WG wishes to negotiate additional ARIA behavior for its HTML 5 specifications, it should propose the particulars to the PF-WG.

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. Judy Brewer <jbrewer@w3.org>
  4. Wayne Carr <wayne.carr@linux.intel.com>
  5. Jason White <jason@jasonjgw.net>
  6. Richard Ishida <ishida@w3.org>
  7. Chris Wilson <cwilso@google.com>
  8. Wendy Chisholm <wendc@microsoft.com>
  9. David Carlisle <davidc@nag.co.uk>
  10. James Helman <jhelman@movielabs.com>
  11. Jim Allan <jimallan@tsbvi.edu>
  12. Chris Marrin <cmarrin@apple.com>
  13. Charles McCathie Nevile <chaals@yandex-team.ru>
  14. Philippe Le Hégaret <plh@w3.org>
  15. Arthur Barstow <art.barstow@nokia.com>
  16. T.V. Raman <raman@google.com>
  17. David Singer <singer@apple.com>
  18. Cynthia Shelly <cyns@microsoft.com>
  19. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  20. Sean Hayes <sean.hayes@microsoft.com>
  21. Karl Dubost <karl@la-grange.net>
  22. Larry Masinter <masinter@adobe.com>
  23. Ian Hickson <ian@hixie.ch>
  24. David Baron <dbaron@dbaron.org>
  25. Lisa Seeman <lisa.seeman@zoho.com>
  26. Paul Cotton <Paul.Cotton@microsoft.com>
  27. wu chou <wu.chou@huawei.com>
  28. Katsuhiko Momoi <momoi@google.com>
  29. Kangchan Lee <chan@w3.org>
  30. Roy Fielding <fielding@gbiv.com>
  31. Silvia Pfeiffer <silviapfeiffer1@gmail.com>
  32. Johnny Stenback <jst@mozilla.com>
  33. Deborah Dahl <dahl@conversational-technologies.com>
  34. Frederick Hirsch <frederick.hirsch@nokia.com>
  35. Michael Cooper <cooper@w3.org>
  36. Glenn Adams <glenn@skynav.com>
  37. Jonathan Jeon <hollobit@etri.re.kr>
  38. David Hyatt <hyatt@apple.com>
  39. Robin Berjon <robin@w3.org>
  40. WonSuk Lee <wonsuk11.lee@samsung.com>
  41. Maciej Stachowiak <mjs@apple.com>
  42. Robert Accettura <robert@accettura.com>
  43. Serge K. Keller <skeller@mammouth.ch>
  44. Jonathan Watt <jwatt@jwatt.org>
  45. Steve Faulkner <faulkner.steve@gmail.com>
  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. Catherine Roy <ecrire@catherine-roy.net>
  59. Jens Meiert <jens@meiert.com>
  60. Felix Sasaki <fsasaki@w3.org>
  61. Kazuyuki Ashimura <ashimura@w3.org>
  62. Daniel Burnett <dburnett@voxeo.com>
  63. Tomas Caspers <tomas@tomascaspers.de>
  64. Han Xu <collin@w3china.org>
  65. Sam Ruby <rubys@intertwingly.net>
  66. Jonas Sicking <jonas@sicking.cc>
  67. Mark Crawford <mark.crawford@sap.com>
  68. Doug Schepers <schepers@w3.org>
  69. Ian Fette <ifette@google.com>
  70. Michael[tm] Smith <mike@w3.org>
  71. Julian Reschke <julian.reschke@gmx.de>
  72. Kelly Ford <kelly.ford@microsoft.com>
  73. Cameron McCormack <cam@mcc.id.au>
  74. Jirka Kosek <jirka@kosek.cz>
  75. Robert O'Callahan <robert@ocallahan.org>
  76. Travis Leithead <Travis.Leithead@microsoft.com>
  77. Youngsun Ryu <ysryu@samsung.com>
  78. Sierk Bornemann <sierkb@gmail.com>
  79. Martijn Wargers <martijn.martijn@gmail.com>
  80. Simon Pieters <simonp@opera.com>
  81. James Graham <james@hoppipolla.co.uk>
  82. Henri Sivonen <hsivonen@hsivonen.fi>
  83. Lachlan Hunt <lachlan.hunt@lachy.id.au>
  84. Krijn Hoetmer <w3c@qontent.nl>
  85. Dean Edridge <dean@dean.gen.nz>
  86. Channy Yun <channy@gmail.com>
  87. Shane Thacker <shanethacker@gmail.com>
  88. Bill Mason <billm@accessibleinter.net>
  89. Vilem Malek <murphy@malek.cz>
  90. Zhihong Mao <zhihong.mao@gmail.com>
  91. Benoit Piette <benoit.piette@gmail.com>
  92. Erik van Kempen <erikvankempen@gmail.com>
  93. Jude Robinson <dotcode+w3@gmail.com>
  94. Dimitri Glazkov <dglazkov@chromium.org>
  95. Diego La Monica <d.lamonica@webprofession.com>
  96. Nick Fitzsimons <w3@nickfitz.co.uk>
  97. Josh Lawton <w3c@joshlawton.com>
  98. Giovanni Gentili <giovanni.gentili@gmail.com>
  99. Adele Peterson <adele@apple.com>
  100. Mateo Yadarola <teodalton@gmail.com>
  101. S Emerson <w3c@accretewebsolutions.ca>
  102. Andrew Fedoniouk <a.fedoniouk@gmail.com>
  103. Morten Tollefsen <morten@medialt.no>
  104. Daniel Schattenkirchner <schattenkirchner.daniel@gmx.de>
  105. Edward O'Connor <eoconnor@apple.com>
  106. Justin Anthony Knapp <justinkoavf@gmail.com>
  107. Samuel Weinig <weinig@apple.com>
  108. Alexey Proskuryakov <ap@webkit.org>
  109. Alejandro Fernandez <alejandro@mediadvanced.com>
  110. Doug Jones <doug_b_jones@me.com>
  111. Marc Drumm <mdrumm@wcupa.edu>
  112. Danny Liang <danny.glue@gmail.com>
  113. Arne Johannessen <arne@thaw.de>
  114. Michael Puls II <shadow2531@gmail.com>
  115. Clair Dunn <cadunn@vt2000.com>
  116. Ron Reisor <ron@udel.edu>
  117. Marat Tanalin <mtanalin@yandex.ru>
  118. Andrew Norman <idonothaveacat@gmail.com>
  119. Craig Buckler <craigbuckler@gmail.com>
  120. Brian Peppler <bpeppler@gmail.com>
  121. Matthew Turvey <mcturvey@gmail.com>
  122. Dale Hudjik <dale.hudjik@gmail.com>
  123. James Cassell <w3c@cyberpear.com>
  124. Joseph D'Andrea <jdandrea@gmail.com>
  125. Pietro Russo <p.russo@webprofession.com>
  126. Moto Ishizawa <summerwind.jp+w3c@gmail.com>
  127. Chris Adams <chris@tuesdaybegins.com>
  128. Eric Carlson <eric.carlson@apple.com>
  129. Michael Turnwall <w3c@turnwall.net>
  130. Don Kiely <donkiely@computer.org>
  131. Robert Marshall <rdm@rdmsoft.com>
  132. Jane Lee <applegoddess@gmail.com>
  133. David Child <dave@addedbytes.com>
  134. Mark DuBois <Mark@webprofessionals.org>
  135. David Choi <daaave@gmail.com>
  136. Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
  137. David Bills <w3@dfbills.com>
  138. Nik Thierry <me@thisemail.ca>
  139. Andrew Ramsden <andrew@irama.org>
  140. Shefik Macauley <allknightaccess@gmail.com>
  141. Joe Steele <steele@adobe.com>
  142. John Vernaleo <john@netpurgatory.com>
  143. Jeremy Keith <jeremy@adactio.com>
  144. Jedi Lin <JediLin@Gmail.com>
  145. Manu Sporny <msporny@digitalbazaar.com>
  146. Kenny Johar <kensingh@microsoft.com>
  147. Jon Hughes <jon@phazm.com>
  148. Anssi Kostiainen <anssi.kostiainen@intel.com>
  149. Samuel Santos <samaxes@gmail.com>
  150. Dean Jackson <dino@apple.com>
  151. Mohammed DADAS <mohammed.dadas@orange.com>
  152. Sally Cain <sally.cain@rnib.org.uk>
  153. Dan Romascanu <dromasca@avaya.com>
  154. David Bolter <dbolter@mozilla.com>
  155. Chris Double <cdouble@mozilla.com>
  156. Jeanne F Spellman <jeanne@w3.org>
  157. James Craig <jcraig@apple.com>
  158. MING JIN <ming.jin.web@gmail.com>
  159. Leonard Rosenthol <lrosenth@adobe.com>
  160. Philip Jägenstedt <philipj@opera.com>
  161. Adrian Bateman <adrianba@microsoft.com>
  162. Dionysios Synodinos <synodinos@gmail.com>
  163. Jean-Pierre EVAIN <evain@ebu.ch>
  164. Mark Pilgrim <pilgrim@google.com>
  165. Matt Lee <mattl@cnuk.org>
  166. Magnus Olsson <magnus.olsson@ericsson.com>
  167. Carlos Cecconi <cecconi@nic.br>
  168. Chris Pearce <cpearce@mozilla.com>
  169. Dzung Tran <dzung.d.tran@intel.com>
  170. Mark Miller <erights@google.com>
  171. Andrew Wilson <atwilson@google.com>
  172. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  173. Ojan Vafai <ojan@chromium.org>
  174. Martin McEvoy <martin@weborganics.co.uk>
  175. Aryeh Gregor <ayg@aryeh.name>
  176. Gavin Carothers <gavin@carothers.name>
  177. Eliot Graff <eliotgra@microsoft.com>
  178. Frank Olivier <frank.olivier@microsoft.com>
  179. D.R.Imanuel Abromeit <dabromeit@gmx.de>
  180. Sergey Lizin <sergey.lizin@gmail.com>
  181. Jonathan Griffin <jgriffin@mozilla.com>
  182. Kris Krueger <krisk@microsoft.com>
  183. Erik Isaksen <erik_isaksen@hotmail.com>
  184. Anders Bondehagen <anders@bondehagen.com>
  185. Steven Pemberton <Steven.Pemberton@cwi.nl>
  186. Raul Hudea <rhudea@adobe.com>
  187. Raghavan Gurumurthy <raghavan@adobe.com>
  188. Mayank Kumar <mayankk@adobe.com>
  189. Monikandan S <smonikan@adobe.com>
  190. Dragos Georgita <dgeorgit@adobe.com>
  191. Christopher Bank <cbank@adobe.com>
  192. Dominik Tomaszuk <ddooss@wp.pl>
  193. Ole Riesenberg <or@oleriesenberg.com>
  194. Takuya Oikawa <takuya@google.com>
  195. Jatinder Mann <jmann@microsoft.com>
  196. Robert Stern <rstern@gmail.com>
  197. Dean Leigh <dean.leigh@deanleigh.co.uk>
  198. Eihab Ibrahim <eihabibrahim@gmail.com>
  199. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  200. Ian Pouncey <w3c@ipouncey.co.uk>
  201. Jer Noble <jer.noble@apple.com>
  202. Léonie Watson <lwatson@paciellogroup.com>
  203. Masatomo Kobayashi <mstm@jp.ibm.com>
  204. Peter Beverloo <beverloo@google.com>
  205. Andrew Scherkus <scherkus@google.com>
  206. Greg Johnson <greg.johnson@gmail.com>
  207. Martijn Croonen <martijn@martijnc.be>
  208. John Jansen <johnjan@microsoft.com>
  209. Andreas Kuckartz <A.Kuckartz@ping.de>
  210. Stanley Manoski <manoski@mitre.org>
  211. Jonas Schneider <js.sokrates@gmail.com>
  212. Yosuke Funahashi <yosuke@funahashi.cc>
  213. Giuseppe Pascale <giuseppep@opera.com>
  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@danielaustin.org>
  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. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  303. Ami Fischman <fischman@google.com>
  304. Arnaud Braud <arnaud.braud@orange.com>
  305. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  306. Bram Tullemans <tullemans@ebu.ch>
  307. Petr Peterka <ppeterka@verimatrix.com>
  308. lei wang <wanglei03@baidu.com>
  309. Giles Godart-Brown <giles.godart-brown@bskyb.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. shangyi chen <chenshangyi@baidu.com>
  343. David Newton <david@davidnewton.ca>
  344. Mark Sadecki <mark@w3.org>
  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. Felipe Nascimento Moura <felipenmoura@gmail.com>
  369. David Evans <david.evans@rd.bbc.co.uk>
  370. Danny O'Brien <danny@eff.org>
  371. Joseph Karr O'Connor <josephoconnor@mac.com>
  372. Vanessa Me Tonini <vanessa@nic.br>
  373. Seth Schoen <schoen@eff.org>
  374. Jamil Ellis <jamil.ellis@hbo.com>
  375. Reinier Kaper <rp.kaper@gmail.com>
  376. Jim Walsh <jim@jwalshcreative.com>
  377. Jasper Valero <contact@jaspervalero.com>
  378. Greg Davis <greg.davis@pearson.com>
  379. Julio Cesar Serrano <mhysterio@gmail.com>
  380. Gabino Alonso <gabinovincent@gmail.com>
  381. Sam Langdon <sam.langdon@hachette.co.uk>
  382. Michael Kelly <mkelly@mozilla.com>
  383. Xiaoqian Wu <xiaoqian@w3.org>
  384. Yue Min <minyue@baidu.com>
  385. Min Li <limin04@baidu.com>
  386. Mark Boyle <boyle.mr@gmail.com>
  387. Sunghoon Moon <sunghoon@w3labs.kr>
  388. A.S. Krishnakumar <ask@avaya.com>
  389. Shijun Sun <shijuns@microsoft.com>
  390. Jonathan Neal <jonathantneal@gmail.com>
  391. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  392. diyar naozary <diyar.naozary@yahoo.com>
  393. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  394. Tetsushi Matsuda <Matsuda.Tetsushi@dh.MitsubishiElectric.co.jp>
  395. So Vang <svang@nab.org>
  396. Flavio Yanai <yanai@nic.br>
  397. Amy Brown <hello@amybrowndesign.com>
  398. Nathalia Sautchuk Patrício <nathalia@cgi.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. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>

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)