W3C

Site Navigation

Nearby

Results of Questionnaire UAWG Survey for 4 July 2013 (no meeting)

The results of this questionnaire are available to anybody.

This questionnaire was open from 2013-07-02 to 2013-07-26.

7 answers have been received.

Jump to results for question:

  1. Introduction
  2. JR1 on 1.1.1
  3. JR51 on 1.5.1
  4. JR9 on 1.8.1
  5. JR10 on 1.8.3
  6. JR11 on 1.8.6
  7. JR13 on 1.8.12
  8. JR17 on 2.2.4
  9. JR20 on 2.3.3
  10. JR29 on 2.7.4
  11. JR36 on 2.11.4
  12. JR40 on 3.1.1
  13. JR44 on 4.1.2
  14. JR47 on 5.1.1
  15. JR49 on 5.1.4

1. Introduction

This survey comes from the comment responses spreadsheet that Jim created to allow us to strategically and efficiently address the comments we received on the 23 May 2013 working draft.

Jim organized the comments into the appropriate success criteria or guidelines, and then Jim and Jeanne sorted the comments into categories: editorial, ready for survey, and needs proposal. Kim and Jeanne will integrate the editorial comments. This survey is the first pass of comment suggestions that were simple enough to put directly into a survey. There are 16 comments in this survey.

In addition to completing this survey, please look at the comment responses spreadsheet and search for the comments that "[need proposal]" and start drafting language that we can put into a future survey.

Figuring out a way to efficiently handle our comments will be very helpful in expediting our Last Call comments. Your suggestions on ways to further expedite this procedure will be welcome.

Details

Responder Introduction comments
Jeanne F Spellman
Jan Richards
Kimberly Patch
Simon Harper
Jim Allan
Greg Lowney
Eric Hansen

2. JR1 on 1.1.1

Comment

Is the phrase "For any content element " necessary? ...BTW: did the group ever look at this proposal (of mine)?: http://lists.w3.org/Archives/Public/w3c-wai-ua/2011AprJun/0086.html

Existing

1.1.1 Render Alternative Content: For any content element, the user can choose to render any types of recognized alternative content that are present. (Level A)

Note: It is recommended that the user agent allow the user to choose whether the alternative content replaces or supplements the original content element.

Proposed

1.1.1 Default Rendering of Alternative Content (Minimum): For each type of non-text content, the user can specify a type of alternative content that, if present, will be rendered by default. (Level A)

Summary

ChoiceAll responders
Results
Agree with the proposal 4
Disagree with the proposal 1
Neutral, will accept consensus of the group 2
Suggest the following changes to the proposal

Details

Responder JR1 on 1.1.1JR1 on 1.1.1
Jeanne F Spellman Agree with the proposal
Jan Richards Neutral, will accept consensus of the group The proposal covers GL1.1 as a whole.
Kimberly Patch Neutral, will accept consensus of the group
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal
Greg Lowney Disagree with the proposal Here are comments on each of the five paragraphs in Jan's proposal:

> 1.1.1 Default Rendering of Alternative Content (Minimum): For each type of non-text content, the user can specify a type of alternative content that, if present, will be rendered by default,. (Level A)

GCL: Rather than “each type of non-text content”, it should be “each type of content that can can have alternative content”. For example, it should cover replacing abbreviations with their expansions.

> Note: Alternative content may be rendered together with the original non-text content (e.g., turning video caption track on) or may replace the original content (e.g., video with extended audio description replacing original video).

GCL: I don’t agree with removing the recommendation that the user be allowed to choose the behavior.

> 1.1.2 Indicate Unrendered Alternative Content: The user can specify that indicators be displayed when unrendered alternative content is present for rendered content. (Level A)

GCL: As usual, I would prefer to require that indicators be displayed “with” or the content that has unrendered alternative content, because I don’t consider it sufficient to have a flag that just tells the user there’s at least one element with alternative content somewhere in this document, or to go further and bury that information in a dialog box.

GCL: Would you then remove this from 1.3.1 (Highlight Items)?

> 1.1.3 Render Alternative Content: The user can choose to render any types of alternative content that are present. (Level A)

GCL: This seems to be replacing the old 1.1.1, which was specifically one a single element, but the proposed wording is unclear about whether it’s talking about applying this to a single element or all elements of a given class. Also, we might want to tighten up both wording to specifically require presenting at least one type of alternative content at a time, to avoid the interpretation that it’s required that the user be able to choose “any (set of) types” to display at once. If you don’t want “For any content element” at the beginning, how about something like “The user can choose to render any type of alternative content that are present for a content element.”

GCL: In this SC, the term “content element” should link to a definition that explicitly refers to a single element in the document, not to a *type* of element; the current definition of “element” explicitly says it can mean either one, which makes it inappropriate for this SC.

> 1.1.4 Default Rendering of Alternative Content (Enhanced): For each type of non-text content, the user can specify the cascade in which to render different types of alternative content, in case preferred types are not present. (Level AA)

GCL: Rather than “each type of non-text content”, it should be “each type of content that can can have alternative content”. For example, it should cover replacing abbreviations with their expansions.
Eric Hansen Agree with the proposal The proposal is a considerable improvement. I would like to see, though, the taxonomy of non-text content types and alternative content types.

3. JR51 on 1.5.1

Comment

JR51: Seems like a lot for A. Maybe AA.

Existing

The user can adjust the volume of each audio track independently of other tracks, relative to the global volume level set through operating environment mechanisms. (Level A)

Proposed

Level AA

Summary

ChoiceAll responders
Results
Agree with the proposal 5
Disagree with the proposal
Neutral, will accept consensus of the group 1
Suggest the following changes to the proposal 1

Details

Responder JR51 on 1.5.1JR51 on 1.5.1
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Neutral, will accept consensus of the group
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal
Greg Lowney Suggest the following changes to the proposal It looks like this guideline went through a lot of changes over time, and some were confused. Originally "Global Volume" was about respecting operating environment mechanisms, and there was also an SC about separate volume controls for recognized speech and non-speech tracks. I assume we removed the former because we’re willing to assume assumed that any well-behaved user agent will be forced to respect platform volume settings. Now we have just one SC with the same old title but new content, which don’t match. I think it’s fine to reduce the priority of the current 1.5.1, but the title should be changed to something more appropriate such as "Volume of individual tracks" or "Track volume." Because we’d no longer have any Level A SC about adjusting volume, I also suggest renaming it to 1.5.2 and inserting a new SC, "1.5.1 Volume Control: The user can adjust the volume of all audio played, relative to the global volume level set through *operating environment* mechanisms. (Level A)" I think it’s quite reasonable for any media player to provide at minimum one volume control for the media it’s playing, and so widely implemented as to be expected by users, and entirely necessary for users who need to adjust their media volume without affecting the volume of their synthesized speech, etc.
Eric Hansen Agree with the proposal

4. JR9 on 1.8.1

Comment

Maybe highlighting customization part should be AA?

Existing

1.8.1 Highlight Viewport: The viewport with the input focus is highlighted and the user can customize attributes of the highlighting mechanism (e.g. shape, size, stroke width, color, blink rate). The viewport can include nested viewports and containers. (Level A)

Proposed

1.8.1 Highlight Viewport: The viewport with the input focus is highlighted. The viewport can include nested viewports and containers. (Level A)

1.8.x Customize Viewport Highlighting: The user can customize attributes of the highlighting mechanism (e.g. shape, size, stroke width, color, blink rate). (Level AA)

Summary

ChoiceAll responders
Results
Agree with the proposal 4
Disagree with the proposal
Neutral, will accept consensus of the group 2
Suggest the following changes to the proposal 1

Details

Responder JR9 on 1.8.1JR9 on 1.8.1
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Neutral, will accept consensus of the group
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal 1.8.x don't know of a UA that allows customization. May be in CSS? good to separate it.
Greg Lowney Neutral, will accept consensus of the group It is sad and disappointing if 1.8.1 is important enough to require at Level A, but still okay for it to be invisible to many people. There are products that highlight frames with a thin, dotted rectangle which is difficult for people with average vision to detect, and extremely difficult for people with even moderately impaired vision. I can understand if it’s considered too much work for too many products to require this to be customized, but it will definitely make this far less beneficial.
Eric Hansen Suggest the following changes to the proposal Agree except that I suggest deleting the phrase "The viewport can include nested viewports and containers." It is not a requirement and therefore does not belong in an SC statement.

5. JR10 on 1.8.3

Comment

JR10: Maybe AA? I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport?

Existing

1.8.3 Resize Viewport: The user can resize viewports within the limits of the display, overriding any values specified by the author. (Level A)

Proposed

1.8.3 Resize Viewport: The user can resize top level viewports within the limits of the display, overriding any values specified by the author. (Level AA)

Summary

ChoiceAll responders
Results
Agree with the proposal 4
Disagree with the proposal 2
Neutral, will accept consensus of the group
Suggest the following changes to the proposal 1

Details

Responder JR10 on 1.8.3 JR10 on 1.8.3
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Disagree with the proposal
Simon Harper Agree with the proposal
Jim Allan Suggest the following changes to the proposal AA is ok. think this should not only be top level. If viewport (video, or iframe, etc.) is inside a top-level viewport it should be resizeable to size of containing viewport. everything else should reflow.

keep the original wording (we have vetted it numerous times) and make it AA.
this morphed from 4.9.9 (http://www.w3.org/TR/2010/WD-UAAG20-20100617/)
Greg Lowney Disagree with the proposal The intent was not just for top-level viewports. For example, some browsers allow the user to resize text input boxes but that can be overridden in CSS by authors using resize:none. Similarly, many pages use iframe to create a separate viewport for the navigation links on the right-hand side, and this may be too narrow if the user enlarges the text.
Eric Hansen Agree with the proposal

6. JR11 on 1.8.6

Comment

JR11: I'm concerned this might be read that each viewport needs to be configurable separately? Should it say top-level viewport?

Existing

1.8.6: Zoom: The user can rescale content within graphical viewports as follows: (Level A)
Zoom in: to 500% or more of the default size; and
Zoom out: to 10% or less of the default size, so the content fits within the height or width of the viewport.

Proposed

1.8.6: Zoom: The user can rescale content within top level graphical viewports as follows: (Level A)
Zoom in: to 500% or more of the default size; and
Zoom out: to 10% or less of the default size, so the content fits within the height or width of the viewport. (Level AA)

Summary

ChoiceAll responders
Results
Agree with the proposal 4
Disagree with the proposal 1
Neutral, will accept consensus of the group
Suggest the following changes to the proposal 2

Details

Responder JR11 on 1.8.6JR11 on 1.8.6
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Disagree with the proposal
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal current UA scale all content (including embedded viewports [iframe]).
it would be nice if you could only scale content in a given viewport, but not critical.
Greg Lowney Suggest the following changes to the proposal Agreed. It would be more useful if each viewport had independent control, but that is asking too much. (I hope there will not be any confusion--real or feigned--over whether content within nested viewports is considered to be "within [the] top level viewports".)

Is "the viewport" appropriate when the first line explicitly refers to "top level viewports" but the third line could be referring to a nested viewport? Should it instead say "so that content fits within the height or width of *its* viewport"?

However, there is a problem with the "Zoom out" portion. It consists of two clauses that could conflict, and it's not clear how such conflicts would be resolved. For example, what if reducing to 10% is not enough to let the content fit within the height or width of the viewport,then what? Is it saying that zoom has to go to 10% or the amount necessary to make the content fit, whichever size is smaller? Perhaps rephrase as "Zoom out: to 10% or less of the default size, or enough to let the content fit within the height or width of its viewport, whichever size is smaller."

Eric Hansen Suggest the following changes to the proposal Change seems reasonable. However:
Can we clarify the meaning of top-level viewport?
Also, for zoom out should it read:
"Zoom out: (a) to 10% or less of the default size AND (b)so the content fits within the height AND width of the viewport. (Level AA) "

7. JR13 on 1.8.12

Comment

JR13: usual wording is specify rather than "request". BTW all of the "specifies" make it sound like a lot of settings are required....could some be rewritten in the form: "When reflowable content in a graphical viewport is rescaled, it can be reflowed so that one dimension of the content fits within the height or width of the viewport."

Existing

1.8.12 Reflowing Zoom: The user can request that when reflowable content in a graphical viewport is rescaled, it is reflowed so that one dimension of the content fits within the height or width of the viewport. (Level AA)

Note: User agents are encouraged to allow users to override author instructions not to wrap content (e.g., nowrap).

Proposed

1.8.12 Reflowing Zoom: When reflowable content in a graphical viewport is rescaled, it can be reflowed so that one dimension of the content fits within the height or width of the viewport. (Level A)

Note: User agents are encouraged to allow users to override author instructions not to wrap content (e.g., nowrap).

Summary

ChoiceAll responders
Results
Agree with the proposal 4
Disagree with the proposal 2
Neutral, will accept consensus of the group 1
Suggest the following changes to the proposal

Details

Responder JR13 on 1.8.12JR13 on 1.8.12
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Agree with the proposal
Simon Harper Agree with the proposal
Jim Allan Neutral, will accept consensus of the group
Greg Lowney Disagree with the proposal What does "when it can be reflowed" mean? It would be extremely inconvenient if such reflowing could not be made automatic (e.g. if the user had to perform an explicit action on each element they want to reflow, or on each page after it is rendered). Other wording might be more acceptable.

My personal preference would also be to remove the Note, so that user agents would be required to allow overriding of nowrap and equivalent.
Eric Hansen Disagree with the proposal In general, I really like the direction of the changes.
However, I don't understand the meaning of:
"one dimension of the content fits within the height or width of the viewport. (Level A)"
Do we want require that all content fit within the viewport, then why not say:
"the content fits within the height and width of the viewport. (Level A)"

8. JR17 on 2.2.4

Comment

JR17: Should this be AA? Also, wording feels odd (allow it to be turned off, alert when it is done).

Existing

2.2.4 Options for Wrapping in Navigation: The user can prevent sequential navigation from wrapping the focus at the beginning or end of a document, and can request notification when such wrapping occurs. (Level AA)

Proposed

Level AA. Wording suggestions are welcome in comments field.

Summary

ChoiceAll responders
Results
Agree with the proposal 2
Disagree with the proposal
Neutral, will accept consensus of the group 1
Suggest the following changes to the proposal 3

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

Details

Responder JR17 on 2.2.4JR17 on 2.2.4
Jeanne F Spellman Agree with the proposal
Jan Richards Suggest the following changes to the proposal Wrapping benefits some groups...so maybe a wrapping and no-wrap options should both be required. e.g.
2.2.4 Sequential Navigation Wrap/No-Wrap: The user can specify whether or not sequential navigation wraps when focus reaches the beginning and end of the content. (Level AA)
Kimberly Patch Suggest the following changes to the proposal When using sequential navigation, the user can prevent wrapping at the beginning or end of a document and can be alerted when wrapping occurs. (Level AA)
Simon Harper Agree with the proposal
Jim Allan
Greg Lowney Suggest the following changes to the proposal Would it read more easily if reversed, as in "The user can request notification when sequential navigation wraps at the beginning or end of a document, and can prevent such wrapping."?

Personally I’d prefer this and the equivalent for searching to be Level A, and strengthen them by requiring active, rather than passive notification. By that I mean putting a subtle cue in the status bar should not be considered sufficient notification. If you look at the fervent requests online for this feature you’ll see how passionately some users feel about the difficulty they experience because of its lack (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=279014, which is also noteworthy for demonstrating the incredibly self-centered attitude of some developers who feel that a behavior--in this case passive notification--is good enough for them, if someone else can’t get used to it it’s their own fault). Note that we have at least two implementations: Microsoft Word and Firefox with the Find Toolbar With Alert Box extension (https://addons.mozilla.org/en-US/firefox/addon/find-toolbar-with-alert-box). This would conflict with the current definition of "notify", so I’d suggest rewording as "The user can request *active notification* when sequential navigation wraps at the beginning or end of a document, and can prevent such wrapping.", along with the definition of "active notification" as something like "notify, active notification, passive notification: To make the user aware of events or status changes. Notifications can occur within the user agent user interface (e.g. a status bar) or within the content display. Notifications may be passive, not requiring user acknowledgment, or they may be *active*, presented in the form of a prompt requesting a user response (e.g. a confirmation dialog)." We should also include an exemption for controls that follow the user interface standards of the platform (e.g. navigation in menus).
Eric Hansen Neutral, will accept consensus of the group I don't think that I understand the problem well enough to comment.

9. JR20 on 2.3.3

Comment

JR20: Perhaps AA?

Existing

2.3.3 Direct activation of Enabled Elements: The user can move directly to and activate any enabled element in rendered content. (Level A)

Proposed

Level AA

Summary

ChoiceAll responders
Results
Agree with the proposal 2
Disagree with the proposal 3
Neutral, will accept consensus of the group
Suggest the following changes to the proposal 2

Details

Responder JR20 on 2.3.3JR20 on 2.3.3
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal And should it be "operable elements"?
Kimberly Patch Disagree with the proposal
Simon Harper Disagree with the proposal This seems pretty critical to me and I'd support leaving it at A
Jim Allan Disagree with the proposal for speech and keyboard only users this is critical. keep att A
Greg Lowney Suggest the following changes to the proposal Neutral.

However, I think in the past I’ve mentioned that I’d prefer to scope this to acknowledge that it’s not always possible. For example, every UA would fail if given a page with 700 links, so we could acknowledge that with something like ", within the limitation imposed by the input methods (e.g. number of letter and number keys on the keyboard)".
Eric Hansen Suggest the following changes to the proposal When you refer to "move" do you mean "move the focus". Or is the difference. Otherwise I think I can accept the consensus of the group.

10. JR29 on 2.7.4

Comment

JR29: AAA perhaps?

Existing

2.7.4 Change preference settings outside the user interface: The user can adjust any preference settings required to meet the User Agent Accessibility Guidelines (UAAG) 2.0 from outside the user agent user interface. (Level AA)

Proposed

Level AAA

Summary

ChoiceAll responders
Results
Agree with the proposal 5
Disagree with the proposal 1
Neutral, will accept consensus of the group 1
Suggest the following changes to the proposal

Details

Responder JR29 on 2.7.4JR29 on 2.7.4
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Neutral, will accept consensus of the group Is this really that hard to do? One way to do this would be to allow a user to save and share settings, which is another thing we want to encourage.
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal don't know of any UA that does this (easily?). there are editable file for chrome and ff that can be edited with text editor outside of browser. very geeky and you MUST know what you are doing or can break the browser.
Greg Lowney Disagree with the proposal I’d prefer to leave it AA; I think the Intent and Examples give compelling cases and a wide range of possible implementation techniques. However, I acknowledge that extra tools (e.g. batch files or Windows registry files) would make it more usable by non-experts, but at least those are supported because of this feature.
Eric Hansen Agree with the proposal

11. JR36 on 2.11.4

Comment

JR36: Could this be AA?

Existing

2.11.4 Playback Rate Adjustment for Prerecorded Content: The user can adjust the playback rate of prerecorded time-based media content, such that all of the following are true: (Level A)
a. The user can adjust the playback rate of the time-based media tracks to between 50% and 250% of real time.
b. Speech whose playback rate has been adjusted by the user.
maintains pitch in order to limit degradation of the speech quality. c. Audio and video tracks remain synchronized across this required range of playback rates.
d. The user agent provides a function that resets the playback rate to normal (100%).

Proposed

Level AA

Summary

ChoiceAll responders
Results
Agree with the proposal 5
Disagree with the proposal 1
Neutral, will accept consensus of the group 1
Suggest the following changes to the proposal

Details

Responder JR36 on 2.11.4JR36 on 2.11.4
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Disagree with the proposal
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal
Greg Lowney Neutral, will accept consensus of the group
Eric Hansen Agree with the proposal

12. JR40 on 3.1.1

Comment

JR40: Maybe remove "and rendered content". Only mechanism for this in content would seem to be politeness level and implementing that is should following the content spec.

Existing

3.1.1 Reduce Interruptions: The user can avoid or defer recognized non-essential or low priority messages and updating/changing information in the user agent user interface and rendered content.(Level AA)

Proposed

3.1.1 Reduce Interruptions: The user can avoid or defer recognized non-essential or low priority messages and updating/changing information in the user agent user interface.(Level AA)

Summary

ChoiceAll responders
Results
Agree with the proposal 5
Disagree with the proposal
Neutral, will accept consensus of the group 1
Suggest the following changes to the proposal 1

Details

Responder JR40 on 3.1.1JR40 on 3.1.1
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Agree with the proposal
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal
Greg Lowney Neutral, will accept consensus of the group Unsure at this point. I'd like to be sure there are not other good examples of problems.
Eric Hansen Suggest the following changes to the proposal 3.1.1 Reduce Interruptions: The user can avoid or defer recognized non-essential information in the user agent user interface.(Level AA)

13. JR44 on 4.1.2

Comment

JR44: Isn't this (4.1.2) implementation detail for 4.1.1?

Existing

4.1.1 Platform Accessibility Services: The user agent supports relevant platform accessibility services. (Level A)

4.1.2 Name, Role, State, Value, Description: For all user interface components including user interface , rendered content , generated content, and alternative content, the user agent makes available the name, role, state, value, and description via platform accessibility services. (Level A)

Proposed

Remove 4.1.2, merging the IER with 4.1.1

Summary

ChoiceAll responders
Results
Agree with the proposal
Disagree with the proposal 1
Neutral, will accept consensus of the group 5
Suggest the following changes to the proposal 1

Details

Responder JR44 on 4.1.2JR44 on 4.1.2
Jeanne F Spellman Neutral, will accept consensus of the group
Jan Richards Neutral, will accept consensus of the group
Kimberly Patch Neutral, will accept consensus of the group
Simon Harper Disagree with the proposal These items (name, role, state, value) might not be passed to the platform accessibility services. 4.1.2 just specifies the minimal set for 4.1.1 - also 'relevant' seems ambiguous.
Jim Allan Suggest the following changes to the proposal 4.1.1 Platform Accessibility Services: For all user interface components including user interface , rendered content , generated content, and alternative content, the user agent makes available, at a minimum, the name, role, state, value, and description via platform accessibility services. (Level A)

added 'at a minimum' just to cover anything else. Used 4.1.1 short name, and 4.1.2 wording.

Greg Lowney Neutral, will accept consensus of the group Neutral. While the specific requirements of 4.1.2 cannot simply be deleted or assumed, I *think* they could be merged into 4.1.1. However, I’m not satisfied with any of the wordings thus far proposed. I think this needs more work.
Eric Hansen Neutral, will accept consensus of the group

14. JR47 on 5.1.1

Comment

JR47: Might want to remove Level AAA since it will be hard to find implementations.

Existing

5.1.1 WCAG Compliant: Web-based user agent user interfaces 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. (Level AAA)

Proposed

5.1.1 WCAG Compliant: Web-based user agent user interfaces meet the WCAG 2.0 success criteria: Level A to meet WCAG 2.0 Level A success criteria; and Level AA to meet WCAG 2.0 Level A and AA success criteria. (Level A - AA)

Summary

ChoiceAll responders
Results
Agree with the proposal 3
Disagree with the proposal 1
Neutral, will accept consensus of the group 2
Suggest the following changes to the proposal 1

Details

Responder JR47 on 5.1.1JR47 on 5.1.1
Jeanne F Spellman Agree with the proposal
Jan Richards Agree with the proposal
Kimberly Patch Neutral, will accept consensus of the group
Simon Harper Disagree with the proposal Disagree with this whole scale! What about guidelines which are not WCAG - means you can't get conformance if not WCAG - so what about 508 - or European Guidelines? Further, what happens when WCAG 2.0 is superseded - no UAAG conforming browser will ever support the most current WCAG.
Jim Allan Neutral, will accept consensus of the group
Greg Lowney Suggest the following changes to the proposal Neutral on the proposed change.

However, while (Level AAA) was just wrong, saying (Level A - AA) or (Level A - AAA) is also problematic. It could break attempts to convert the guidelines into other formats or import them into databases, and will certainly complicate any attempt to sort or filter SC in other views. I don't believe there were any SC in the equivalent ISO or ANSI standards that didn't have one of the three standard priority levels. Thus I’d much prefer going back to separate SC for this.
Eric Hansen Agree with the proposal

15. JR49 on 5.1.4

Comment

JR49: Is this an accessibility issue?

Existing

5.1.4 Handle Unrendered Technologies: If the user agent does not render a technology, the user can choose a way to handle content in that technology (e.g. by launching another application or by saving it to disk). (Level A)

Proposed

Remove 5.1.4

Summary

ChoiceAll responders
Results
Agree with the proposal 3
Disagree with the proposal
Neutral, will accept consensus of the group 2
Suggest the following changes to the proposal 2

Details

Responder JR49 on 5.1.4JR49 on 5.1.4
Jeanne F Spellman Agree with the proposal It may also be difficult to find implementations of a user agent that can have a mechanism to handle ALL content type possibilities.
Jan Richards Neutral, will accept consensus of the group
Kimberly Patch Neutral, will accept consensus of the group
Simon Harper Agree with the proposal
Jim Allan Agree with the proposal
Greg Lowney Suggest the following changes to the proposal Neutral.

However, it seems like the real accessibility issue would be providing an option to specify non-default handling of technologies that the user agent *does* support, rather than those it does not support. For example, if a browser can render PDF files but does so in a way which is not Level AA compliant, the user may want to specify that the user agent allow saving those PDF files to disk for viewing in another program.
Eric Hansen Suggest the following changes to the proposal Good question. Should this be an AA SC?

More details on responses

  • Jeanne F Spellman: last responded on 2, July 2013 at 19:59 (UTC)
  • Jan Richards: last responded on 2, July 2013 at 20:32 (UTC)
  • Kimberly Patch: last responded on 2, July 2013 at 23:53 (UTC)
  • Simon Harper: last responded on 3, July 2013 at 12:46 (UTC)
  • Jim Allan: last responded on 8, July 2013 at 18:33 (UTC)
  • Greg Lowney: last responded on 11, July 2013 at 08:52 (UTC)
  • Eric Hansen: last responded on 15, July 2013 at 14:48 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.