W3C WBS Home

Results of Questionnaire AUWG Survey for 20 June 2011

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-06-16 to 2011-06-30.

7 answers have been received.

Jump to results for question:

  1. A.3.1.3 PROPOSAL: Adjust defined term to "sequential keyboard access"
  2. A.3.5.1 PROPOSAL: To split the search requirement
  3. A.3.1.3 ACTION: JR to update answer to IBM24 to better address mobile
  4. PROPOSAL: A.3.6.1 Independence of Display
  5. PROPOSAL: A.3.6.2 Save Settings
  6. PROPOSAL: A.3.6.3 Apply Platform Settings
  7. PROPOSAL: A.3.6.4 Multiple Sets
  8. PROPOSAL: A.3.6.5 Assistance with Preferences
  9. PROPOSAL: A.4.2.2 Document Author-Level Features
  10. PROPOSAL: A.3.2.1 Auto-Save
  11. PROPOSAL: A.3.2.4 Auto-Save (Extended)
  12. PROPOSAL to shorten the way we indicate SC Level depends on WCAG 2.0
  13. PROPOSAL: update definition of accessible templates (WCAG)
  14. PROPOSAL: B.2.4.1 Accessible Template Options (WCAG):
  15. PROPOSAL: B.2.4.2 Identify Template Accessibility (Minimum)
  16. PROPOSAL: B.2.4.x Identify Template Accessibility (Enhanced)
  17. PROPOSAL: B.3.1.4 Status Report
  18. B.3.1.5 Programmatic association of results
  19. Proposal on B.4.2.1 Model Practice (WCAG) in ATAG 2.0

1. A.3.1.3 PROPOSAL: Adjust defined term to "sequential keyboard access"

ACTION: JR Consider how to set a minimum criteria for A.3.1

Jan's email

PROPOSAL: Adjust defined term to "sequential keyboard access" (and adjust the definition):

A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA)

sequential keyboard access
Using a keyboard interface to navigate the focus one-by-one through all of the items in an ordered set (e.g. menu items, form fields, etc.) until the desired item is reached and activated. This is in contrast to direct keyboard access methods such as keyboard shortcuts and the use of bypass links.

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 1

Details

Responder A.3.1.3 PROPOSAL: Adjust defined term to "sequential keyboard access" Comments on A.3.1.3
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Neutral - will accept the consensus of the group I'm not sure that using 'access' instead of navigation helps here, but it's a very minor change.
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

2. A.3.5.1 PROPOSAL: To split the search requirement

A.3.5.1 ACTION: JR in A.3.5.1, use "web content being edited" to be more clear that this refers to editing views. AND ACTION: JR work in "Focus is moved and the match is made visible to the author" to A.3.5.1

Jan's email

PROPOSAL: To split the search requirement into an AA minimum (within current editing view) at an AAA enhanced (all editing views). The reason is that browser search functions are confined to text that is currently rendered (including within textboxes) and we want these functions to be leveraged by web-based tools.

Success Criterion A.3.5.1 Text Search (Minimum): Editing-views enable text search, such that all of the following are true: (Level AA)
(a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
(b) Match: Matching results can be made visible to the author and given focus; and
(c) No Match: Authors are informed when no matching results are found; and
(d) Two-way: The search can be made forwards or backwards; and (e) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Success Criterion A.3.5.X Text Search (Enhanced): The authoring tool enables text search of all editable text in the web content being edited. (Level AAA)

Note: Authoring tools that support multiple editing-views should display search results in editing-views in which the results are editable.

Summary

ChoiceAll responders
Results
Accept the proposal 6
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 A.3.5.1 PROPOSAL: To split the search requirementComments on A.3.5.1 & A.3.5.x
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Recommend changes (see comments field) I can't tell what the difference is between level AA and AAA:
- "Any text content that is editable by the editing-view is searchable"
- "search of all editable text in the web content being edited"

I may have missed the discussion of a use-case where this matters, but it should be clear what extra the AAA covers.
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal Propose to drop AAA requirement
Sueann Nichols Accept the proposal

3. A.3.1.3 ACTION: JR to update answer to IBM24 to better address mobile

ACTION: JR to update answer to IBM24 to better address mobile

Jan's email

AUWG: This requirement has been changed to clarify that mechanisms such as skip-over links qualify: FOLLOWED BY SC WORDING THAT MAY CHANGE DUE TO A.3.1.3 PROPOSAL ABOVE

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 1

Details

Responder A.3.1.3 ACTION: JR to update answer to IBM24 to better address mobileComments on A.3.1.3 to IBM24
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Neutral - will accept the consensus of the group
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols The proposal needs more discussion (see comments field) ACTION: JR to update answer to IBM24 to better address mobile

Unclear what the proposal is?
PROPOSAL:
AUWG: This requirement has been changed to clarify that mechanisms such as skip-over links qualify: FOLLOWED BY SC WORDING THAT MAY CHANGE DUE TO A.3.1.3 PROPOSAL ABOVE

4. PROPOSAL: A.3.6.1 Independence of Display

PROPOSAL: A.3.6.1 Independence of Display:

Jan's email

PROPOSAL: A.3.6.1 Independence of Display: If the authoring tool includes display settings, then authors can adjust these settings for editing-views without affecting the web content to be published. (Level A)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: A.3.6.1 Independence of DisplayComments on A.3.6.1 & A.3.5.x
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal (Assuming this is in addition to the current 3.6.1 which is about user settings.)
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

5. PROPOSAL: A.3.6.2 Save Settings

PROPOSAL: A.3.6.2 Save Settings

Jan's email

PROPOSAL: A.3.6.2 Save Settings: If the authoring tool includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: A.3.6.2 Save SettingsComments on A.3.6.2 & A.3.5.x
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

6. PROPOSAL: A.3.6.3 Apply Platform Settings

PROPOSAL: A.3.6.3 Apply Platform Settings

Jan's email

PROPOSAL: A.3.6.3 Apply Platform Settings: The authoring tool respects changes in platform display and control settings made by authors. (Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: A.3.6.3 Apply Platform SettingsComments on A.3.6.3
Jan Richards Accept the proposal This SC would benefit from Related Resources that listed what sorts of display and control settings are available on various platforms.
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal Does this also need "without affecting the web content to be published."
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

7. PROPOSAL: A.3.6.4 Multiple Sets

A.3.6.4 Multiple Sets

Jan's email

PROPOSAL: A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, then authors can save and reload multiple sets of these settings. (Level AAA)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: A.3.6.4 Multiple SetsComments on A.3.6.4
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

8. PROPOSAL: A.3.6.5 Assistance with Preferences

A.3.6.5 Assistance with Preferences

Jan's email

PROPOSAL: A.3.6.5 Assistance with Preferences: If the authoring tool includes display and/or control settings, then the authoring tool includes a mechanism to help authors configure these settings. (Level AAA)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: A.3.6.5 Assistance with PreferencesComments on A.3.6.5
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

9. PROPOSAL: A.4.2.2 Document Author-Level Features

Jan's email

PROPOSAL: A.4.2.2 Document Author-Level Features: The authoring tool includes documentation for its author-level user interface features. (Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 6
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 PROPOSAL: A.4.2.2 Document Author-Level FeaturesComments on A.4.2.2
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal Can we define author level?
Sueann Nichols The proposal needs more discussion (see comments field) This is vague? Is this any features or specific to accessibility?

10. PROPOSAL: A.3.2.1 Auto-Save

Jan's email

PROPOSAL: A.3.2.1 Auto-Save (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool can be set to automatically save web content edits made using the authoring tool before session time limits are reached. (Level A)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: A.3.2.1 Auto-SaveComments on A.3.2.1
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

11. PROPOSAL: A.3.2.4 Auto-Save (Extended)

Jan's email

PROPOSAL: A.3.2.4 Auto-Save (Extended): The authoring tool can be set to automatically save web content edits made using the authoring tool. (Level AAA)

Summary

ChoiceAll responders
Results
Accept the proposal 6
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 PROPOSAL: A.3.2.4 Auto-Save (Extended)Comments on A.3.2.4
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Recommend changes (see comments field) To differentiate from AA better, could it say "can be set to automatically save all web content edits"
(Without an 'all' in there, it appears to be the same as AA.)
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

12. PROPOSAL to shorten the way we indicate SC Level depends on WCAG 2.0

Jan's email

PROPOSAL: to pull the text together into a single parenthetical to match the other level indicators:
(Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL to shorten the way we indicate SC Level depends on WCAG 2.0Comments on WCAG 2.0 levels
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

13. PROPOSAL: update definition of accessible templates (WCAG)

Jan's email

accessible templates (WCAG):
Templates that can be filled in to create web content that meets the WCAG 2.0 success criteria (Level A, AA or AAA), when both of the following are true:
(a) The author correctly follows any instructions provided (e.g., correctly responding to prompts, correctly replacing highlighted placeholders); and
(b) No further authoring occurs.

Note: Under these conditions, some templates will result in completely empty documents, which are considered accessible by default.

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 1

Details

Responder PROPOSAL: update definition of accessible templates (WCAG)Comments on Dec "accessible template"
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Neutral - will accept the consensus of the group
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols The proposal needs more discussion (see comments field) Not sure this adequately covers the issue.

14. PROPOSAL: B.2.4.1 Accessible Template Options (WCAG):

Jan's email

PROPOSAL: B.2.4.1 Accessible Template Options (WCAG): If the *authoring tool* provides *templates*, then there are *accessible template (WCAG)* *options* for a *range* of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Note: The accessible options are not necessarily identified.

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 1

Details

Responder PROPOSAL: B.2.4.1 Accessible Template Options (WCAG):Comments on B.2.4.1
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Recommend changes (see comments field) Why the note "not necessarily identified"? Shouldn't it be "recommended that they are identified." with a reference to the SC on identifying template accessibility.
Frederick Boland Accept the proposal
Jutta Treviranus Neutral - will accept the consensus of the group
Sueann Nichols Accept the proposal

15. PROPOSAL: B.2.4.2 Identify Template Accessibility (Minimum)

Jan's email

PROPOSAL: B.2.4.2 Identify Template Accessibility (Minimum): If the *authoring tool* includes a *template selection mechanism* and provides any non-*accessible template (WCAG)* *options*, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)

Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: B.2.4.2 Identify Template Accessibility (Minimum)Comments on B.2.4.2
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

16. PROPOSAL: B.2.4.x Identify Template Accessibility (Enhanced)

Jan's email

PROPOSAL: B.2.4.x Identify Template Accessibility (Enhanced): If the *authoring tool* provides any non-*accessible template (WCAG)* *options* and does not include a *template selection mechanism*, then the non-accessible templates include accessibility warnings within the templates. (Level AAA)

Summary

ChoiceAll responders
Results
Accept the proposal 7
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 PROPOSAL: B.2.4.x Identify Template Accessibility (Enhanced)Comments on B.2.4.x
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

17. PROPOSAL: B.3.1.4 Status Report

Jan's email

PROPOSED RESPONSE: AUWG: The status requirement ("B.3.1.4 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA) Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc. ") is simply that the author receive information about the state of things from the accessibility checker. The note clarifies that the format of the report is not specified.

If the checker hasn't run, there will be nothing to report. Your comment raises email, wikis and dynamic content as issues, which we will address separately:
- in the case of email, an accessibility checker, like a spell checker is something a sender may or may not choose to run. For example, sending a quick personal note to a known recipient requires less vigilance than posting to a publicly-archived forum.
- wikis have the challenge that the wiki system doesn't usually have access to the content until the user submits it (though DHTML implementations change this). However, this need not be a problem since the user can re-edit content if/when content issues are identified by the system (whether they are issues of wiki syntax, spelling or accessibility)
- by "dynamic content" you may be referring to DHTML-type content. This certainly presents challenges to automated checkers, however some progress has been made on checker design in this area and in these cases communication of results back to the author seems to be a reasonable use case.

Summary

ChoiceAll responders
Results
Accept the proposal 5
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 1

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

Details

Responder PROPOSAL: B.3.1.4 Status ReportComments on B.3.1.4
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal This is a comment response, not text for the guidelines.
Sueann Nichols Neutral - will accept the consensus of the group

18. B.3.1.5 Programmatic association of results

Jan's email

B.3.1.5 Programmatic association of results: Authoring tools can programmatically associate accessibility checking results with the web content that was checked. (Level AA)

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

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

Details

Responder B.3.1.5 Programmatic association of resultsComments on B.3.1.5
Jan Richards Accept the proposal
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

19. Proposal on B.4.2.1 Model Practice (WCAG) in ATAG 2.0

Jan's email

Current version: (http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20110613/#gl_b42)

Challenges in setting a testable criterion:

- online documentation can be modified or added-to by developers at any time
- documentation sets may be vast (thousands of pages) or very limited (even one page)
- while the accessibility of documentation can be (to some extent) checked automatically, checking whether documentation correctly models accessible practice must be done manually.
- theoretically, this situation lends itself to a statistical approach (e.g., testing a random set of documents from the documentation), but this is not very practical and inevitably would lead to questions about how the "random" set was selected.

Proposal: Link the term "range" to the new definition, but add context in the "Intent"

B.4.2.1 Model Practice (WCAG): A *range* of examples in the documentation (e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices that meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

DEFINITION:

"Range": More than one item within a multi-item set. (Informative) Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not always be practical (e.g. the set of all help documentation examples, the set of all templates, etc.). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly.

Intent of Success Criterion B.4.2.1:

The intent of this success criterion is to have accessible authoring practices introduced to authors as naturally integrated common practice. The success criterion is also intended to reduce the chance that authors will copy inaccessible authoring practices from examples in the documentation. Essentially, modelling inaccessible authoring practices in the documentation should be viewed in the same way as modelling invalid markup or spelling/grammar errors.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.4.2.1:

- Reference examples are accessible: An HTML authoring tool includes an on-line HTML markup reference guide. Markup examples within the reference guide are all valid code and they all meet the WCAG 2.0 Level A success criteria.

- Screen shots show accessibility features in use: A content management system has a help system that includes screen shots of various aspects of the system's user interface. When screen shots show examples of the user interfaces as content is being produced, the user interface is always shown such that the content produced would meet the WCAG 2.0 Level A success criteria (e.g. prompts filled in, optional accessibility features turned on, etc.).

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

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

Details

Responder Proposal on B.4.2.1 Model Practice (WCAG) in ATAG 2.0Comments on B.4.2.1
Jan Richards Accept the proposal I could also see adding a specific reference to "context sensitive" help to the Implementing ATAG2 info for this SC.
Roberto Scano Accept the proposal
Alastair Campbell Accept the proposal
Jeanne F Spellman
Frederick Boland Accept the proposal
Jutta Treviranus Accept the proposal
Sueann Nichols Accept the proposal

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Cynthia Shelly <cyns@microsoft.com>
  2. Andrew Ronksley <andrew.ronksley@rnib.org.uk>
  3. Alex Li <alli@microsoft.com>
  4. Cherie Ekholm <cheriee@exchange.microsoft.com>
  5. Alessandro Miele <alessandro.miele@standardware.net>
  6. Tom Babinszki <tbabins@us.ibm.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


Completed and maintained by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.124 2014-10-06 13:46:23 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)