W3C WBS Home

Results of Questionnaire UAWG Survey for 17 February 2011

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: w3c-archive@w3.org, jeanne@w3.org

This questionnaire was open from 2011-02-15 to 2011-02-25.

6 answers have been received.

Jump to results for question:

  1. ACTION-504 - Rewrite 2.9.1 Background Image Toggle
  2. ACTION-503 - 2.9.2 Time-Based Media Load-Only
  3. Intent of Success Criterion 1.4.1
  4. New SC
  5. ACTION-489 - Replacing the term "enabled element" as used in 1.3
  6. ACTION-489 - Replacing "enabled element" in 1.3.1
  7. ACTION-489 - 1.3.2
  8. ACTION-489 - 1.3.3
  9. Rewrite 1.11.1 Basic Link Information
  10. Rewrite 1.11.2 Extended Link Information:

1. ACTION-504 - Rewrite 2.9.1 Background Image Toggle

Proposed 2.9.1 Background Image Toggle

2.9.1 (former 4.9.1) Background Image Toggle: The user can have all background images shown or hidden. (Level A)

Intent:

It can be difficult for some people to read text or identify images when the background is complex or doesn't contrast well with the foreground. Allowing users to disable the display of background images helps ensure that foreground content remains easy to read. This can also help remove purely decorative distractions, which is important for some users.

Users could have the option to have non-transparent backgrounds of a solid color of their choice drawn behind text, rather than turning off background images.

Because background images occasionally convey important information, when their display is turned off the user agent should give users access to any alternative content associated with them.

This checkpoint does not address issues of multi-layered renderings and does not require the user agent to change background rendering for multi-layer renderings (refer, for example, to the z-index property in Cascading Style Sheets, level 2 ([CSS2], section 9.9.1)

Examples:

James has a reading disability where he needs text to be clear from distractions that are not related to the text. He configures his user agent not to load background images and navigates to a web page. James then gets only the text from the web page without any images interfering with what he is reading.

Related Resources:

1. In CSS, background images may be turned on/off with the background and background-image properties ([CSS2], section 14.2.1).

2. The z-index property in Cascading Style Sheets, level 2 ([CSS2], section 9.9.1)

3. Because background images occasionally convey important information, when their display is turned off the user agent should give users access to any alternative content associated with them. (At the time of this writing, HTML does not support alternative content for background images, but this may be supported in other technologies or future versions.)

4. See Success Criteria 1.4.1 "Configure Text" for more information related to background colors.

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field) 3
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group 1

Details

Responder ACTION-504 - Rewrite 2.9.1 Background Image ToggleComments 2.9.1 Background Image Toggle
Greg Lowney Recommend changes (see comments field) The second and third paragraphs really belong with a separate SC that either supplements or replaces the one quoted here. That's because:

a) The second paragraph of the Intent is written as if providing an alternative way of meeting the criterion, but the actual SC wording does not support it. In that way it essentially contradicts the SC.

b) The third paragraph reads like additional guidance on how to comply with the SC, but it's actually a recommendation of behavior that could be done *in addition* to the behaviors required by the SC.

I'd also suggest that the final paragraph ("This checkpoint does not address...") be modified slightly to clarify what it *DOES* address, as in "This checkpoint applies to that are unambiguously defined as being written on the base background, such as the HTML background property. It does not apply to cases where complex computation is required to determine whether or not some content will appear behind or overlap other content, as with the multi-layered renderings..."
Markku Hakkinen Recommend changes (see comments field) I am concerned that the use of "could" in the following:

"Users could have the option to have non-transparent backgrounds of a solid color of their choice drawn behind text, rather than turning off background images."

Puts this part into a an "AA" category, while the rest is "A". The problem I see, which I don't think is clearly stated is the when the foreground text color is white, the background is a distracting mix of dark colors, and the default page background is matches the text color. After bg image removal, the text is "invisible". I see this happen far too often in practice.

I would change the ability to alter the background color to a "should".

Suggested change:

"Users should have the option to have non-transparent backgrounds of a solid color of their choice drawn behind text, rather than turning off background images. This ensures that foreground text does not disappear when the image is removed and the default background color does not provide sufficient contrast with the foreground text color."

I would further suggest in the techniques that an appropriate background color could be programmatically determined by the UA based on the foreground text color. Perhaps think about a "Improve Text Legibility" option in the UA as a way to enable this in a user understandable manner (as opposed to simply saying "remove background images").
Jeanne F Spellman Recommend changes (see comments field) Background images don't have alternative information in CSS. Remove that sentence.
Jim Allan Accept the proposal
Kimberly Patch Accept the proposal
Simon Harper Neutral - will accept the consensus of the group

2. ACTION-503 - 2.9.2 Time-Based Media Load-Only

Proposed

2.9.2 Time-Based Media Load-Only: The user can load time-based media content such that the first frame is displayed (if video), but the content is not played until explicit user request. (Level A)

Intent

As an opt-in user setting, autoplay for media is off/paused, until the user activates 'play'. Prevent media from playing without explicit request from the user. For example, Uart, a screen reader user, opens a page with an audio element that starts playing immediately. The user cannot hear the screen reader because of the noise from the audio element, and must search through the page to find the 'noisy' element to turn it off (or pause). Once the screen reader is the sole source of audio the user can read the page and determine if the audio is important and choose to play it.

Examples

1. Using the same techniques as are used for pop-up blockers, the user agent checks to see if the play() request was from user interaction or a background script. If isn't from direct user interaction, the user agent could ask the user to explicitly allow the media to play, perhaps remembering the choice for the site.

2. Playback of a <video> or <audio> element can only be triggered in response to a user gesture on a touch screen device with no keyboard (like pop-up blockers). The user agent provides a visual and auditory indicator that the video is in paused state and needs user interaction to start.

3. The user agent provides a global control that calls "paused for user interaction" for all media when a page loads.

Resources

HTML5 4.8.10.8 Playing the media resource (http://dev.w3.org/html5/spec/Overview.html#playing-the-media-resource)

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field) 3
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group 1

Details

Responder ACTION-503 - 2.9.2 Time-Based Media Load-OnlyComments 2.9.2
Greg Lowney Recommend changes (see comments field) Suggest enhancing the SC to explicitly say that the user agent must inform the user that media is available and how to start it. (E.g. In a graphical user agent, provide a "Play" button in proximity to where the media will be played, or a message in the status bar telling the user that media is paused and including a link to start it playing.) Displaying the first frame of the video might be left as a recommended implementation detail, rather than a strict requirement, because it can be difficult (e.g. have to start streaming the video) or useless (e.g. a black screen).

Suggest moving the example from the Intent paragraph to the Examples list.

The Intent paragraph should clarify the benefit of this for users, e.g. "This helps users who need to avoid signals that may trigger seizures, as well as users who are easily distracted, or who have difficulty interacting with the controls provided for playing media."

Example 1 sounds as if it's recommending the user agent prompt the user when it renders a page that tries to autoplay some media. I don't think we want to encourage modal prompts, especially if it's once per media, when a page may have several.

Example 3 is about AT compatibility, so does not really belong in Principle 2. It could be a note about a related technique included after the Intent paragraph, but not in the examples.
Markku Hakkinen Recommend changes (see comments field) As much as I fondly recall building serial communications circuits, I think the use of Uart distracts due to its technical association (at least for some of us). Keep the Uart, in part, by changing the name to "Stuart".

Perhaps the UA theme can be carried out by using only names containing UA [1].

[1] http://www.nameplayground.com/?nameswith=UA&withtype=
Jeanne F Spellman Accept the proposal Grammar edits in Intent. Example #1 use "similar techniques" instead of "same techniques".
Jim Allan Recommend changes (see comments field) remove "Prevent media from playing without explicit request from the user." from the INTENT
Kimberly Patch Accept the proposal minor edit: change "1. Using the same techniques as are"
to "1. Using the same techniques that are"
Simon Harper Neutral - will accept the consensus of the group

3. Intent of Success Criterion 1.4.1

Intent of Success Criterion 1.4.1

Users need to able to access a wide range of font sizes, styles, colors, and other attributes in order to find the combination that works best for their particular needs. For example, some users want to increase font size to make text more legible, while other users want to reduce the font size to decrease the need to scroll the content. <NEW>Other users may want to set a solid color behind all text in order to cover background images that might reduce readability.</NEW> In providing these preferences, it is important to avoid making assumptions. For example, some users want to reduce the font size to decrease the need to scroll the content.

Summary

ChoiceAll responders
Results
Accept the proposal 5
Recommend changes (see comments field) 1
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Intent of Success Criterion 1.4.1Comments 1.4.1
Greg Lowney Recommend changes (see comments field) The new sentence is fine, but the final sentence is redundant to the second sentence.
Markku Hakkinen Accept the proposal See comment about "improve text legibility" option in question 1.
Jeanne F Spellman Accept the proposal
Jim Allan Accept the proposal
Kimberly Patch Accept the proposal
Simon Harper Accept the proposal

4. New SC

New SC

Jan's email

BTW: I'm *not* pushing hard for a new SC, we already have a lot. So if someone can see how this is covered elsewhere, that would be great!

New SC: Present Status Information in Proximity: The user can specify that status information for rendered elements be either incorporated into the rendering or displayed in proximity to the element.

Intent: Users need to be able to discover and make use of status information for elements, which is more difficult if the information is displayed at a distance from the element (e.g., the status bar).

Examples: (1) Link target: A browser that typically displays the target of a link in the status bar when the link receives focus, includes an option to display the target in an overlay adjacent to the link. (2) Required field: A browser renders a required form control with an adjacent icon indicating this status, rather than a note in the status bar when the control receives focus.

Summary

ChoiceAll responders
Results
Accept the proposal 1
Recommend changes (see comments field) 1
The proposal needs more discussion (see comments field) 2
Disagree with the proposal
Neutral - will accept the consensus of the group 2

Details

Responder New SCComments New SC
Greg Lowney Neutral - will accept the consensus of the group I'd be OK including it but as low priority.

I would add to the Intent section something to the effect that "It is recommended that the user be able to turn off this behavior, as it can actually be detrimental in some cases, especially when the change takes place automatically when the user navigates the document. For example, presenting information in-line requires content to reflow on the fly, which can be disconcerting or disorienting, while displaying it in a pop-up or overlay necessarily obscures part of the surrounding content."

In example 2, one might replace icon with "asterisk", as a textual indicator is probably preferred over an icon.
Markku Hakkinen The proposal needs more discussion (see comments field) I don't disagree, but I thought at some point we had some text related to displaying information adjacent or in close proximity (I think it came up with regard to TTS rendering information, but I could be wrong). However, I don't see it in the current draft anywhere.

In some UA's (Internet Explorer), you can bring up a properties dialog for the link to display information, including URL. Generally, screen readers already can provide this information. The issue appears greatest for magnifier users and some sighted users.

I am not sure how "incorporating it into the rendering" works, especially as so many URLs can be quite long, leading to a more complex presentation than if a pop-up were provided.

Jeanne F Spellman Neutral - will accept the consensus of the group
Jim Allan The proposal needs more discussion (see comments field) Seems to fit in GL3 Ensure that the user interface is understandable
should be a AAA
I thinks it is needed
Kimberly Patch Recommend changes (see comments field) Minor edit: change "receives focus, includes"
to "receives focus includes" (remove comma)
Simon Harper Accept the proposal

5. ACTION-489 - Replacing the term "enabled element" as used in 1.3

Guideline 1.3

Greg's email with the context and rationale behind the changes he is proposing. "The changes to 1.3 include: 1. made it broader by changing "selection, content focus, enabled elements, visited links" to "selection, active keyboard focus, and interactive elements"

Existing Text of 1.3

1.3 Provide highlighting for selection, active keyboard focus, and interactive elements.

Summary

ChoiceAll responders
Results
Accept the proposal 5
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 1
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder ACTION-489 - Replacing the term "enabled element" as used in 1.3Comments 1.3
Greg Lowney Accept the proposal
Markku Hakkinen Accept the proposal
Jeanne F Spellman Accept the proposal
Jim Allan The proposal needs more discussion (see comments field) 1.3.3 is a NEW SC.
1.3.3.a enabled controls that take input (e.g. push buttons, radio buttons, check boxes, and text input fields, but not groupings or static text and images) regardless of whether they are read-write or read-only, (read-only should be eliminated, these items should not take input, nor should the receive focus. )

need explanation for 1.3.3.b.
if something is non-operable, giving it a highlight, to me, tells the user that the item is operable. This could be confusing to some users.
Kimberly Patch Accept the proposal
Simon Harper Accept the proposal

6. ACTION-489 - Replacing "enabled element" in 1.3.1

SC 1.3.1

Greg's email with the context and rationale behind the changes he is proposing.

Existing Text of 1.3.1

1.3.1 (former 3.5.1) Highlighted Items: The user can have the following highlighted /when recognized,/ so that each class is uniquely distinguished (Level A):
* (a) the selection
* (b) /the active keyboard /focus
* (c) the active window
* (d) links that have been visited recently
* (e) links that have not been visited recently

Changes

The changes to 1.3.1 Highlighted Items include:
1. added "when recognized" to the SC, so we would not need to repeat it in each of the bullet items
2. changed "content focus" to "the active keyboard focus" because the former term is no longer used (except it also needs to be changed in 2.2.3)
3. added "the active window"
4. removed "recognized enabled elements", which were split off into 1.3.3 Highlighted Input Controls
5. deleted "presence of alternative content" because that's redundant to 1.1.3 Identify Alternative Content
6. changed "recently visited links" to "links that have been recently visited" and "links that have not been recently visited"

Open Questions

1. Is there a more concise way to say "links that have not been visited recently"?

2. Do we want to incorporate any material from the new 1.3.3 Intent and Related Resources sections into those for 1.3.1?

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 3
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder ACTION-489 - Replacing "enabled element" in 1.3.1Comments 1.3.1
Greg Lowney Accept the proposal But take out the slashes.
Markku Hakkinen The proposal needs more discussion (see comments field) Is there a way for a UA to currently indicate "links that have not been visited recently"? Clearly it could be determined from the history, but I don't see it as a feature implemented today... more a general usability improvement.

Why not just "Unvisited links". In the techniques perhaps it could be discussed that "not recently visited" could be an improvement.
Jeanne F Spellman Accept the proposal
Jim Allan The proposal needs more discussion (see comments field) agree with the proposal.
Q1. non-visited,
Q2. it should be possible to merge all IER for 1.3.x into one overarching IER for all 3 SC.
Kimberly Patch Accept the proposal
Simon Harper The proposal needs more discussion (see comments field)

7. ACTION-489 - 1.3.2

SC 1.3.2

Greg's email with the context and rationale behind the changes he is proposing.

Existing Text of 1.3.2

*1.3.2 (former 3.5.2) Highlighting Options:* When highlighting classes specified by 1.3.1 Highlighted Items /and 1.3.3 Highlighted Input Controls/, the user can specify highlighting options that include at least (Level A):
* (a) foreground colors,
* (b) background colors, and
* (c) border (configurable color, style, and thickness)

Changes

The changes to 1.3.2 Highlighting Options include:
1. added "and 1.3.3 Highlighted Input Controls" so it covers both the existing 1.3.1 and the new 1.3.3

Summary

ChoiceAll responders
Results
Accept the proposal 5
Recommend changes (see comments field) 1
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder ACTION-489 - 1.3.2Comments 1.3.2
Greg Lowney Recommend changes (see comments field) Perhaps change "border (configurable color..." to "border formatting (color..." to make it parallel construction with the earlier list items.
Markku Hakkinen Accept the proposal
Jeanne F Spellman Accept the proposal
Jim Allan Accept the proposal
Kimberly Patch Accept the proposal
Simon Harper Accept the proposal

8. ACTION-489 - 1.3.3

SC 1.3.3

Greg's email with the context and rationale behind the changes he is proposing.

Existing Text of 1.3.3

1.3.3 Highlighted Input Controls:* The user can have the following highlighted when they are recognized. (Level AA):
(a) enabled controls that take input (e.g. push buttons, radio buttons, check boxes, and text input fields, but not groupings or static text and images) regardless of whether they are read-write or read-only, and
(b) elements with scripted input handlers (e.g. images or text ranges that have onClick or onKeyPress events) regardless of whether the current state allows them to operate.

Intent for Success Criterion 1.3.3

When a user looks at a page they often want to quickly find the control they need to accomplish their task, yet in some pages the controls may be "buried" amid a large amount of other content, or may be styled to make it very hard to distinguish from other content. This can be particularly difficult for people with visual impairments, who may not be able to easily distinguish visual differences that may be subtle or obvious to users with average vision. It can also be a problem for people with some cognitive impairments, who may have difficulty distinguishing between items with similar or non-standard appearance. The ability to have these items visually distinguished can greatly help reduce the amount of time or number of commands they need to use examining a page. This success criterion works in conjunction with 1.3.1 Highlighted Items, which ensures highlighting of several other classes of information, and with 1.3.2 Highlighting Options, which ensures that the user can customize the highlighting to meet their visual or cognitive needs.

Examples for Success Criterion 1.3.3

* Binh gets easily frustrated when he cannot locate the buttons and links on a page, usually because they don't have the standard appearance he's used to. By turning on the option to have all links appear in bright purple, and all push buttons and the like drawn with a bright purple border, he can easily scan the page and find the items he's looking for.

Related Resources for Success Criterion 1.3.3

* 1.1.3 Identify Presence of Alternative Content (Level A) requires items with alternative content to be highlighted.
* 1.3.1 Highlighted Items (Level A) requires highlighting of additional classes, including the selection, the active keyboard focus, and visited and unvisited links.
* 1.3.2 Highlighting Options (Level A) requires the user be able to customize the appearances of these highlights.

Summary

ChoiceAll responders
Results
Accept the proposal 6
Recommend changes (see comments field)
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder ACTION-489 - 1.3.3Comments 1.3.3
Greg Lowney Accept the proposal
Markku Hakkinen Accept the proposal
Jeanne F Spellman Accept the proposal
Jim Allan Accept the proposal
Kimberly Patch Accept the proposal
Simon Harper Accept the proposal

9. Rewrite 1.11.1 Basic Link Information

SC 1.11.1

Simon's email

Existing Text of 1.11.1

1.11.1 (former 3.13.1) Basic Link Information:
The following information is provided for each link (Level A) :
* link element content,
* link title
* link status (visited/selected/hover)

Intent for Success Criterion 1.11.1

Users who use screen readers need to be able to easily discover information about a link, including the title of the link in the event that the link content has the same text as other links on the page. Otherwise the effect of selecting that link is not distinguishable.

Examples for Success Criterion 1.11.1

Robert, who uses a screen reader, hears a list of links read out saying 'more', 'more', 'more'. The browser also displays the link title so that Robert can distinguish which link he must select.

Related Resources for Success Criterion 1.11.1

Web Content Accessibility Guidelines version 2.0

Summary

ChoiceAll responders
Results
Accept the proposal 3
Recommend changes (see comments field) 3
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Rewrite 1.11.1 Basic Link InformationComments 1.11.1
Greg Lowney Recommend changes (see comments field) In the SC, consider changing "provided" to "presented" as the former sounds like guidance for the content author.

Also, this should apply only when the author provides these attributes, or when UAAG requires the user agent to create repair text for missing or empty attributes.

Thus, perhaps use something like "When they are available, the following link attributes are presented to the user".

Re the Intent and Examples, I don't think this is just about screen reader users, so should probably broaden the first sentence of the Intent paragraph and at least one more example.

In fact, the first example ("Robert, who uses a screen reader") is weak because in most cases a screen reader would be able to voice this information without actually requiring the user agent to display it, and in fact, that would probably be preferable.

A new example might be "Jules has low vision and greatly enlarges his fonts, with the result that only a few lines are visible at a time. He visits a Web page that contains many links with the same link element contents ("click here"), so he configures his browser to use distinct colors for visited and unvisited links, and display each link's title attribute immediately after it, so that he can more easily choose the links he's looking for."

Finally, shouldn't either 1.11.1 or 1.11.2 include link target (e.g. URI)?
Markku Hakkinen Recommend changes (see comments field) In order to avoid potential confusion with link title attribute, change to:

* title of the linked Web resource


Jeanne F Spellman Recommend changes (see comments field) I still have reservations about the link status being included (because it seems to me to be a different category of information), but will accept the group consensus. The URI, however, is part of the basic link information that a sighted user might see in the status bar at the bottom of the window. This is useful for confirming link safety, or the domain the link is going to. I think this should be included, but will accept the consensus of the group.
Jim Allan Accept the proposal This also seems similar to link part of Jan's SC.
Kimberly Patch Accept the proposal
Simon Harper Accept the proposal

10. Rewrite 1.11.2 Extended Link Information:

SC 1.11.2

Simon's email

Existing Text of 1.11.2

1.11.2 (former 3.13.2) Extended Link Information: The following information is provided for each link which does not point to an (x)html file (Level AAA) :
* what will be the consequences of selecting the link (will a file download to desktop occur? Will a text file be opened by the browser?)
* technology type (of the linked Web resource)
* technology file size (of the linked Web resource)
* predicted time to load (of the linked Web resource)
* intra-page/onsite/offsite (whether the link is internal to the resource e.g., the link is to a target in the same Web page)

Intent for Success Criterion 1.11.2

Here we wish to mitigate the possibility of unexpected consequences occurring on link selection; this is especially the case for users who cannot see the visual cues present on the web page. For instance, visual styling can be used to imbue groups of simple links with semantic differences such as downloads or offsite links. This may then become a problem because links which seem the same to a user of assistive technology may have unexpected consequences when selected.

Examples for Success Criterion 1.11.2

Robert, who uses a screen reader, selects a link which is surrounding an image, the user agent downloads the image and displays the raw image file, Robert's assistive technology cannot describe the image or even say what has downloaded because raw images do not have alt elements and image downloaded and displayed is not an html file. If the user agent tells Robert that an image file download will occur on link selection he would not have made that choice as he cannot see the image.

Related Resources for Success Criterion 1.11.1

Web Content Accessibility Guidelines version 2.0

Summary

ChoiceAll responders
Results
Accept the proposal 4
Recommend changes (see comments field) 1
The proposal needs more discussion (see comments field)
Disagree with the proposal
Neutral - will accept the consensus of the group

(1 response didn't contain an answer to this question)

Details

Responder Rewrite 1.11.2 Extended Link Information:Comments 1.11.2
Greg Lowney Recommend changes (see comments field) Most of my comments about 1.11.1 apply here. For example, in the SC consider changing "provided" to "presented" as the former sounds like guidance for the content author, and it should only be required when the information is recognized by the user agent (e.g. a browser does not have to download a link target just to be able to tell the user it's file size and technology type).
Markku Hakkinen Accept the proposal
Jeanne F Spellman Accept the proposal
Jim Allan Accept the proposal
Kimberly Patch Minor edits:
Change
"Here we wish to mitigate the possibility of unexpected consequences occurring on link selection; this is especially the case for users..."
to
"Browsers need to mitigate the possibility of unexpected consequences, especially for users..."
Simon Harper Accept the proposal

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Jan Richards <jrichards@ocadu.ca>
  3. Eric Hansen <ehansen@ets.org>
  4. Kelly Ford <kelly.ford@microsoft.com>
  5. Peter Parente <pparent@us.ibm.com>
  6. Simon Pieters <simonp@opera.com>
  7. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  8. Alan Cantor <alan@cantoraccess.com>
  9. he wen <rockywen@tencent.com>
  10. Henny Swan <hswan@paciellogroup.com>
  11. Shaohang Yang <shaohang.ysh@alibaba-inc.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.127 2015-02-04 08:52:34 carcone 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)