W3C WBS Home

Results of Questionnaire UAWG Survey for 12 July 2012

The results of this questionnaire are available to anybody.

This questionnaire was open from 2012-07-10 to 2012-07-24.

8 answers have been received.

Jump to results for question:

  1. Definition of Relative TIme Units (action 699)
  2. Proposed new 1.1.3
  3. Proposed 4.1.1
  4. Proposed 5.x.x Enable Reporting of User Agent Accessibility Faults

1. Definition of Relative TIme Units (action 699)

Proposed: Definition of Relative Time Units

from email

Relative time units define time intervals for media navigation which may be preset, user configurable, and/or automatically calculated based upon media duration. When interacting with a time-based media presentation, a user may find it beneficial to move forward or backward via a time interval relative to their current position. For example, a user may find a concept unclear in a video lecture and elect to skip back 30 seconds from the current position to review what had been described.

Summary

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

Details

Responder Definition of Relative TIme Units (action 699)Definition of Relative Time Units
Kimberly Patch Suggest the following changes to the proposal Minor editing:
Change
relative to their current position
To
relative to the current position
Simon Harper Neutral, will accept consensus of the group Not sure how the example relates to the Definition. We say that time units 'define time intervals' so I presume this means I might define 1 time unit as 5 seconds; or in a different instance as 5% of the total time... right? In this case the example is more about absolute time units (I'd suggest).

So wouldn't this be more appropriate:

For example, a user may find a concept unclear in a video lecture and - having already defined a time unit as 5 seconds - elect to skip back 6 time units (equating to 30 seconds) from the current position to review what had been described.

?


I presume the rational for this is that if using keyboard control pressing the back key 30 times (rapidly) to get back 30 seconds is more taxing on a person with, say, RSI then pressing the key 6 times (or whatever the time unit equates to)?

Cheers
Jaime Rice Agree with the proposal
Markku Hakkinen Agree with the proposal
Jeanne F Spellman Suggest the following changes to the proposal I thought the "current position" was important enough to understanding to put in the first sentence.

"Relative time units define time intervals *from the current position* for media navigation "
Kelly Ford Agree with the proposal
Greg Lowney Suggest the following changes to the proposal I can live with it but a few edits might make it clearer.

For example, rather than trust the reader will recognize that "that" in the first sentence introduces a non-restrictive clause, I'd break the two clauses into separate sentences. I'd also move the second clause because it does not need to be part of the stage-setting introductory sentence.

Thus: "Relative time units define time intervals for navigating media relative to the current point (e.g. move forward 30 seconds). When interacting with a time-based media presentation, a user may find it beneficial to move forward or backward via a time interval relative to their current position. For example, a user may find a concept unclear in a video lecture and elect to skip back 30 seconds from the current position to review what had been described. Relative time units may be preset by the user agent, configurable by the user, and/or automatically calculated based upon media duration (e.g. jump 5 seconds in a 30-second clip, or 5 minutes in a 60-minute clip). Relative time units are distinct from absolute time values such as the 2 minute mark, the half-way point, or the end.
Jan Richards Agree with the proposal

2. Proposed new 1.1.3

Proposed new 1.1.3

from email

1.1.3 Time-Based Media Alternatives: The user can configure any or all of the following for visually-rendered time-based media alternatives (e.g. captions, sign language video):

(a) Scale: the media alternative as a viewport that may occupy any rectangular region within the user agent's viewport.

(b) Position: the media alternative as a viewport so that it does not obscure the primary time-based media or its controls.

(c) Adjust Text: within Alternative media tracks in conformance with 1.4.1.

The user can scale and position alternative visual media tracks independent of the base video or audio player presentation. (Level AAA)

Intent of Success Criterion 1.1.3 :

Users who require or can benefit from alternative media tracks in video or audio may not find the default or authored position and size of those tracks to be usable. Enabling the user to move and scale any displayed alternate media tracks (e.g. captions) allows for the displayed content to be positioned and sized to meet the needs of the user.

Examples of Success Criterion 1.1.3 :

Justin has low vision and works in a noisy environment that makes it difficult to listen to instructional videos. When he enlarges the text of the captions to a viewable size, they block most of the video image. Justin selects an option that displays the caption track in a separate window, which he positions below the video image so the captions do not block the video image.

Jaime is deaf and is taking courses from on online university. She prefers to utilize ASL if it is available for online media, and a current course she is taking offers both captions and a signing avatar for the recorded lectures. Selecting the signing track, she finds the default size of the avatar window too small, making it difficult to follow. The avatar also overlays an important part of the lecture video content. Jaime drags the avatar out of the video player and enlarges it, so that both are equally sized and side by side.

Summary

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

Details

Responder Proposed new 1.1.31.1.3
Kimberly Patch Agree with the proposal
Simon Harper Agree with the proposal
Jaime Rice Agree with the proposal
Markku Hakkinen Agree with the proposal
Jeanne F Spellman Agree with the proposal
Kelly Ford Agree with the proposal
Greg Lowney Suggest the following changes to the proposal I'd remove the colons that break up the list item sentences.

"(a) Scale: the media alternative as a viewport that may occupy any rectangular region within the user agent's viewport", the part about "any rectangular region" makes it sound like it's about moving, which is the following list item.

Re "within the user agent's viewport", make sure Related Resources reminds them that the viewport itself needs to be resizable per 1.8. Without that the current item would only require the ability to make text smaller, not larger.

The last paragraph "The user can scale and position alternative visual media tracks independent of the base video or audio player presentation." is now redundant to the list items so should probably be deleted, and the (AAA) moved.

Item B seems like a restrictive clause, meaning that the UA would comply as long as the alternative "does not obscure the primary time-based media or its controls", even if the user could not adjust the position any further (e.g. move from top to bottom). Is that the intent? I suggest separating the clause, as in "(b) Position the media alternative as a viewport (e.g. so that it does not obscure the primary time-based media or its controls)."
Jan Richards Suggest the following changes to the proposal Not quite there IMO...maybe needs reference to SCs related to expanding viewports?

For (a)-(c) the stem should not be part of the sentence...instead:
"(a) Scale: the media alternative should be scalable as a viewport that may occupy any rectangular region within the user agent's viewport." etc.

Is the last sentence a "Note"?

3. Proposed 4.1.1

from email

Replacing: 4.1.1 Platform Accessibility Architecture: The user agent supports a platform accessibility architecture relevant to the operating environment. (Level A)

...with...

4.1.1 Platform Accessibility Services: If the user agent contains non-web-based user interfaces, then those user interfaces implement communication with platform accessibility services. [ed. On Monday AUWG may change the wording slightly to: " expose accessibility information through"]
Note: The (optional) explanation of conformance claim results should record the platform accessibility service(s) that were implemented."

Intent:

The intent of this success criterion is to ensure that user agent user interfaces that are not web applications are more accessible to users with disabilities who use assistive technologies that communicate with software via platform accessibility services. The requirement is stated generally because the specifics of what constitutes a platform accessibility service will differ on each platform.

The note regarding documenting the platform accessibility service(s) that were implemented in the conformance claim should encourage developers to implement services that are well supported by assistive technologies.

Examples:

UNCHANGED

Related Resources:

The following is a non-exhaustive list of documents related to communication with platform accessibility services for various platforms:
Desktop OS
GNOME Desktop on Linux: GNOME Accessibility Developers Guide
KDE Desktop on Linux: Developer's Information
Mac OS: Accessibility Overview
Microsoft Windows: Accessibility Overview
Mobile OS
Android: Example from Android Developer Reference
BlackBerry: BlackBerry Accessibility
iPhone OS: Accessibility Programming Guide for iPhone OS
Cross-OS environments
Java SE: Java SE Desktop Accessibility

Summary

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

(2 responses didn't contain an answer to this question)

Details

Responder Proposed 4.1.1 Comments
Kimberly Patch Agree with the proposal Note: I like the "expose accessibility information through" wording better
Simon Harper Agree with the proposal
Jaime Rice Agree with the proposal
Markku Hakkinen Agree with the proposal
Jeanne F Spellman
Kelly Ford Agree with the proposal
Greg Lowney
Jan Richards Agree with the proposal

4. Proposed 5.x.x Enable Reporting of User Agent Accessibility Faults

from email

5.x.x Enable Reporting of User Agent Accessibility Faults: Users can report faults in accessibility support within the user agent using a built-in facility for that purpose. (Level AAA)

Intent of Success Criterion 5.X :

Users of assistive technology such as screen readers may find that their assistive technology may not be compatible fully with their Web browser, or that the browser may not accessibly render content that has been authored in compliance with WCAG, resulting in a loss of information or convenience. In these instances, users with disabilities will benefit from being able to easily file a report with the user agent vendor to inform them of the incompatibility, similar to the feedback mechanisms currently available in some user agents to file bug reports.

Examples of Success Criterion 5.X :

Alice is a visually impaired college student who frequently uses a refreshable Braille display with her Web browser on her laptop. Usually, she does not encounter issues with displaying text from her browser on her refreshable braille display. However, occasionally she experiences difficulty with elements such as drop-down boxes or complex menus, where the text is only partially rendered on the braille display. Alice notices this incompatibility and navigates to the feedback section of her browser. After providing some basic information (such as AT device and computer hardware used), Alice is able to describe the problem she encountered and submit the report to the browser vendor.

Fred has low vision and uses screen magnification software to enlarge displayed information and alter color contrast. While reading content on a Web site in compliance with WCAG, Fred discovers that the scroll bars are not visible and he cannot scroll further down the page. Unable to read the information he needs, Fred selects the Feedback option from his browser's Tools menu, and is presented with a dialog where he can select which information to transmit to the browser vendor. He selects to include the current URL of the page he is trying to view, system information including OS and screen magnifier version, and enters a description of the problem he is having. Though not required, Fred chooses to provide his email address so that the vendor may contact him for further details or to provide a workaround.

Summary

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

(2 responses didn't contain an answer to this question)

Details

Responder Proposed 5.x.x Enable Reporting of User Agent Accessibility Faults5.x.x
Kimberly Patch Suggest the following changes to the proposal Editing changes to make it clearer:
Intent of Success Criterion 5.X:
People who use assistive technologies such as screen readers may find that a technology isn't fully compatible with a Web browser, or that the browser doesn't accessibly render content authored in compliance with WCAG. This causes information loss and inconvenience. When this happens, users with disabilities will benefit from being able to easily file a report with the user agent vendor to report the incompatibility, similar the way users can file bug reports in some user agents today.
Simon Harper Agree with the proposal
Jaime Rice Agree with the proposal
Markku Hakkinen Suggest the following changes to the proposal In the intent, change first sentence:

"Users of assistive technology such as screen readers may find that their assistive technology may not be fully compatible with their Web browser, ..."

and change the last sentence:

"currently available in some user agents to file bug reports or provide feedback."


First example (wording changes):

Alice is a visually impaired college student who frequently uses a refreshable braille display with her Web browser. Occasionally she experiences difficulty with Web content containing elements such as drop-down list boxes or complex menus, where the text is only partially rendered on the braille display. Alice notices this incompatibility and navigates to the feedback section of her browser. After providing some basic information (such as AT software and computer hardware used), Alice is able to describe the problem she encountered and submit the report to the browser vendor.


Jeanne F Spellman
Kelly Ford Agree with the proposal
Greg Lowney
Jan Richards Neutral, will accept consensus of the group instead of a built-in facility for that purpose, what if it is an email address? I could then see this as AA.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Jim Allan <jimallan@tsbvi.edu>
  3. Eric Hansen <ehansen@ets.org>
  4. Wayne Dick <wayneedick@gmail.com>
  5. Peter Parente <pparent@us.ibm.com>
  6. Simon Pieters <simonp@opera.com>
  7. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  8. Alan Cantor <alan@cantoraccess.com>
  9. he wen <rockywen@tencent.com>
  10. Henny Swan <hswan@paciellogroup.com>
  11. Shaohang Yang <shaohang.ysh@alibaba-inc.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


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.127 2015-02-04 08:52:34 carcone Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)