W3C WBS Home

Results of Questionnaire UAWG Survey for 30 June 2011

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:

  1. ACTION-544 - Rewrite 2.3.5 to be technology agnostic
  2. Proposal: Overview
  3. Proposal: Delete SC 1.2.3
  4. Proposal: 1.11.2 IER
  5. Find a home for 4.1.x?

1. ACTION-544 - Rewrite 2.3.5 to be technology agnostic

Jim's email.

Current

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.

Proposed

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.

Summary

ChoiceAll 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)

Details

Responder ACTION-544 - Rewrite 2.3.5 to be technology agnosticComments 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

2. Proposal: Overview

From the Kim and Jeanne meeting of 24 June to do an editorial pass of the document

Current

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.

Proposed

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

Summary

ChoiceAll 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

Details

Responder Proposal: OverviewComments 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

3. Proposal: Delete SC 1.2.3

From the Kelly email

Current

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)

Proposed

Delete this SC. I don't know of an UA that does this and it seems really hard to do.

Summary

ChoiceAll 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

Details

Responder Proposal: Delete SC 1.2.3Comments 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?

4. Proposal: 1.11.2 IER

From the Kim and Jeanne meeting of 24 June to do an editorial pass of the document

Background

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?

Proposed

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.

Summary

ChoiceAll 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

Details

Responder Proposal: 1.11.2 IERComments 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

5. Find a home for 4.1.x?

From the Kim and Jeanne meeting of 24 June to do an editorial pass of the document

Background

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.

Proposed

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)

Summary

ChoiceAll 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

Details

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

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Jan Richards <jrichards@ocadu.ca>
  3. Eric Hansen <ehansen@ets.org>
  4. Markku Hakkinen <mhakkinen@ets.org>
  5. Wayne Dick <wayneedick@gmail.com>
  6. Kelly Ford <kelly.ford@microsoft.com>
  7. Peter Parente <pparent@us.ibm.com>
  8. Simon Pieters <simonp@opera.com>
  9. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  10. Alan Cantor <alan@cantoraccess.com>
  11. Jeanne F Spellman <jeanne@w3.org>
  12. Simon Harper <simon.harper@manchester.ac.uk>

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)