w3c/wbs-design
or
by mail to sysreq
.
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 2009-05-27 to 2009-06-26.
8 answers have been received.
Jump to results for question:
4.1.9 Override of UI Keyboard Commands: The user can override any keyboard shortcut binding for the user agent user interface except for conventional bindings for the operating environment (e.g., for access to help). The rebinding options must include single-key and key-plus-modifier keys if available in the operating environment. (Level A)
4.1.9 Override of UI Keyboard Commands: The user can override any keyboard shortcut binding for the user agent user interface except for conventional bindings for the operating environment (e.g., for access to an open command). The rebinding options must include single-key and key-plus-modifier keys if available in the operating environment. This does not prohibit a user agent from supporting user override of conventional bindings for the operating platform to extend accessibility of the user agent. (Level A)
Choice | All responders |
---|---|
Results | |
Accept the proposal | 5 |
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 |
Responder | 4.1.9 Override of UI Keyboard Commands | Comments |
---|---|---|
David Poehlman | Accept the proposal | |
Jan Richards | The proposal needs more discussion (see comments field) | Should this be AA? It is P2 in UAAG 1.0. |
Simon Harper | Accept the proposal | |
Kimberly Patch | Accept the proposal | |
Kelly Ford | Accept the proposal | |
Jim Allan | Accept the proposal | |
Jeanne F Spellman | The proposal needs more discussion (see comments field) | The last sentence is still not clear. It took me about 4 times through to understand what it means. recommend inserting before the sentence beginning "the rebinding options": This does not prohibit the user agent from allowing user override of the conventional bindings. |
Greg Lowney | The proposal needs more discussion (see comments field) | Please see comments at http://lists.w3.org/Archives/Public/w3c-wai-ua/2009AprJun/0093.html. |
Guideline 4.5 Store preference settings.
4.5.1 Save Settings: User agent preference settings are stored between sessions. (Level A)
4.5.2 User Profiles: The user can save and retrieve multiple sets of user agent preference settings. (Level AA)
4.5.3 Portable Profiles: Sets of preferences are stored as separate files (allowing them to be transmitted electronically). (Level AAA)
4.5.4 Preferences Wizard: A "wizard" helps the user to configure (at least) the accessibility-related user agent preferences. (Level AAA)
Guideline 4.5 Configure and Store accessibility preference settings.
4.5.1 Reconfigure Accessibility Defaults: The user agent will allow default settings that impact accessibility to be reconfigured by the user. (Level A)
4.5.2 Save Accessibility Settings: User agent accessibility preference settings are stored between sessions. (Level A)
4.5.3 Accessibility User Profiles: The user can save and retrieve multiple sets of user agent preference settings. (Level AA)
4.5.4 Accessibility Portable Profiles: Sets of preferences are stored as separate files (allowing them to be transmitted electronically). (Level AAA)
4.5.5 Accessibility Preferences Wizard: A "wizard" helps the user to configure (at least) the accessibility-related user agent preferences. (Level AAA)
Choice | All responders |
---|---|
Results | |
Accept the proposal | 5 |
Recommend changes (see comments field) | |
The proposal needs more discussion (see comments field) | 2 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group | 1 |
Responder | Guideline 4.5 Configure and Store accessibility preference settings | Comments |
---|---|---|
David Poehlman | Neutral - will accept the consensus of the group | we have to study the security implications of the portability section. |
Jan Richards | The proposal needs more discussion (see comments field) | I'm a bit concerned by 4.5.1. Because it refers to something everyone does anyway (make preference setting configurable), I think people might interpret as requiring everything that impacts accessibility to be controlled by a preference setting. |
Simon Harper | Accept the proposal | 4.5.4 - see below (4. Move 4.5.3 to Level AA.). |
Kimberly Patch | Accept the proposal | One comment -- who is determining what defaults have to do with accessibility? I think there are many defaults that have to do accessibility that might not the obvious to everyone. |
Kelly Ford | Accept the proposal | |
Jim Allan | Accept the proposal | In the Techniques or Understanding document, we should make clear that meeting these success criteria does not prevent the UA from saving other settings not related to accessibility. Or from making them transportable. Accessibility settings do not necessarily have to be separate from other settings, but must still meet these SC. |
Jeanne F Spellman | Accept the proposal | Do we also need to be able to easily reset them to the defaults, or is that covered elsewhere. I know we have talked about it. |
Greg Lowney | The proposal needs more discussion (see comments field) | Please see comments at http://lists.w3.org/Archives/Public/w3c-wai-ua/2009AprJun/0094.html |
A potentially harmful flash occurs when there is a pair of opposing changes in luminance (i.e., an increase in luminance followed by a decrease, or a decrease followed by an increase) of 20 candelas per square metre (cd.m-2) or more (see notes 1 and 2). This applies only when the screen luminance of the darker image is below 160 cd.m-2. Irrespective of luminance, a transition to or from a saturated red is also potentially harmful.
Isolated single, double, or triple flashes are acceptable, but a sequence of
flashes is not permitted when both the following occur:
i. the combined area of flashes occurring concurrently occupies more
than one quarter of the displayed (see note 3) screen area; and
ii. there are more than three flashes within any one-second period.
For clarification, successive flashes for which the leading edges are
separated by 9 frames or more are acceptable, irrespective of their
brightness or screen area.
Notes:
1. A luminance voltage of 234 mV results in light output of 20.1 cd.m-2. If the brighter image of a
flash or pattern is above this level, then it is potentially harmful if the light output between the
darker and brighter images differs by 20 cd.m-2 or more.
2. A luminance voltage of 631 mV results in light output of 160 cd.m-2. If the darker image of a
flash or pattern is below this level, then it is potentially harmful if the light output between the
darker and brighter images differs by 20 cd.m-2 or more.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 3 |
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 | 4 |
Responder | 4.4.1 define - general flash and red flash thresholds | Comments |
---|---|---|
David Poehlman | Neutral - will accept the consensus of the group | |
Jan Richards | Neutral - will accept the consensus of the group | |
Simon Harper | Accept the proposal | |
Kimberly Patch | Accept the proposal | |
Kelly Ford | Neutral - will accept the consensus of the group | |
Jim Allan | Accept the proposal | do we need a reference? where is Note 3? |
Jeanne F Spellman | Recommend changes (see comments field) | This needs to be worded as a definition. |
Greg Lowney | Neutral - will accept the consensus of the group |
ISSUE-4 Move 4.5.3 to Level AA. Seems to me this should stay at AAA, while it would be useful for transferring profiles between the same browser, I think it maybe goes beyond the our remit for UAAG as this seems to more about additional functionality which is not pre-provided for all, and it seems that if we wanted to facilitate transfer between different UA we would need to define a language. A good idea in and of itself but beyond our remit I think.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 2 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | 3 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group | 2 |
Responder | Move 4.5.3 to Level AA. | Comments |
---|---|---|
David Poehlman | Accept the proposal | |
Jan Richards | The proposal needs more discussion (see comments field) | Maybe we could clarify as follows: Portable Profiles: Sets of preferences are stored such that they can be transferred between different installations of the same user agent. (Level AA) |
Simon Harper | Accept the proposal | |
Kimberly Patch | The proposal needs more discussion (see comments field) | Accessible profiles sometimes take quite a bit of time to set. Making an accessible profile portable means you can access multiple computers more easily and more easily work on other people's computers. This is a basic in some jobs. Ease of access to a given computer is a showstopper in many situations. |
Kelly Ford | Neutral - will accept the consensus of the group | |
Jim Allan | The proposal needs more discussion (see comments field) | current rewrite of this - see #2 (4.5.4) above has this as AAA. When this was originally written, the concept was - user creates a mysettings.profile in UAx, that file can be used on other UAx on other computers. But would not be required to work with UAy or any other UA. The comment above, seems to indicate that the profile would/might work in all UA cross platform. HTML, CSS, and JS can hardly do that now. I agree that cross browser/platform profile usage is beyond our charter. Perhaps we need some language to limit the profile to individual UAs and perhaps on a given platform. <proposed> 4.5.4 Accessibility Portable Profiles: Sets of preferences are stored as separate files (allowing them to be transmitted electronically). Note: These profiles may be usable only with the brand(?) of user agent that created it (Level AAA) |
Jeanne F Spellman | Neutral - will accept the consensus of the group | |
Greg Lowney | Recommend changes (see comments field) | Per my comment #7 in http://lists.w3.org/Archives/Public/w3c-wai-ua/2009AprJun/0094.html, I suggest harmonizing with ISO 9241-171 by adopting their wording or a close equivalent. ISO says "8.2.6 Provide capability to use preference settings across locations [ANSI Level 3]: Software should permit users to transfer their preference settings easily onto a compatible system.", and it provides a number of important accompanying notes and examples. |
#108. (Re 4.9.7) Split multimedia stop/start from pause/resume: I'm concerned that none of the major Web browsers comply with the Level A success criteria that they allow the user to stop, pause, and resume multimedia. Neither Firefox, Internet Explorer, nor Safari allow the user to pause and resume animated gifs regardless of their duration. Consider splitting this SC into two: the ability to stop and start multimedia as Level A, and the ability to pause and resume multimedia as Level AA. (Priority: 1 High) (Type: Narrow)
Choice | All responders |
---|---|
Results | |
Accept the proposal | 7 |
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 |
Responder | #108. (Re 4.9.7) Split multimedia stop/start from pause/resume | Comments |
---|---|---|
David Poehlman | Accept the proposal | |
Jan Richards | Accept the proposal | |
Simon Harper | Accept the proposal | Accept but with a question; is the pause resume state persistent across sessions? |
Kimberly Patch | The proposal needs more discussion (see comments field) | I think pausing is a very important ability that bears on accessibility. Is it difficult to implement? |
Kelly Ford | Accept the proposal | |
Jim Allan | Accept the proposal | |
Jeanne F Spellman | Accept the proposal | |
Greg Lowney | Accept the proposal |
#109. (Re 4.9.7 **) Remove restrictions based on multimedia duration: 4.9.7 and 4.9.8 both restrict their applicability to multimedia that lasts three seconds or longer at default playback rate. Because a user agent would often not know the duration of multimedia content, it would have to provide these controls for all multimedia, so I would remove the 3-second restriction from both success criteria (and my proposed split off 4.9.7). (Someone could argue that the Note for this guideline, which says it only applies to multimedia "that the user agent can recognize" means that 4.9.7 and 4.9.8 would only apply to multimedia for which the user agent can recognize the length. If that is the working group's intention then the Note should be significantly reworded to make this clear, and the working group needs to accept that these criteria would have extremely limited applicability.) (Priority: 1 High) (Type: Expand)
Choice | All responders |
---|---|
Results | |
Accept the proposal | 6 |
Recommend changes (see comments field) | |
The proposal needs more discussion (see comments field) | 2 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | #109. (Re 4.9.7 **) Remove restrictions based on multimedia duration | Comments |
---|---|---|
David Poehlman | Accept the proposal | |
Jan Richards | Accept the proposal | My reading of this is that along with #108 they now say: 4.9.X Stop/Start Multimedia: The user can stop and start rendered audio and animation content (including video and animated images). (Level A) 4.9.7 Pause/Resume Multimedia: The user pause and resume rendered audio and animation content (including video and animated images) . (Level AA) 4.9.8 Navigate Multimedia: The user can navigate efficiently within rendered audio and animations (including video and animated images). (Level A) BUT "NAVIGATE EFFICIENTLY" NEEDS A DEFINITION AT LEAST |
Simon Harper | Accept the proposal | |
Kimberly Patch | Accept the proposal | |
Kelly Ford | Accept the proposal | |
Jim Allan | The proposal needs more discussion (see comments field) | Agree to removing the 3 second time restriction. The author would know the playback length of animated gifs (these are played nativly in the browsers). other multimedia (movies, flash, etc.) are played in their own native players that are embedded within the base user agent. It is up to these native players to provide the functionality (I think they all do). So the special case is animated gifs which have no player controls. Rather than making a blanket reduction in functionality for all media, we should make an exception for animated gifs (stop and play - though the only way to play again once stopped is to refresh the page). Are there other media that UAs play natively that are similar to animated gifs? Also, it should be made clear for animated gifs, that control of individual gifs is not required. Question - does the UA know the difference between an animated and static gif? Hitting <esc> makes it stop, but how? |
Jeanne F Spellman | The proposal needs more discussion (see comments field) | Isn't this based on the difference of media vs. animated gifs? I agree we need to make it more clear. |
Greg Lowney | Accept the proposal | Re Jim's suggestion, I don't favor enshrining specific technology-specific issues in the guidelines, such as special-casing animated GIFs. Ideally UA that plays media (video and/or sound) should allow the user to perform all the major operations (start/stop at Level A, pause/resume possibly at Level AA, Fast Forward/Reverse at Level AA or AAA, etc.), and that would apply to plug-in players rendering AVI, Flash, or MPEG just as much as to Web browsers natively rendering animated GIFs and maybe eventually animated SVGs or EMMA markup. I merely suggest we be pragmatic and make pause/resume lower priority for a period of time until browsers can add the functionality, and let them know it's coming. The version that Jan quotes in his comment seems right. |
#110. (Re 4.9.8 **) Remove restrictions based on multimedia duration: Please see my comment with this title for 4.9.7 (Stop/Pause/Resume Multimedia). (Priority: 1 High) (Type: Expand
Choice | All responders |
---|---|
Results | |
Accept the proposal | 5 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | 1 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
(1 response didn't contain an answer to this question)
Responder | #110. (Re 4.9.8 **) Remove restrictions based on multimedia duration | Comments |
---|---|---|
David Poehlman | Accept the proposal | |
Jan Richards | Accept the proposal | |
Simon Harper | The proposal needs more discussion (see comments field) | I Agree with this really. This is just a Flag. I think we should also state that ALL time based presentations on a page can be paused / stopped with a single keystroke or combination thereof. |
Kimberly Patch | Accept the proposal | |
Kelly Ford | Accept the proposal | |
Jim Allan | Accept the proposal | |
Jeanne F Spellman | ||
Greg Lowney | Recommend changes (see comments field) | As per discussion of 4.9.7, 4.9.8 (navigating within rendered audio and animations) might fit the criteria for "browsers can't do it natively yet, so postpone it via temporarily lowered priority". |
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
w3c/wbs-design
or
by mail to sysreq
.