W3C WBS Home

Results of Questionnaire AUWG Survey for 3 October 2011

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-09-30 to 2011-10-11.

7 answers have been received.

Jump to results for question:

  1. A.2.1.2 "Alternatives for Rendered Time-Based Media", rewording of "(a) Option to Render"
  2. In "A.3.1.2 No Keyboard Traps", replacing "known" by "documented".
  3. In "A.4.1.2 Setting Changes Reversible", simplifying the wording and removing the save option.
  4. In applicability note: B.3 "Applicability after the end of an authoring session" replacing "has specified" with "causes"
  5. New rationale for B.4.2
  6. In the definition of authoring tool, replacing "software" with "application"
  7. Modified definition of "prompt":
  8. A.3.6.5 Assistance with Preferences

1. A.2.1.2 "Alternatives for Rendered Time-Based Media", rewording of "(a) Option to Render"

A.2.1.2 in latest draft | Chart of Comments

EXISTING
A.2.1.2 Alternatives for Rendered Time-Based Media:
If an editing-view renders time-based media, then at least one of the following is true: (Level A)
(a) Alternatives Rendered: Alternatives for the time-based content are also rendered; or
(b) User Agent Option: Authors have the option to preview the time-based content in a user agent that is able to render the alternatives.

Proposed:
(a)Option to Render: The authoring tool provides the option to render alternatives for the time-based content; or

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 A.2.1.2 "Alternatives for Rendered Time-Based Media", rewording of "(a) Option to Render"Comments on A.2.1.2
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li Accept the proposal
Alastair Campbell Accept the proposal
Sueann Nichols Accept the proposal

2. In "A.3.1.2 No Keyboard Traps", replacing "known" by "documented".

A.3.1.2 in latest draft | Chart of Comments

EXISTING
A.3.1.2 No Keyboard Traps: Keyboard traps are prevented as follows: (Level A)
(a) In the Authoring Tool User Interface: If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away; and
(b) In Editing-Views that Render Content: If an editing-view renders content (e.g., WYSIWYG view), then a documented keyboard command is provided that moves the editing-view keyboard focus to a known location (e.g., the start of the editing-view).

Proposed:
(b) In Editing-Views that Render Content: If an editing-view renders content (e.g., WYSIWYG view), then a documented keyboard command is provided that moves the editing-view keyboard focus to a documented location (e.g., the start of the editing-view).

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 1
Neutral - will accept the consensus of the group

Details

Responder In "A.3.1.2 No Keyboard Traps", replacing "known" by "documented".Comments on A.3.1.2
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li Accept the proposal
Alastair Campbell Accept the proposal
Sueann Nichols Disagree with the proposal As a level A requirement the proposal is too prescriptive. Should just ensure the correct result is achieved without indicating how it is accomplished.

3. In "A.4.1.2 Setting Changes Reversible", simplifying the wording and removing the save option.

A.4.1.2 in latest draft | Chart of Comments

EXISTING
A.4.1.2 Setting Changes Reversible:
If actions modify authoring tool settings, then one of the following is true: (Level A)
(a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or
(b) Warn and Confirm: The authoring tool provides a warning to authors that the setting change is irreversible and requires authors to confirm or save the current settings before proceeding.

Proposed:
If an authoring tool setting change is not reversible, then the authoring tool requires author confirmation to proceed.

Reference to Original Comment

Summary

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

Details

Responder In "A.4.1.2 Setting Changes Reversible", simplifying the wording and removing the save option.Comments on A.4.1.2 to IBM24
Jeanne F Spellman Recommend changes (see comments field) If a change to an authoring tool setting is not reversible....

I think this is easier to parse.
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li Accept the proposal
Alastair Campbell Recommend changes (see comments field) I agree with the change, it is much simpler. However, it looks like the title should change to match? How about "A.4.1.2 Settings change confirmation".
Sueann Nichols Accept the proposal seem like an improvement

4. In applicability note: B.3 "Applicability after the end of an authoring session" replacing "has specified" with "causes"

B.3 note in latest draft | Chart of Comments

EXISTING
3. Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author has specified, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed).

Proposed:
3. Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author causes, whether it is author-generated or automatically-generated by another system that the author has specified (e.g., a third-party feed).

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 In applicability note: B.3 "Applicability after the end of an authoring session" replacing "has specified" with "causes"Comments on App Note B.3
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li Neutral - will accept the consensus of the group Note that Microsoft has issue with the example. But changing from specified to causes does not affect our input.
Alastair Campbell Accept the proposal
Sueann Nichols Accept the proposal

5. New rationale for B.4.2

B.4.2 in latest draft | Chart of Comments

EXISTING
Guideline B.4.2: Ensure that documentation promotes the production of accessible content.

Rationale: Without documentation of the features that support the production of accessible content (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be able to use them. Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.

Proposed:
Rationale: Some authors need support in determining how to use accessible content production features (e.g. how to respond to prompts for text alternatives, how to use the accessibility checking tool). Demonstrating accessible authoring as routine practice or at least not demonstrating inaccessible practices will help to encourage acceptance of accessibility by some authors.

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 2

Details

Responder New rationale for B.4.2Comments on B.4.2
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li Neutral - will accept the consensus of the group
Alastair Campbell Accept the proposal
Sueann Nichols Neutral - will accept the consensus of the group

6. In the definition of authoring tool, replacing "software" with "application"

Authoring Tool Definition in latest draft | Chart of Comments

EXISTING
Any software (or collection of software components) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users).

Note 1: "collection of software components": Multiple applications, plug-ins, etc. can be used together to meet ATAG 2.0 (see also note in the "Required Components of an ATAG 2.0 Conformance Claim").

Proposed:
Any web-based or non-web-based application(s) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users). Note 1: "application(s)": ATAG 2.0 may be conformed to by stand-alone applications or by collections of applications. If a conformance claim is made, then the claim must provide identifying information for each application and also for any required extensions, plug-ins, 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

Details

Responder In the definition of authoring tool, replacing "software" with "application"Comments on definition of Authoring Tool
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li Neutral - will accept the consensus of the group Note that Microsoft has issue with the definition. But changing from software to application does not affect our input.
Alastair Campbell Accept the proposal
Sueann Nichols Accept the proposal

7. Modified definition of "prompt":

Definition of "prompt" in latest draft | Chart of Comments

EXISTING
prompt
Any authoring tool initiated request for a decision or piece of information from authors. Well designed prompting will urge, suggest, and encourage authors.

Proposed:
prompt
Any authoring tool initiated request for a decision or piece of information from authors. The term covers requests that must be responded to immediately (e.g. modal dialog boxes) as well as less urgent requests (e.g. underlining a misspelled word).

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 Modified definition of "prompt":Comments on definition of Prompt
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li Neutral - will accept the consensus of the group
Alastair Campbell Accept the proposal
Sueann Nichols Accept the proposal

8. A.3.6.5 Assistance with Preferences

A.3.6.5 in latest draft | Chart of Comments

Proposed:
Intent of Success Criterion A.3.6.5:
The intent of this success criterion is to ensure that authoring tools provide some assistance to authors in configuring options related to the accessibility of the user interface. This assistance may include assistance on when and how to use each setting and might also include help with detecting and resolving conflicts between option settings.

Examples of Success Criterion A.3.6.5:

- Documented Settings: An authoring tool includes a Display Settings feature that allows authors to set the size, text color and background color of the authoring tool's source editing view. A help link in the Display Options area explains how each setting will affect the appearance of the editing view.

- Settings Preview: An authoring tool's Display Settings feature includes a preview of how the display settings will change the appearance of the editing view when applied

- Contrast Conflict Management: An authoring tool's Display Settings feature prevent the author from setting a foreground and background color combination that is below a minimum contrast threshold

- Keystroke Conflict Management: An authoring tool includes a Keystroke Manager that allows the authoring tool's user interface shortcuts to be remapped. One feature of the Manager is that it prevents authors from assigning the same shortcut to more than one action.

- EXISTING Options setting wizard: An authoring tool includes a wizard that takes authors step-by-step through the accessibility options, providing explanations and previews of how the options will change the display. The wizard follows an interview format, first asking authors about general areas (e.g., seeing the screen, using the keyboard) and then becoming more detailed (e.g., text size, text color).

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.6.5 Assistance with PreferencesComments on A.3.6.5
Jeanne F Spellman Accept the proposal
Frederick Boland Accept the proposal
Alessandro Miele Accept the proposal
Jan Richards Accept the proposal
Alex Li The proposal needs more discussion (see comments field) I'm confused. The comment chart propsed to remove the SC, but we have a rewording here. I need some context.
Alastair Campbell Accept the proposal
Sueann Nichols Neutral - will accept the consensus of the group

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Jutta Treviranus <jtreviranus@faculty.ocadu.ca>
  2. Cynthia Shelly <cyns@microsoft.com>
  3. Roberto Scano <w3c-rep@iwanet.org>
  4. Andrew Ronksley <andrew.ronksley@rnib.org.uk>
  5. Cherie Ekholm <cheriee@exchange.microsoft.com>
  6. Alexandre Morgaut <alexandre.morgaut@4d.com>
  7. Jean-Bernard Piot <jean-bernard.piot@4d.com>
  8. 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.123 2013-09-26 09:46:56 dom Exp $. Please send bug reports and request for enhancements to dom@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)