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 2011-06-21 to 2011-07-08.
3 answers have been received.
Jump to results for question:
2.3.5 Allow Override of Accesskeys (former 2.1.11) : The user can override any recognized author supplied content keybinding (i.e. access key). The user must have an option to save the override of user interface keyboard shortcuts so that the rebinding persists beyond the current session. (Level AA)
Intent: Content authors may utilize the Accesskey attribute to define short cut keys which allow quick access to specific elements, actions, or parts of their Web content. The author-selected short cuts may utilize keystrokes that are unique to their site, differing from conventions used, and or familiar, to users of other similar sites, or sites offering similar functionality. Users of assistive technologies who rely upon keyboard input may wish to have a consistent mapping of shortcut keys to similar, or common actions or functions across the sites they visit.
2.3.5 Allow Override of Accesskeys (former 2.1.11) : The user can override any recognized author supplied content keybinding (i.e. accesskey attribute in HTML). The user must have an option to save the override of user interface keyboard shortcuts so that the rebinding persists beyond the current session. (Level AA)
Intent: Depending on the markup language, content authors may be able to define short cut keys which allow quick access to specific elements, actions, or parts of their Web content. For example, in HTML, the author may use the Accesskey attribute to define these short cut keys. The author-selected short cuts may utilize keystrokes that are unique to their site, differing from conventions used, and or familiar, to users of other similar sites, or sites offering similar functionality. Users of assistive technologies who rely upon keyboard input may wish to have a consistent mapping of shortcut keys to similar, or common actions or functions across the sites they visit.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
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 response didn't contain an answer to this question)
Responder | ACTION-544 - Rewrite 2.3.5 to be technology agnostic | Comments 2.3.5 |
---|---|---|
Greg Lowney | Accept the proposal | |
Jim Allan | ||
Kimberly Patch | Recommend changes (see comments field) | Just minor edits: change ... short cut keys which allow to ... shortcut keys that allow change familiar, to users to familiar to users |
From the Kim and Jeanne meeting of 24 June to do an editorial pass of the document
Key methods for achieving that goal include:
optional self-pacing
configurability
device independence
interoperability
direct support for both graphical and auditory output
adherence to published conventions.
To achieve this goal, user agents must:
be configurable
be discoverable
be predictable
provide direct support for both graphical and auditory output
enable optional self-pacing
be device independent
be interoperable
adhere to published conventions
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
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 |
Responder | Proposal: Overview | Comments Overview |
---|---|---|
Greg Lowney | The proposal needs more discussion (see comments field) | It's OK, but I think it would be stronger with some inline elaboration, and a few items raise issues. Here are some suggested elaborations: * be configurable, so the user can adjust it to meet their needs * be discoverable, so the user can learn to use it easily * be predictable, so the user does not have to react and compensate for the user agent behaving in ways they did not expect * enable optional self-pacing, for users who need additional time to view, read, comprehend, or respond * adhere to published conventions where they do not reduce accessibility And here are some items with the questions they raised for me: * provide direct support for both graphical and auditory output...[are we really saying it has to be direct support rather than indirect support via a supported screen reader? Do you really mean graphical instead of merely visual (e.g. allowing text mode browsers)?] * be interoperable [With what? Perhaps instead say "support assistive technology such as alternative input and output utilities"?] * be device independent... [We don't really recommend device independence so much as supporting multiple input modalities. Perhaps change it to say "support multiple input styles, such as keyboard, mouse, and speech".] |
Jim Allan | Recommend changes (see comments field) | be discoverable?? what does this mean? element in the UI are discoverable perhaps...provide discoverable interface put all the be phrases together enable optional self-pacing?? for what? are device independent and interoperable similar enough that we could eliminate the interoperable? |
Kimberly Patch | Accept the proposal |
From the Kelly email
1.2.3 Repair Missing Associations: The user can specify whether or not the user agent should attempt to predict associations from author-specified presentation attributes (i.e. position and appearance). (Level AAA)
Delete this SC. I don't know of an UA that does this and it seems really hard to do.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
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 |
Responder | Proposal: Delete SC 1.2.3 | Comments 1.2.3 |
---|---|---|
Greg Lowney | Accept the proposal | |
Jim Allan | Recommend changes (see comments field) | |
Kimberly Patch | The proposal needs more discussion (see comments field) | Does this mean a user agent can change things based on the profile and the user can't control this? |
From the Kim and Jeanne meeting of 24 June to do an editorial pass of the document
1.11.1 was Basic Link Information. It had an IER written. It was deleted and 1.11.3 (Extended Link Information) was renumbered to become the new 1.11.2 with no IER. Should the IER for the old 1.11.1 be used?
1.11.2 Extended Link Information: The following information is provided for each link (Level AAA) :
link title
technology type (of the linked Web resource)
internal/external: (whether the link is internal to the resource e.g. the link is to a target in the same Web page)
Intent of Success Criterion 1.11.2:
Users who use screen readers need to be able to easily discover information about a link, including the title of the link, whether or not that link is a webpage, PDF etc. and whether the link goes to a new page or a different location in the current page, in order to navigate Web content more quickly and easily.
Examples of Success Criterion 1.11.2:
Robert, who uses a screen reader, needs to know whether a given link will automatically open in a new page or a new window. The browser indicates this information so he can discover it before he makes a decision to click on a link.
Maria has an attention disorder, new windows opening are a large distraction. She needs to know whether a given link will automatically open in a new page or a new window. The browser indicates this information so she can decide not to follow a link that opens a new window.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 2 |
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 |
Responder | Proposal: 1.11.2 IER | Comments 1.11.1 |
---|---|---|
Greg Lowney | Recommend changes (see comments field) | Do we want to change "technology type (of the linked Web resource)" to something like "recognized technology type..." or "technology type (of the linked Web resource, where known)? I'm not sure we want or expect the user agent to download and examine the linked resource merely to determine its type, because of the stress this would put on the system, bandwidth, and servers. Those could be mitigated if the user agent did this only on request from assistive technology, but even then the user would not necessarily know how large the resource is or how long it would take to determine it's technology type. In addition, I don't think the Intent or first example make good cases for why this is particularly important for users with disabilities. (The second example does, but only for one case.) We should clarify the import of both link title and technology type, and provide use cases for each. |
Jim Allan | Accept the proposal | |
Kimberly Patch | Accept the proposal |
From the Kim and Jeanne meeting of 24 June to do an editorial pass of the document
This sentence was found in the printed version of 4.1.5 but was a separate SC that looked like it had been truncated into 4.1.5.
4.1.x Programmatic Write Access: Ifk the user can modify the state or value of a pice of content through the *user interface* (e.g. by checking a box or editing a text area), the same degree of write access is available programmatically. (Level A) :
Is this sufficiently covered by 4.1.5?
4.1.5 Write Access:
If the user agent keeps an internal representation of the user content in terms of element structure, relationships between elements, element meaning, or some combination thereof, it must expose this internal representation via an appropriate means (normally by using the platform accessibility architecture or a programmatically available DOM). (Level A)
Choice | All responders |
---|---|
Results | |
Accept the proposal | 2 |
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 | Find a home for 4.1.x? | Comments 4.1.x |
---|---|---|
Greg Lowney | The proposal needs more discussion (see comments field) | 4.1.x Programmatic Write Access will be fine after fixing the typos "Ifk" and "pice". However, the title of 4.1.5 is incorrect. Simon proposed this as a new SC in email of 2010-05-28 and clearly meant for it to be inserted into the order as the new 4.1.5 rather than replacing the existing 4.1.5, and it would need a new title unrelated to write access. I wrote about this on 2010-11-23 saying: "4.1.5 Write Access" has the correct wording crossed out, and a different SC taking its place. It previously read "If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically. (Level A)", but now reads "If a User Agent keeps an internal representation of the user content in terms of element structure, relationships between elements, element meaning, or some combination thereof, it must expose this internal representation via an appropriate means normally by using the platform accessibility architecture or a programmatically available DOM) (level A)". Simon proposed this new SC in email of 5/28/10, with the stated intention "To overcome possible problems related to decentralized-extensibility." His email said it should be inserted at (i.e. before), rather than replace, the current 2.1.5 (Write Access) which is now 4.1.5. |
Jim Allan | Accept the proposal | 4.1.x should be in the document. it is not covered by 4.1.5. 4.1.x is about changing the state, editing content. 4.1.5 is about a mapping of content. nit: 4.1.x "Ifk" should be "If" |
Kimberly Patch | Accept the proposal |
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
.