W3C WBS Home

Results of Questionnaire ISSUE-32: how to provide a summary of a table, e.g. for unsighted navigation? - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-20 to 2011-03-28.

15 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to reserve the summary attribute for summarizing the purpose of the table and any trends that might be obvious from viewing the table visually
  2. Objections to the Change Proposal to Make the table summary attribute fully conforming in HTML5
  3. Objections to the Change Proposal to Drop the summary="" attribute
  4. Objections to the Change Proposal to change summary from an Attribute to an Element

1. Objections to the Change Proposal to reserve the summary attribute for summarizing the purpose of the table and any trends that might be obvious from viewing the table visually

We have a Change Proposal to reserve the summary attribute for summarizing the purpose of the table and any trends that might be obvious from viewing the table visually. 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 to reserve the summary attribute for summarizing the purpose of the table and any trends that might be obvious from viewing the table visually
Ben Boyle I object to this useful information being hidden in an attribute. It should be in the content (for example, within the caption) and rendered (spoken and visible) by default.

I object to the use of "obvious from viewing the table visually"—we all face different challenges when understanding information, whether it be text, graphical, aural or tabular. We should make features like "summary" universally accessible. Many people who can "see" the table may have difficulty comprehending the trends and would be assisted by the summary.
aurélien levy
Gregory Rosmaita i support the concept, but with summary not as an attribute, but as an element, as explained in the following change proposal which was not included in this survey:

http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element
Tab Atkins Jr. I object to this Change Proposal.

Tables essentially fall into two categories:
1. Tables with a regular structure that can be inferred by machines
2. Tables with a complex or non-obvious structure.

In the first case, you don't need a summary. Sighted users can digest the table adequately by themselves, and ATs can generate reliable automated descriptions of the tables for their users. Anecdotally, I have seen many real-world examples of simple tables with @summary attributes which are inferior to a what I expect a simple, naive auto-generated summary would be for the same table.

In the second case, you don't want a hidden summary. If the structure is complex or non-obvious enough to prevent a machine from auto-generating a sufficient summary, then it is almost certainly complex or non-obvious enough that sighted users may be confused by the table layout as well. As such, the author should either provide a table description visible to everyone or rewrite the table into a more regular form.

Thus, in neither case do you need a summary available only to ATs or non-sighted users.
Cynthia Shelly
Leif Halvard Silli
Laura Carlson This is NOT an objection but a point to ensure that it is recognized that this proposal to reinstate table summary as conforming and not +obsolete was recommended by the HTML-A11Y Task Force.
http://lists.w3.org/Archives/Public/public-html-a11y/2010May/0088.html

Another thing I would like to mention is that @summary as "hidden meta-data" is a fallacy. As Gregory Rosmaita has often stated, the term "hidden meta-data" [1] is pejorative, and not an accurate description of attributes such as @summary. Rather the term should be "discoverable meta-data", which means it doesn't matter if it is displayed visually or not, but in a way the user can access it in accordance with that user's individual preferences. User Agents and authoring tools can and should offer a means to toggle visibility according to user preference [2]. One example of a table summary toggle is Table Inspector. [3]

Germane to the "hidden meta-data" fallacy is the fact that the Web is not a visual medium. It never has been. It's an electronic communication medium, both audio and visual, both print and screen etc. Even though the majority of users have vision and use visual means to access content doesn't make the web a visual medium. It is multi-modal. Perhaps some web developers concentrate on a particular media type more than another. And perhaps on many web sites, sighted, dexterous, able-bodied users outnumber users with a disability. But the strengths of the web, which makes it unique as a medium of communication, is that it isn't limited to a single output. That is the beauty.

[1] http://lists.w3.org/Archives/Public/public-html/2010Jan/0583.html
[2]http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222#Providing_an_Option_to_Reveal_Summary_Content_Via_User_Agent
[3] http://juicystudio.com/article/firefox-table-inspector.php
Denis Boudreau I object to the information presented in summary to be hidden by default in the attribute's value as some sighted users might benefit from it as well. I'm also in favor of turning summary into an element and have it rendered visible by default as per the "Change summary from an Attribute to an Element" Change proposal:
http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element
Joshue O Connor I am NOT objecting to this proposal, (as per our recommendation by the HTML-A11Y Task Force. http://lists.w3.org/Archives/Public/public-html-a11y/2010May/0088.html) but the following are comments relating to others stated objections here.

@Tab Atkins Jr.
>Sighted users can digest the table adequately by themselves

because they can see.

>ATs can generate reliable automated descriptions of the tables for >their users.

No they cannot. At least none of the AT I have used in the past 9 years.

@Ian Hickson

>summary="" has been amply demonstrated (one might even say _proved_) >to not help improve accessibility in concrete ways.

No it hasn't.

@lauracarlson Yes, the argument about hidden meta data is a fallacy. @summary could be easily displayed in a user agent as/if needed.



Martin Kliehm I do NOT object to this proposal, but I would to counter-argue that @summary is necessarily "hidden" meta-data. Browser vendors are free to provide the information of the summary attribute in a way that benefits other users than those with AT. Another argument has been that the summary text is often outdated and inaccurate: I strongly believe this is an issue of authoring tools making the information editable, therefore it is not a question that should be addressed in HTML, but in the W3C WAI ATAG.
Eric Eggert
Ian Hickson summary="" has been amply demonstrated (one might even say _proved_) to not help improve accessibility in concrete ways. As such, it is just acting as an opportunity cost, encouraging authors from spending time on something other than improving accessibility *even after we are lucky enough to have found an author who cares about accessibility*. This is a net harm to the accessibility of the Web.
Doug Jones
Stephen Axthelm
Jonas Sicking I object to this proposal since it encourages a redundant feature. We already have aria-describedby which not only solves the same use cases, but does it in a better way.

People have argued that summaries are different from descriptions. This is certainly true, however no argument has been brought forward for why we have to keep them separate in HTML. I.e. there doesn't seem to be a reason why the description of a table could contain a summary of said table. Consider a user which uses AT to read a page. If the user comes upon a table which he/she has trouble understanding, but where the browser notifies the user that a description is available, I see no reason to believe that the user wouldn't ask to get the description read to him/her.

In other words, if you have trouble understanding a table, but you are notified that a description of the table is available, it seems hard to argue that the user wouldn't inspect said description. At the very least, the user seems just as likely to seek help from a description as from a summary.

Hence I argue that aria-describedby solves the same use cases.

Further, I argue that aria-describedby solves the use case better, for a number of reasons.

First of all, it very poorly solves the use case when the page author wants to make the summary available both to AT users as well as users that doesn't use AT. The author has to duplicate the summary both in the summary attribute, and in normal flow of the page.

While wanting to show the summary to non-AT users isn't always the case, it seems like something that is at least as common, if not more so, than the case when the summary should only be made available to AT users. Unfortunately we don't have data either way showing which is the more common scenario.

Also note that aria-describedby still allows the summary to only be made available to AT users by simply adding a style="display:none" attribute to element containing the summary.

Second, aria-describedby has the advantage that it's available not just on <table>, but on all elements. Thus it allows providing summaries on data shown in list form, or data shown in the form of a graph in a <img> or a <canvas>. Allowing the same attribute to work across all elements makes both implementation as well as usage easier. Implementors doesn't have to have specific code for different elements, and authors don't have to learn which attributes work on which elements.

Third, aria-describedby allows providing descriptions, including summaries, in structured form, rather than just plain text. So while aria-describedby lets you provide a summary that for example puts emphasis on certain words using the <em> element, or provides text in the form of paragraphs, using the <p> element, the summary attribute can do neither. People have argued that aria-describedby only exposes the textual contents of the element that aria-describedby points to, however this does not seem to be supported by the aria specification. There is no wording that I have been able to find which makes this a requirement. So it simply seems like a bug in implementation if they don't expose the full semantics of the elements that aria-describedby points to.

If I am wrong in my interpretation of aria, this weakens my third point here. However I note that there is no reason aria couldn't be changed to allow for structured content, something which is not true for the summary attribute. It also wouldn't affect the other points raised above.

Fourth, there seems to be much more momentum behind aria than behind the summary attribute. I have heard several times on the public-html list about how support is appearing in various JS libraries. I have not heard the same thing regarding summary. I think we would be much more successful in advocating aria-describedby and aria-describedby alone, than telling people "use aria-describedby, except if your are describing trends in a table which a AT user couldn't see, or if you have a long description of a image in <img>".

So I consider the summary attribute to be harmful not in that there is existing content out there which poorly uses the summary attribute, but because it complicates the accessibility story for HTML5. It's hard enough as it is to get authors to provide accessibility specific content (a far too small percentage of the web provides it), the more complex message we provide for how to make pages accessible, the less successful we will be in improving this situation.

2. Objections to the Change Proposal to Make the table summary attribute fully conforming in HTML5

We have a Change Proposal to Make the table summary attribute fully conforming in HTML5. 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 to Make the table summary attribute fully conforming in HTML5
Ben Boyle Same objection as above.
aurélien levy
Gregory Rosmaita why wasn't the following change proposal included in this survey:
http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element
Tab Atkins Jr. I object to this Change Proposal.

Tables essentially fall into two categories:
1. Tables with a regular structure that can be inferred by machines
2. Tables with a complex or non-obvious structure.

In the first case, you don't need a summary. Sighted users can digest the table adequately by themselves, and ATs can generate reliable automated descriptions of the tables for their users. Anecdotally, I have seen many real-world examples of simple tables with @summary attributes which are inferior to a what I expect a simple, naive auto-generated summary would be for the same table.

In the second case, you don't want a hidden summary. If the structure is complex or non-obvious enough to prevent a machine from auto-generating a sufficient summary, then it is almost certainly complex or non-obvious enough that sighted users may be confused by the table layout as well. As such, the author should either provide a table description visible to everyone or rewrite the table into a more regular form.

Thus, in neither case do you need a summary available only to ATs or non-sighted users.
Cynthia Shelly
Leif Halvard Silli
Laura Carlson
Denis Boudreau I support this CP.
Joshue O Connor @ianhickson
> the text in the proposed example would be beneficial for all users

Then the user agent can expose it to all users. Removing the @summary attribute will remove the ability to add descriptive text, and by the logic of your own statement nullify any use, for any user group.
Martin Kliehm
Eric Eggert
Ian Hickson The same argument applies, except that the change proposal itself proves to be a perfect demonstration of the point: the text in the proposed example would be beneficial for all users, not just those who need assistance with the table, and encouraging authors to put that text in the summary="" attribute thus causes an author who would have written that text to actively _hide_ it from most users.
Doug Jones This change proposal on the surface seems to be very similar to "Change Proposal for Table Summary and related accessibility features" (http://www.w3.org/WAI/PF/HTML/wiki/Summary_Change_Proposal_Nov_18%2C_2009). However, this change proposal, "Make the table summary attribute fully conforming in HTML5", is not as clear in its purpose. It states the summary attribute should relay the structure of a table. To me, that means information about the number of rows and columns and their headings. Yet the proposed text for the specification includes an example of summary text that describes the highlights of the table information, which is not about structure.

"<table summary="This table lists the 32 most significant
floods of the 20th Century grouped into 6 types of floods:
Regional, flash, ice-jam, storm-surge, dam-failure, and
mudflow. The majority of the floods (20) are listed as
Regional floods. There are between one and four floods
in each of the other 5 categories.">
<!-- Remainder of table -->"
Stephen Axthelm
Jonas Sicking I object to this proposal since it encourages a redundant feature. We already have aria-describedby which not only solves the same use cases, but does it in a better way.

People have argued that summaries are different from descriptions. This is certainly true, however no argument has been brought forward for why we have to keep them separate in HTML. I.e. there doesn't seem to be a reason why the description of a table could contain a summary of said table. Consider a user which uses AT to read a page. If the user comes upon a table which he/she has trouble understanding, but where the browser notifies the user that a description is available, I see no reason to believe that the user wouldn't ask to get the description read to him/her.

In other words, if you have trouble understanding a table, but you are notified that a description of the table is available, it seems hard to argue that the user wouldn't inspect said description. At the very least, the user seems just as likely to seek help from a description as from a summary.

Hence I argue that aria-describedby solves the same use cases.

Further, I argue that aria-describedby solves the use case better, for a number of reasons.

First of all, it very poorly solves the use case when the page author wants to make the summary available both to AT users as well as users that doesn't use AT. The author has to duplicate the summary both in the summary attribute, and in normal flow of the page.

While wanting to show the summary to non-AT users isn't always the case, it seems like something that is at least as common, if not more so, than the case when the summary should only be made available to AT users. Unfortunately we don't have data either way showing which is the more common scenario.

Also note that aria-describedby still allows the summary to only be made available to AT users by simply adding a style="display:none" attribute to element containing the summary.

Second, aria-describedby has the advantage that it's available not just on <table>, but on all elements. Thus it allows providing summaries on data shown in list form, or data shown in the form of a graph in a <img> or a <canvas>. Allowing the same attribute to work across all elements makes both implementation as well as usage easier. Implementors doesn't have to have specific code for different elements, and authors don't have to learn which attributes work on which elements.

Third, aria-describedby allows providing descriptions, including summaries, in structured form, rather than just plain text. So while aria-describedby lets you provide a summary that for example puts emphasis on certain words using the <em> element, or provides text in the form of paragraphs, using the <p> element, the summary attribute can do neither. People have argued that aria-describedby only exposes the textual contents of the element that aria-describedby points to, however this does not seem to be supported by the aria specification. There is no wording that I have been able to find which makes this a requirement. So it simply seems like a bug in implementation if they don't expose the full semantics of the elements that aria-describedby points to.

If I am wrong in my interpretation of aria, this weakens my third point here. However I note that there is no reason aria couldn't be changed to allow for structured content, something which is not true for the summary attribute. It also wouldn't affect the other points raised above.

Fourth, there seems to be much more momentum behind aria than behind the summary attribute. I have heard several times on the public-html list about how support is appearing in various JS libraries. I have not heard the same thing regarding summary. I think we would be much more successful in advocating aria-describedby and aria-describedby alone, than telling people "use aria-describedby, except if your are describing trends in a table which a AT user couldn't see, or if you have a long description of a image in <img>".

So I consider the summary attribute to be harmful not in that there is existing content out there which poorly uses the summary attribute, but because it complicates the accessibility story for HTML5. It's hard enough as it is to get authors to provide accessibility specific content (a far too small percentage of the web provides it), the more complex message we provide for how to make pages accessible, the less successful we will be in improving this situation.

3. Objections to the Change Proposal to Drop the summary="" attribute

We have a Change Proposal to drop the summary="" attribute. 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
Ben Boyle
aurélien levy
Gregory Rosmaita 1. summary is an essential tool for non-visual and limited visual access to data contained in TABLE;

2. summary as an attribute is insufficient because it does not support structured content, such as <span lang="xx"> for bi-lingual tables, as well as indicating to the user that the table uses structured markup and a guide to that structured markup

why wasn't the following change proposal included in this survey:
http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element
Tab Atkins Jr.
Cynthia Shelly In the absense of a better replacement, we need to keep the accessiblity features from HTML 4. We do not currently have a better replacement for @summary, and creating one is not the highest priority work item on the very aggressive schedule for HTML 5.
Leif Halvard Silli (1) This CP Is confusing in that it states about @summary that
]] the attribute isn't part of the language [[
And yet:
]] encourages user agents (such as screen readers) to expose the contents
of summary="" attributes, [snip] That should not be changed. [[

Another place the CP descripe @summary as
]] allowed (though discouraged) [[

What does "part of the language" mean? Are ARIA part of the HTML5 language? Is @summary a part of HTML4 that is tolerated in HTML5, but not part of the langauge?

Though the logics behind perhaps is found in the claim that @summary hides content that could be useful to sighted as well, this is an inconsistent way of "dropping" an attribute. It is in fact unclear whether it is or isn't part of the language.

There are many valid features for which is is useful to warn against certain uses of them..

(2)Regardign ]] Usability study. A blind user, using JAWS, [[
Firstly, this part of the CP seems like it could be relevant feedback to the JAWS producers
Secondly, the test person complains that he summary info is unneeded. There could be more than one reason why so. Do we for instance know that the user would not have complained if the same text had been inside the <caption> instead? Being inside @summary, the user can - in principle - switch it off, whereas there is no way to switch off content inside <caption> - since there is not special place to place such info there.

(3) Regarding the claim that @summary is ]] encouraging people to consider layout tables acceptable [[
The logic is here, it seeems, that authors believe that they can signal that the table is a layout table by inserting an empty @summary attribute.

However, this only points to a general problem with Validator.w3.org when it comes to HTML4 and XHTML1: there is a lot of things they do not check for - including that they do not check for invalid URLs inside URI attributes. In the case of @summary, the empty string as well as whitespace only, should simply be forbidden - that would pretty much solve the issue. It would also be possible to have checks which looks as whether the content of @summary seems meanignful, whether it simply repeats the <caption> etc.

Even if @summar becomes fully valid, it is possible to have very strict rules for it use, including strict validation rules - it just to file bugs ...

(4) The CP claims:
]] This would make sense if the summary content was rendered very
differently than other content in specific media, but in practice in
ATs the summary content is just read out like caption content, so it
wouldn't add much here, [[

This does not rhyme with the CP's intepretation of usability test with the about the peson who tested @summary together with JAWS user: Jaws *does* read it differently - it announces the summary. Allthoug this part of the CP spoke aginst the possible use of a <summary> element, the point should also be avlid for @summary: the @summary attribtue allows exactly this. Namely it allows the AT to render it very different from the caption.

ARIA is not an alternative, as e.g. an element pointed to via ARIA-describedby would not be read in a different tone etc.

]] and in other UAs the author would be able to
just style it using CSS. (Media queries can also be used to hide
content specifically from particular media, e.g. having text not
appear on screen.) [[

It is also possible to "just style" the @summary attribtute. CSS allows us to make it visible - either visible to all, or to some particular media. This page has not been updated for a while, but still mostly holds what it promises: http://malform.no/testing/html5/summary+css
By making the attribute visible, via CSS it is also possible to get @summary support in some screenreaders without @summary support.

(5) The CP claims:
]] it isn't visible to non-screen-reader users in
legacy user agents; and visual media browsers would not want to show
this content inline in legacy content because it would cause legacy
content to change rendering in a non-backwards-compatible manner. [[

The legacy argument is difficult. Many things are possible to achive via scripting and css if one is willing to. Besides, legacy UAs are always on the way out ...

(6) The CP claims:
]] There is, however, ample evidence that authors who are convinced (by
advocacy) that they fall into the above situation in fact fail to fall
into it, and end up creating harmful content (see above for
examples).[[

Stricter validation could help. See above. "Harmful content" is an exaggeration anyway.

]]There is also ample evidence that having the attribute
present encourages authors to include descriptions when they are not
necessary, wasting their time and the time of their AT-using readers.[[

It seems valid, to me, to be crticial about the things about @summary that doesn't work. But I am also sure that @alt is vasting the time of some. Any time a mark-up language has slots which are to be correclty filled int by authors, there is a chance that authors invent their own interpretation - or add bogus content as part of their struggle to get to grip with the language.

As told, there is legacy content with @summary out there. By defining @summary as not part of the languagge, the legacy content out there will be forgotten or perhaps removed - without anyting new coming instead. It is better to have stricter validation rules for @summary and thus encourage authorst to correct use.
Laura Carlson NO CURRENT REPLACEMENT

HTML5 does not provide a table summary mechanism which is not visible to the sighted by default and which allows summary of, anything that is visually obvious, but would aid and save someone time using a screen reader to determine the structure of a table, (remembering that AT can be quite helpful by summarizing the number of rows and columns automatically). Without a table summary, screen reader users may need to investigate a table cell by cell to build up a mental picture of how the data is organized; something that is visually evident. If summary is to be worked out of the system, it should not be abruptly. Transition it out with something BETTER in an orderly and graceful manner.

CONSIDERATION FOR AUTHORS

For the majority of sighted users a summary is not needed [1]. It is however, a tool for authors. Providing summary information visually by default can be extra verbiage that most authors/designers/marketing departments would be reluctant to include visually on a page because of redundancy. This is where @summary is useful. The summary attribute should not be outlawed by HTML5. Give authors the freedom to use it when THEY deem it necessary.

BACKWARDS COMPATIBILITY

Obsolescing summary breaks the web for numerous sites doing the right thing.

CONSIDERATION FOR EXISTING GUIDELINES, LAWS, POLICY, STANDARDS

HTML5 should not ignore existing laws and requirements. By obsolescing the existing tool, HTML5 could be seen as setting law, standards, policy for governments, companies and organizations.

80/20 RULE

No set number proves a feature should be included or excluded from the spec when we are talking about tables and people with disabilities. People With Disabilities are a minority. Tables that need summary are a minority. However, summary has been used in that minority [2].

THE SUBJECTIVE VALUE OF VALUES

This change proposal imposes the editor's personal and subjective evaluation of @summary values in several examples.

The researcher who provided those examples came to completely different findings. He stated, "In conclusion: @summary is well supported by AT, its misuse at whatever level (though I would say claims are overstated) has little effect upon users. Therefore I suggest that it would be useful to talk to the screen reader users (its intended audience) that are on the W3C HTML working group and the W3C WAI groups and heed their advice on the utility of the @summary." [3]

No users have said that the summary attribute is a harmful. HTML a11y task force (many are blind screen reader users) recommend a proposal to reinstate table summary as conforming and not +obsolete. Blind users who are not part of the WG such as Sailesh Panchang [4] have expressed @summary's usefulness.

ACCESSIBILITY AND UNIVERSAL DESIGN

This proposal is a skewed notion and misrepresentation of how Accessibility fits into Universal Design. It is a stealth type of discrimination.

Accessibility is a condition of Universal Design, as other conditions (media independence, language, infrastructure, geographical location, culture, etc.). When accessibility has been considered in its own right within universal access, people with disabilities won't be overlooked. If people with disabilities are overlooked in a design, then the design doesn't embody the principles of universality in the first place. The danger of ignoring the purpose of @summary and not supplying its functionality in HTML5 is the initial use case [5] is not provided for.

Access for people with disabilities is essential. This does not mean that features should be dropped if not all users can fully make use of them but rather that alternative/equivalent mechanisms must be provided where needed. People with disabilities face some unique challenges and barriers (and are only too often systemically excluded). To ensure that such exclusion does not occur in HTML5, it does need to contain some features that may be only of use to people with certain disabilities, when functional equivalents are not provided.

Example: The image in the img element is not perceivable by blind users. HTML5 has mechanisms for adding text alternatives. No one is arguing to make the alt attribute visible by default. The alt attribute's value for an image is not rendered with the image. Text alternatives are there for people who cannot perceive the image. The same principle applies to the summary attribute. They are both accommodations.

As for people with cognitive impairments, if a person with cognitive problems is also blind, then he or she would benefit from the summary attribute. If he or she is sighted, a visible summary attribute would add to the clutter on the page (information overload) and make it more confusing, as it would be explaining what is visually obvious and could be detrimental to someone with cognitive disabilities.

The reason for retaining the summary attribute as valid and conforming is to ensure a group people with disabilities, namely blind and low vision screen reader users, are afforded a table summary mechanism to provide a concise overview of the structure and are not shut out from what sighted users take for granted.

[1] http://www.w3.org/html/wg/wiki/SummaryForTABLE#Sighted_Users
[2] http://www.w3.org/html/wg/wiki/SummaryForTABLE#Sites_.22In_the_Wild.22_Which_Use_Summary
[3] http://lists.w3.org/Archives/Public/public-html/2009Feb/0420.html
[4] http://lists.w3.org/Archives/Public/public-html-comments/2010Aug/0000.html
[5] http://www.w3.org/html/wg/wiki/SummaryForTABLE#Use_Cases
Denis Boudreau I object to making the summary attribute obsolete as it can provide useful information to some users. I believe summary needs to be reinstated as conforming and not obsolete (but not necessarily as an attribute, as mentioned above).
Joshue O Connor I object to this change proposal, and support the retention of @summary as a full citizen in HTML 5, or at least retaining it as conforming but obsolete *when* we have something better to replace it with. Please note that we currently do not.

The case for the defendant may not watertight, and I admit the party making an affirmative defense bears the burden of proof. However, the prosecution has the burden of proving beyond a reasonable doubt that the defense is not applicable. To me, looking at both arguments (in full cognisance of my own bias), the prosecution has not proven beyond reasonable doubt that @summary is actively harmful to accessibility, therefore its retention is a sensible approach *until there is a better solution*. None of the argumentum ad baculum logic will convince me of anything different, as my experience working with people with disabilities proves to me (at least) that the retention of @summary is wise.

Martin Kliehm I object to this proposal. The editor claims that authors did not provide good summary text in the past. But this is not the question. The question is if @summary can benefit people with disabilities, and this is affirmative. If only one person's user experience becomes better through the summary attribute, for this person it can make the difference between inclusion or exclusion. Therefore @summary shouldn't be made obsolete or dropped.
Eric Eggert
Ian Hickson
Doug Jones This change proposal argues that all information should be presented to all user agents equally, visual or otherwise. Providing explanatory text for all to see may be visually annoying and informationally redundant.
The argument that the alt attribute for the img element provides fallback information to user agents that do not display the image is not the same as the use of the summary attribute with a table is flawed. The alt text is hidden from those who see the image; it is exposed only if the image is not .displayed. The same behavior is true of the proposed summary attribute (or element). A table is a hybrid - text and a visual display.
If the detail element is used for equivalent summary attribute text, it is not visible in a visual user agent by default. Why would it be exposed or read by default by an AT user agent?
Stephen Axthelm I object to this change proposal and support the current behavior of @summary being retained. In addition to the reasons laid out in Laura Carlson's well presented case, I would add that @summary allows conscientious authors a way to add to the accessibility of a table without impacting visual design or content. While I agree with the CP that in a perfect world, this information would be available to all users, we don't author in a perfect world and are often not the decision makers for visual design or visible content.
Jonas Sicking

4. Objections to the Change Proposal to change summary from an Attribute to an Element

We have a Change Proposal to change summary from an Attribute to an Element . 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 to change summary from an Attribute to an Element
Ben Boyle
aurélien levy
Gregory Rosmaita
Tab Atkins Jr.
Cynthia Shelly
Leif Halvard Silli
Laura Carlson
Denis Boudreau
Joshue O Connor
Martin Kliehm
Eric Eggert
Ian Hickson This doesn't address any new use cases as far as I can tell. It's already possible to provide a description in a caption (indeed, the spec encourages it). It doesn't help convey information to AT users (captions are already read to AT users and already easily skippable), it doesn't help convey information that would be hidden from non-AT users to non-AT users (the element as described does nothing that a simple caption would not as well).

In fact, this change proposal describes itself quite accurately as a Solomonic solution. It seems obvious on its face that we should only be considering technically sound solutions, not solutions that self-describe themselves as a pretence of a solution.

Furthermore, the proposed details make no sense. The term "activatable text" is not defined, it allows certain elements but not others that are substantially similar (e.g. <dfn> but not <i>), it allows suggests allowing <li> and <dd> elements as children, which is completely bogus given the definitions of those elements, but somehow still excludes other elements (e.g. <dt>) which seem to have equivalent standing; it doesn't define the semantics of those elements in that context...
Doug Jones
Stephen Axthelm
Jonas Sicking This proposal doesn't seem to provide any advantages over the existing aria-describedby mechanism. It's a new construct so no existing body of contents and no existing mind share exists. It further complicates implementations since they now have to look for summaries in two locations.

It also complicates the accessibility story that we have to tell authors as they now have even more features that they have to learn and that will show up in tutorials etc.

There doesn't appear to be any advantages for authors or users to ask the author to add a <summary> element around the summary. Instead the author could just leave the summary in the caption which would work in old browsers as well as be less work for the author.

Finally, it greatly limits authors in where they can get the summary rendered should they wish to have it rendered for sighted people. They could use CSS positioning to position the summary somewhere other than where the caption is rendered, but this doesn't allow the summary to take part of the normal flow of the text. Likely an author that wanted to render the summary below the table (which seems like a quite normal thing to do), would have to use CSS positioning together with scripts to get a good rendering. This would work particularly poorly with syndication as both CSS and scripts are often stripped.

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. Liam Quin <liam@w3.org>
  7. Richard Ishida <ishida@w3.org>
  8. Chris Wilson <cwilso@google.com>
  9. Wendy Chisholm <wendc@microsoft.com>
  10. David Carlisle <davidc@nag.co.uk>
  11. James Helman <jhelman@movielabs.com>
  12. Jim Allan <jimallan@tsbvi.edu>
  13. Chris Marrin <cmarrin@apple.com>
  14. Charles McCathie Nevile <chaals@yandex-team.ru>
  15. Philippe Le Hégaret <plh@w3.org>
  16. Don Brutzman <brutzman@nps.edu>
  17. T.V. Raman <raman@google.com>
  18. David Singer <singer@apple.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. David Baron <dbaron@dbaron.org>
  24. Lisa Seeman <lisa.seeman@zoho.com>
  25. Paul Cotton <Paul.Cotton@microsoft.com>
  26. Shane McCarron <shane@aptest.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. Janina Sajka <janina@rednote.net>
  34. Deborah Dahl <dahl@conversational-technologies.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 <wonsuk.lee@etri.re.kr>
  41. Maciej Stachowiak <mjs@apple.com>
  42. Robert Accettura <robert@accettura.com>
  43. Jonathan Watt <jwatt@jwatt.org>
  44. Steve Faulkner <faulkner.steve@gmail.com>
  45. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  46. Patrick Lauke <redux@splintered.co.uk>
  47. David MacDonald <David100@sympatico.ca>
  48. Jack Jansen <jack@cwi.nl>
  49. Boris Zbarsky <bzbarsky@mit.edu>
  50. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  51. Markku Hakkinen <mhakkinen@ets.org>
  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. Mark Crawford <mark.crawford@sap.com>
  66. Doug Schepers <schepers@w3.org>
  67. Ian Fette <ifette@google.com>
  68. Michael[tm] Smith <mike@w3.org>
  69. Julian Reschke <julian.reschke@gmx.de>
  70. Kelly Ford <kelly.ford@microsoft.com>
  71. Cameron McCormack <cam@mcc.id.au>
  72. Stefan Schnabel <stefan.schnabel@sap.com>
  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. Henri Sivonen <hsivonen@hsivonen.fi>
  82. Lachlan Hunt <lachlan.hunt@lachy.id.au>
  83. Krijn Hoetmer <w3c@qontent.nl>
  84. Markus Fischer <markus@fischer.name>
  85. Dean Edridge <dean@dean.kiwi>
  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@google.com>
  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. S Emerson <w3c@accretewebsolutions.ca>
  101. Morten Tollefsen <morten@medialt.no>
  102. Daniel Schattenkirchner <schattenkirchner.daniel@gmx.de>
  103. Edward O'Connor <eoconnor@apple.com>
  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. Marc Drumm <mdrumm@wcupa.edu>
  110. Danny Liang <danny.glue@gmail.com>
  111. Arne Johannessen <arne@thaw.de>
  112. Michael Puls II <shadow2531@gmail.com>
  113. Ron Reisor <ron@udel.edu>
  114. Marat Tanalin <mtanalin@yandex.ru>
  115. Andrew Norman <idonothaveacat@gmail.com>
  116. Craig Buckler <craigbuckler@gmail.com>
  117. Matthew Turvey <mcturvey@gmail.com>
  118. Dale Hudjik <dale.hudjik@gmail.com>
  119. James Cassell <w3c@cyberpear.com>
  120. Joseph D'Andrea <jdandrea@gmail.com>
  121. Pietro Russo <p.russo@webprofession.com>
  122. Moto Ishizawa <summerwind.jp+w3c@gmail.com>
  123. Chris Adams <chris@tuesdaybegins.com>
  124. Eric Carlson <eric.carlson@apple.com>
  125. Michael Turnwall <w3c@turnwall.net>
  126. Don Kiely <donkiely@computer.org>
  127. Robert Marshall <rdm@rdmsoft.com>
  128. Jane Lee <applegoddess@gmail.com>
  129. David Child <dave@addedbytes.com>
  130. Mark DuBois <Mark@webprofessionals.org>
  131. David Choi <daaave@gmail.com>
  132. David Bills <w3@dfbills.com>
  133. Nik Thierry <me@thisemail.ca>
  134. Andrew Ramsden <andrew@irama.org>
  135. John Foliot <john.foliot@deque.com>
  136. Shefik Macauley <allknightaccess@gmail.com>
  137. Joe Steele <steele@adobe.com>
  138. John Vernaleo <john@netpurgatory.com>
  139. Jeremy Keith <jeremy@adactio.com>
  140. Jedi Lin <JediLin@Gmail.com>
  141. Kenny Johar <kensingh@microsoft.com>
  142. Jon Hughes <jon@phazm.com>
  143. Anssi Kostiainen <anssi.kostiainen@intel.com>
  144. Samuel Santos <samaxes@gmail.com>
  145. Dean Jackson <dino@apple.com>
  146. Mohammed DADAS <mohammed.dadas@orange.com>
  147. Sally Cain <sally.cain@rnib.org.uk>
  148. Dan Romascanu <dromasca@avaya.com>
  149. David Bolter <dbolter@mozilla.com>
  150. Chris Double <cdouble@mozilla.com>
  151. Jeanne F Spellman <jeanne@w3.org>
  152. James Craig <jcraig@apple.com>
  153. MING JIN <ming.jin.web@gmail.com>
  154. Leonard Rosenthol <lrosenth@adobe.com>
  155. Philip Jägenstedt <philipj@opera.com>
  156. Adrian Bateman <adrianba@microsoft.com>
  157. Dionysios Synodinos <synodinos@gmail.com>
  158. Jean-Pierre EVAIN <evain@ebu.ch>
  159. Mark Pilgrim <pilgrim@google.com>
  160. Matt Lee <mattl@cnuk.org>
  161. Magnus Olsson <magnus.olsson@ericsson.com>
  162. Chris Pearce <cpearce@mozilla.com>
  163. Dzung Tran <dzung.d.tran@intel.com>
  164. Mark Miller <erights@google.com>
  165. Andrew Wilson <atwilson@google.com>
  166. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  167. Ojan Vafai <ojan@chromium.org>
  168. Martin McEvoy <martin@weborganics.co.uk>
  169. Aryeh Gregor <ayg@aryeh.name>
  170. Eliot Graff <eliotgra@microsoft.com>
  171. Frank Olivier <frank.olivier@microsoft.com>
  172. Jonathan Griffin <jgriffin@mozilla.com>
  173. Kris Krueger <krisk@microsoft.com>
  174. Erik Isaksen <erik_isaksen@hotmail.com>
  175. Daniel Davis <ddavis@w3.org>
  176. Anders Bondehagen <anders@bondehagen.com>
  177. Steven Pemberton <Steven.Pemberton@cwi.nl>
  178. Raul Hudea <rhudea@adobe.com>
  179. Raghavan Gurumurthy <raghavan@adobe.com>
  180. Mayank Kumar <mayankk@adobe.com>
  181. Monikandan S <smonikan@adobe.com>
  182. Dragos Georgita <dgeorgit@adobe.com>
  183. Christopher Bank <cbank@adobe.com>
  184. Dominik Tomaszuk <ddooss@wp.pl>
  185. Ole Riesenberg <or@oleriesenberg.com>
  186. Takuya Oikawa <takuya@google.com>
  187. Jatinder Mann <jmann@microsoft.com>
  188. Robert Stern <rstern@gmail.com>
  189. Dean Leigh <dean.leigh@deanleigh.co.uk>
  190. Eihab Ibrahim <eihabibrahim@gmail.com>
  191. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  192. Ian Pouncey <w3c@ipouncey.co.uk>
  193. Jer Noble <jer.noble@apple.com>
  194. Léonie Watson <lwatson@paciellogroup.com>
  195. Masatomo Kobayashi <mstm@jp.ibm.com>
  196. Grant Simpson <glsimpso@gmail.com>
  197. Peter Beverloo <beverloo@google.com>
  198. Andrew Scherkus <scherkus@google.com>
  199. Greg Johnson <greg.johnson@gmail.com>
  200. Martijn Croonen <martijn@martijnc.be>
  201. John Jansen <johnjan@microsoft.com>
  202. Stanley Manoski <manoski@mitre.org>
  203. Jonas Schneider <js.sokrates@gmail.com>
  204. Yosuke Funahashi <yosuke@w3.org>
  205. Mounir Lamouri <mlamouri@google.com>
  206. Mike Amundsen <mamund@yahoo.com>
  207. Tony Gentilcore <tonyg@google.com>
  208. Jacob Rossi <Jacob.Rossi@microsoft.com>
  209. Joseph Pecoraro <pecoraro@apple.com>
  210. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  211. Shoko Okuma <okuma@tomo-digi.co.jp>
  212. Fumitaka Watanabe <fwtnb@tomo-digi.co.jp>
  213. Yoshimitsu Tsurimaki <tsurimaki@tomo-digi.co.jp>
  214. Bob Lund <b.lund@cablelabs.com>
  215. Tatsuya Igarashi <Tatsuya.Igarashi@jp.sony.com>
  216. John Simmons <johnsim@microsoft.com>
  217. Mathias Bynens <mathias@qiwi.be>
  218. Mark Watson <watsonm@netflix.com>
  219. Clarke Stevens <c.stevens@cablelabs.com>
  220. Mark Vickers <mark_vickers@cable.comcast.com>
  221. Sree Kotay <Sree_Kotay@cable.comcast.com>
  222. Cameron Jones <cmhjones@gmail.com>
  223. Rik Cabanier <Cabanier@adobe.com>
  224. Jeremy LaCivita <jeremy.lacivita@theplatform.com>
  225. Denis Ah-Kang <denis@w3.org>
  226. Alvar Laigna <laigna@gmail.com>
  227. Kunio Ito <kunio.ito@mail.rakuten.com>
  228. David Mays <david_mays@comcast.com>
  229. Michael Chen <michael_chen@cable.comcast.com>
  230. jongyoul Park <jongyoul@etri.re.kr>
  231. Adrian Roselli <roselli@algonquinstudios.com>
  232. Colin Ihrig <cjihrig@gmail.com>
  233. Kilroy Hughes <kilroy.hughes@microsoft.com>
  234. Reinaldo Ferraz <reinaldo@nic.br>
  235. Bill Mandel <bill.mandel@nbcuni.com>
  236. Jonas Jacek <gaccesss@gmail.com>
  237. Eva Lingyun Jing <jinglingyun@baidu.com>
  238. GANG LIANG <gang.liang@huawei.com>
  239. Ryosuke Niwa <rniwa@apple.com>
  240. Jason Kiss <jason@accessibleculture.org>
  241. Gian Luca Marroni <gmarroni@libero.it>
  242. Ian Devlin <ian@iandevlin.com>
  243. Xingrong Guo <guoxingrong@baidu.com>
  244. Jet Villegas <w3c@junglecode.net>
  245. Alexander Surkov <surkov.alexander@gmail.com>
  246. Hasan Savran <hsavran@kent.edu>
  247. Ben Dalton <bendalton@gmail.com>
  248. Marco Kotrotsos <Marco@mlabs.nl>
  249. Brian Blakely <anewpage.media@gmail.com>
  250. Eric VonColln <eric.voncolln@navy.mil>
  251. Jason Boyd <jason@pixelboxdesign.co.uk>
  252. Jungkee Song <jungkee.song@samsung.com>
  253. Huan Ren <renhuan@360.cn>
  254. Xitong Huang <stonehuang@tencent.com>
  255. Rayi Lei <leiyi@baidu.com>
  256. Daniel Austin <daniel.austin@grintech.net>
  257. David Dorwin <ddorwin@google.com>
  258. jiexuan gao <gaojiexuan@baidu.com>
  259. Mathew Marquis <mat@matmarquis.com>
  260. Xiaoqing Yang <yangxiaoqing@baidu.com>
  261. Aaron Colwell <acolwell@google.com>
  262. Alex Giladi <alex.giladi@huawei.com>
  263. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  264. Kevin Streeter <kstreete@adobe.com>
  265. Christian Kaiser <kaiserc@google.com>
  266. François REMY <francois.remy.dev@outlook.com>
  267. Xuejian Li <lixuejian@baidu.com>
  268. Zuncheng Yang <yangzuncheng@baidu.com>
  269. Qianglong Zheng <zhengqianglong@baidu.com>
  270. Zhou Shen <shenzhou@baidu.com>
  271. Duoyi Wu <wuduoyi@baidu.com>
  272. Zheng Jia <jiazheng@baidu.com>
  273. Weifeng Feng <fengweifeng@baidu.com>
  274. Damin Hu <hudamin@baidu.com>
  275. Yang Liu <liuyang12@baidu.com>
  276. Zhixing Lei <leizhixing@baidu.com>
  277. Honggang Tang <tanghonggang@baidu.com>
  278. Kefeng Li <buaadallas@gmail.com>
  279. Xu Ma <maxu@baidu.com>
  280. Junzhong Liu <liujunzhong@baidu.com>
  281. Yusuke Maehama <maehama@tomo-digi.co.jp>
  282. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  283. Sheau Ng <Sheau.ng@nbcuni.com>
  284. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  285. Ami Fischman <fischman@google.com>
  286. Arnaud Braud <arnaud.braud@orange.com>
  287. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  288. Bram Tullemans <tullemans@ebu.ch>
  289. Petr Peterka <ppeterka@verimatrix.com>
  290. lei wang <wanglei03@baidu.com>
  291. Milan Patel <Milan.Patel@huawei.com>
  292. Yiling Gu <guyiling@baidu.com>
  293. Yehuda Katz <wycats@gmail.com>
  294. Xueqing Huang <huangxueqing@baidu.com>
  295. Zefa Xiong <xiongzefa@baidu.com>
  296. shanglin chen <chenshanglin@baidu.com>
  297. Yaso Córdova <yaso@nic.br>
  298. Dongsheng Zhang <zhangdongsheng@baidu.com>
  299. Ping Wu <wuping02@baidu.com>
  300. Yao Tong <tongyao@baidu.com>
  301. Bin Chen <chenbin01@baidu.com>
  302. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  303. Patrick Ladd <Pat_Ladd2@cable.comcast.com>
  304. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  305. Billy Gregory <bgregory@paciellogroup.com>
  306. Hanrui Gao <gaohanrui@360.cn>
  307. Hao Jing <jh.jinghao@huawei.com>
  308. Glenn Deen <glenn.deen@nbcuni.com>
  309. Lei Wang <wanglei@baidu.com>
  310. Tom Handal <thandal@verimatrix.com>
  311. Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>
  312. Jose Segura <jose.segura@mail.rakuten.com>
  313. Pengcheng Guo <guopengcheng@baidu.com>
  314. Erika Doyle Navara <erika.doyle@microsoft.com>
  315. Tom Wiltzius <wiltzius@google.com>
  316. Pierre-Anthony Lemieux <pal@sandflow.com>
  317. Xie Jianhui <xiejianhui@baidu.com>
  318. Yujie Jiang <jiangyujie@baidu.com>
  319. Leslie Sikos <sikos@sikoswebconsulting.com.au>
  320. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  321. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  322. Brady Eidson <beidson@apple.com>
  323. Jerry Smith <jdsmith@microsoft.com>
  324. Michael Thornburgh <mthornbu@adobe.com>
  325. Cyril Rickelton-Abdi <cyril.rickelton-abdi@turner.com>
  326. Andrew Davis <andrew@diff.mx>
  327. Mick Hakobyan <mhakobyan@netflix.com>
  328. Mallory van Achterberg <stommepoes@stommepoes.nl>
  329. Vladimir Sinelnikov <sinelnikov@gmail.com>
  330. Chris Wong <huanghoujin@baidu.com>
  331. Yiliang LIU <liuyiliang@baidu.com>
  332. Hernan Beati <hernanbeati@gmail.com>
  333. mingqiang zhang <imcnan@gmail.com>
  334. yubo zhou <zhouyubo@360.cn>
  335. Ben Barber <barberboy@gmail.com>
  336. Matt Rakow <marakow@microsoft.com>
  337. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  338. Grzegorz Babula <gbabula@gmail.com>
  339. Brian Kardell <hitchjs@gmail.com>
  340. xueliang fan <fanxueliang@baidu.com>
  341. Niels Thorwirth <nthorwirth@verimatrix.com>
  342. David Evans <david.evans@rd.bbc.co.uk>
  343. Danny O'Brien <danny@eff.org>
  344. Joseph Karr O'Connor <josephoconnor@mac.com>
  345. Seth Schoen <schoen@eff.org>
  346. Jamil Ellis <jamil.ellis@hbo.com>
  347. Jim Walsh <jim@jwalshcreative.com>
  348. Greg Davis <greg.davis@pearson.com>
  349. Gabino Alonso <gabinovincent@gmail.com>
  350. Sam Langdon <sam.langdon@hachette.co.uk>
  351. Michael Kelly <mkelly@mozilla.com>
  352. Xiaoqian Wu <xiaoqian@w3.org>
  353. Yue Min <minyue@baidu.com>
  354. Min Li <limin04@baidu.com>
  355. A.S. Krishnakumar <ask@avaya.com>
  356. Shijun Sun <shijuns@microsoft.com>
  357. Jonathan Neal <jonathantneal@gmail.com>
  358. Joanmarie Diggs <jdiggs@igalia.com>
  359. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  360. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  361. So Vang <svang@nab.org>
  362. Nathalia Sautchuk Patrício <nathalia@nic.br>
  363. Deblyn prado <deblyn@nic.br>
  364. Vicente García Díaz <vicegd@live.com>
  365. Nolan Butcher <nolan.butcher@hbo.com>
  366. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  367. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  368. John Riviello <john_riviello@comcast.com>
  369. yaolong wang <wangyaolong@baidu.com>
  370. Shun-ichi Sekiguchi <Sekiguchi.Shunichi@eb.MitsubishiElectric.co.jp>
  371. Tao Liang <liangtao01@baidu.com>
  372. Glenn Eguchi <geguchi@adobe.com>
  373. Hirofumi Nishikawa <Nishikawa.Hirofumi@cs.MitsubishiElectric.co.jp>
  374. Hiroyuki Yamada <Yamada.Hiroyuki@dn.MitsubishiElectric.co.jp>
  375. Chockalingam Muthian <chockam@gmail.com>
  376. Lukáš Čihák <lukas.cihak@mensa.cz>
  377. Anatoly Shikolay <shikolay@gmail.com>
  378. WOOGLAE KIM <wlkim@inswave.com>
  379. Min Ren <minren@tencent.com>
  380. Rustam Khashimkhodjaev <Rustam_Khashimkhodjaev@cable.comcast.com>
  381. Brian Evans <Brian.Evans@microsoft.com>
  382. Jason White <jjwhite@ets.org>
  383. Hyejin Lee <hjlee@html5forum.or.kr>
  384. Richard Grzeczkowski <richard_grzeczkowski@cable.comcast.com>
  385. Pascal Perrot <pascal.perrot@orange.com>
  386. Dongseong Hwang <dongseong.hwang@intel.com>
  387. Dapeng Liu <max.ldp@alibaba-inc.com>
  388. Matthew Wolenetz <wolenetz@google.com>
  389. Cory Heslip <cory_heslip@cable.comcast.com>
  390. Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  391. Nirankush Panchbhai <npanch@microsoft.com>
  392. Pramod Patlolla <pramod.patlolla@turner.com>
  393. Cooper Pope <cooper.pope@turner.com>
  394. Grisha Lyukshin <glyuk@microsoft.com>

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


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.129 2015/07/01 16:13:23 kahan Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)