W3C WBS Home

Results of Questionnaire AUWG Survey for 3 January

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-01-03 to 2011-01-10.

11 answers have been received.

Jump to results for question:

  1. break-up A.2.1.1 Alternative Content
  2. B.1.1.2 (NEW) Content Auto-Generation During Authoring Sessions (WCAG):
  3. A.2.2.2 Access to Text Presentation (Minimum)
  4. A.2.2.3 Access to Text Presentation (Enhanced)
  5. A.3.5.1 Text Search

1. break-up A.2.1.1 Alternative Content

A.2.1.1 Alternative Content

Proposal how we might break-up A.2.1.1 in a way that is similar to WCAG 2.0's 1.1 (Text Alternatives) and 1.2 (Time-based Media):

Proposal:

A.2.1.1 Text Alternatives for Rendered Non-Text Content: If an *editing-view* *renders* *non-text content* with *programmatically associated* *text alternatives*, then the text alternatives can be *programmatically determined*. (Level A)

A.2.1.X 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: the author has the option to have the content being edited *previewed* in a pre-existing *user agent*.

Ed. Note: WCAG2 does not define time-based media. I've taken a shot but I haven't come up with anything more clear than the term itself

Ed. Note2: The reason for (b) in A.2.1.X is that the alternative might be in a media the authoring tool doesn't ever render. (e.g., an audio editor might not have the capability to render a video alternative)

Summary

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

Details

Responder break-up A.2.1.1 Alternative ContentComments on A.2.1.1 and A.2.1.x
Jan Richards Accept the proposal
Jutta Treviranus Recommend changes (see comments field) The term "pre-existing" user agent seems awkward. It is unlikely that a user agent will be created.
Roberto Scano Accept the proposal
Greg Pisocky Accept the proposal
Frederick Boland Accept the proposal
Sueann Nichols Neutral - will accept the consensus of the group Question on A.2.1.X (b). What is the significance of the preview being in a "pre-exisiting" user agent? Couldn't the preview be supported by the authoring tool? The notion of the pre-existing user agent doesn't seem to be the key point to the issue, but it adds a potential restriction to the support that the preview has to be presented via a pre-existing user agent.
Jeanne F Spellman The proposal needs more discussion (see comments field) A2.1.X already sets the conditional "if an editing view renders", which seem to negate the need for (b). (b) appears to allow a preview to be an acceptable option for not providing captions.
Alex Li Accept the proposal
Andrew Ronksley Accept the proposal
Alastair Campbell Accept the proposal NB: I think (b) is needed because taking another step to open the content in a preview is (or could be) separate from the editing view.
Cherie Ekholm The proposal needs more discussion (see comments field)

2. B.1.1.2 (NEW) Content Auto-Generation During Authoring Sessions (WCAG):

Proposed

B.1.1.2 (NEW) Content Auto-Generation During Authoring Sessions (WCAG): Authors have the default option that, when web content is automatically generated during an authoring session, then one of the following is true:

@@Note 1: Automatic generation includes automatically selecting templates for authors.

Note 2: This success criterion applies only to automatic processes specified by the authoring tool developer. It does not apply when author actions prevent generation of accessible web content.

(a) Accessible: The content is accessible web content (WCAG) without author input; or
(b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or
(c) Checking Active: After the automatic generation process, accessibility checking is active on the output; or
(d) Checking Suggested: Authors have the default option to have accessibility checking suggested. The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).

Summary

ChoiceAll responders
Results
Accept the proposal 8
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 B.1.1.2 (NEW) Content Auto-Generation During Authoring Sessions (WCAG):Comments on B.1.1.2
Jan Richards Accept the proposal
Jutta Treviranus Accept the proposal
Roberto Scano Accept the proposal
Greg Pisocky The proposal needs more discussion (see comments field) then one of the following is true:

Do we mean among a b c and d and to satisfy the requirement it means a OR b OR C or D - any one of these four.
Frederick Boland Accept the proposal
Sueann Nichols Accept the proposal
Jeanne F Spellman Accept the proposal
Alex Li The proposal needs more discussion (see comments field) For option A: Where does level A, AA, AAA come in?
For option B: What is ANY required accessibility information?
For option C: I'm not sure what "active on the output" means.
For option D: What's the difference between option c and d?

Also, I'm wonder about the scope of "web content [that] is automatically generated during an authoring session". Does it include, say shipping order, packing slip, invoice, inventory updae and such for an online purchase? Or are we talking about something more defined? If so, we should define it more tightly.

Pardon me if this is settled: are we scoping authoring tool so that activities such as shopping online, where you have to punch in address and payment info, is considered not an authoring activities? This has been my fundamental concern about ATAG. Whether it was settled would inform the question above.

Shouldn't there be an option E where the content has no accessibility impact, ie info that's hidden from users.
Andrew Ronksley Accept the proposal
Alastair Campbell Accept the proposal
Cherie Ekholm The proposal needs more discussion (see comments field) See comments from Alex Li.

3. A.2.2.2 Access to Text Presentation (Minimum)

Proposed A.2.2.2

Access to Text Presentation (Minimum): If an editing-view renders text content, then any of the following properties that can be communicated by the supported platform accessibility service(s) can be programmatically determined: (Level A)
(a) Font; and
(b) Font Style; and
(c) Font Variant; and
(d) Front Weight;
(e) Font Size; and
(f) Font Color; and
(g) Background Color

Summary

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

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

Details

Responder A.2.2.2 Access to Text Presentation (Minimum)Comments on A.2.2.2
Jan Richards Accept the proposal
Jutta Treviranus Accept the proposal
Roberto Scano Accept the proposal
Greg Pisocky The proposal needs more discussion (see comments field) How do you see this working. If you mean that if the editing view offers a dialog for adding or modifying these text attributes then that dialog should be accessible and only for those attributes that the authoring tool allows to be modified then I would agree.
Frederick Boland The proposal needs more discussion (see comments field)
Sueann Nichols Recommend changes (see comments field) Doesn't the fact that the criteria states the properties and be programmatically determined automatically imply the services are supported by the platform? And if that is true, can't the requirement be simplified to state "then any of the following properties can be programmatically determined:"
Jeanne F Spellman Accept the proposal typo in (d) Front weight
Alex Li
Andrew Ronksley Accept the proposal
Alastair Campbell Accept the proposal Not sure it needs the extra " that can be communicated by the supported platform accessibility service(s)", but there must have been a reason for adding it?
Cherie Ekholm Accept the proposal

4. A.2.2.3 Access to Text Presentation (Enhanced)

Proposed A.2.2.3

If an editing-view renders text content, then all editable properties that can be communicated by the supported platform accessibility service(s) can be programmatically determined. (Level AAA)

Summary

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

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

Details

Responder A.2.2.3 Access to Text Presentation (Enhanced)Comments on A.2.2.3
Jan Richards Accept the proposal
Jutta Treviranus Accept the proposal
Roberto Scano Accept the proposal
Greg Pisocky The proposal needs more discussion (see comments field) This would make a better A.2.2.2 and then we wouldn't need this A.2.2.3 because we are essentially saying all editable properties that can be communicated should be.
Frederick Boland The proposal needs more discussion (see comments field)
Sueann Nichols Recommend changes (see comments field) I would recommend this be stronger. "then all editable properties communicated by the supported..."
Jeanne F Spellman Accept the proposal
Alex Li
Andrew Ronksley Accept the proposal
Alastair Campbell Accept the proposal (As per Question 3.)
Cherie Ekholm Accept the proposal

5. A.3.5.1 Text Search

Proposed A.3.5.1 Text Search

add option (d):

(d) No Match: Authors are informed when no results are found.

Link to A.3.5.1 in the latest draft

Summary

ChoiceAll responders
Results
Accept the proposal 11
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.3.5.1 Text SearchComments on A.3.5.1
Jan Richards Accept the proposal
Jutta Treviranus Accept the proposal
Roberto Scano Accept the proposal
Greg Pisocky Accept the proposal
Frederick Boland Accept the proposal
Sueann Nichols Accept the proposal
Jeanne F Spellman Accept the proposal
Alex Li Accept the proposal
Andrew Ronksley Accept the proposal
Alastair Campbell Accept the proposal
Cherie Ekholm Accept the proposal

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Cynthia Shelly <cyns@microsoft.com>
  2. Alessandro Miele <alessandro.miele@standardware.net>
  3. 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)