There are 7 comments (sorted by their types, and the section they are about).
question comments
Comment LC-2546 : Embedded Flash content
Commenter: Makoto Ueki <makoto.ueki@gmail.com> on behalf of JIS (archived message ) Context: Pause, Stop, Hide: Understanding Success Criterion 2.2.2
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Flash animation is embedded in a HTML web page. The animation has five screens. It starts automatically, lasts more than five seconds, and is presented in parallel with other content. It also has five buttons to stop the animation. When each button receive focus, the movement of the animation will be paused.
Is this considered to be "a mechanism for the user to pause" the animation?
The point is that it might not be obvious for users to understand that the buttons are the mechanism.
Example:
http://www.fujitsu.com/us/
Proposed Change:
Need an answer from WCAG WG to harmonize JIS with WCAG 2.0.
Related issues: (space separated ids)
WG Notes: Michael to draft additional info for Intro to Understanding. Action 147.
Response:
WCAG just says that a mechanism needs to be provided. Whether something is obvious is not testable - although good practice would be to do this of course. In this case you can point to any of the 5 buttons OR point to the image itself to pause it.
For the animated text bar, there is actually a pause button shown.
@@add a new section in the techniques intro after the "testing techniques" section, with title "Application of techniques", and content as follows.
Techniques in this suite often contain code samples to show the technique in practice. These samples exemplify the technique but do not necessarily exemplify all aspects of good code practice or features needed to conform to other success criteria. This is to keep the examples brief and facilitate understanding of the central point of the sample. Accordingly, authors should not copy these examples in production code unless they provide the missing functionality. In addition to inline code samples, many techniques provide "working examples" that are more complete. Such samples are more appropriate as a starting point for production code, although even these may have minimal content.
Many techniques describe how to provide alternate mechanisms to access content. It is important to remember that such alternate functionality must itself conform to WCAG 2.0. A given technique may focus on the basic way to provide the alternate mechanism, but authors need to follow additional relevant techniques to ensure the alternate mechanism meets requirements.
Some techniques use the word "must". Because this is not a normative document, this word is not used in the sense of RFC 2119, as it is in WCAG 2.0. The colloquial use of the word "must" describes proper application of the specific technique under consideration. It does not imply requirements beyond the scope of the technique. This means it does not impose requirements on interpretation of the Success Criterion to which the technique relates.
Reply from commenter:
Thank you very much for the response.I appreciate your help.
Can I ask you an additional question?
When the Flash buttons receive focus, the Flash animation would be
paused. However,
if the user move the focus to the HTML links and/or controls on the
same page, the Flash
animation would be restarted. Even if so, does it mean that the Flash
animation passed SC 2.2.2?
Resolution: If you cannot move the focus away from the buttons without the animation restarting, then the animation cannot be paused in a manner that allows use of the page -- so it would not be considered a pause in the way it is meant in the SC. We have clarified this in the Understanding Document by adding the following.
[DONE] For a mechanism to be considered "a mechanism for the user to pause," it must provide the user with a means to pause that does not tie up the user or the focus so that the page cannot be used. The word "pause" here is meant in the sense of a "pause button" although other mechanisms than a button can be used. Having an animation stop only so long as a user has focus on it (where it restarts as soon as the user moves the focus away) would not be considered a "mechanism for the user to pause" because it makes the page unusable in the process and would not meet this SC.
==================================================================
[DONE] add a new section in the techniques intro after the "testing techniques" section, with title "Application of techniques", and content as follows.
Techniques in this suite often contain code samples to show the technique in practice. These samples exemplify the technique but do not necessarily exemplify all aspects of good code practice or features needed to conform to other success criteria. This is to keep the examples brief and facilitate understanding of the central point of the sample. Accordingly, authors should not copy these examples in production code unless they provide the missing functionality. In addition to inline code samples, many techniques provide "working examples" that are more complete. Such samples are more appropriate as a starting point for production code, although even these may have minimal content.
Many techniques describe how to provide alternate mechanisms to access content. It is important to remember that such alternate functionality must itself conform to WCAG 2.0. A given technique may focus on the basic way to provide the alternate mechanism, but authors need to follow additional relevant techniques to ensure the alternate mechanism meets requirements.
Some techniques use the word "must". Because this is not a normative document, this word is not used in the sense of RFC 2119, as it is in WCAG 2.0. The colloquial use of the word "must" describes proper application of the specific technique under consideration. It does not imply requirements beyond the scope of the technique. This means it does not impose requirements on interpretation of the Success Criterion to which the technique relates. (Please make sure the resolution is adapted for public consumption)
general comment comments
Comment LC-2552 : Appendix A: Minor additional pointer
Commenter: Shawn Henry <hawn@w3.org> (archived message ) Context: Appendix A: How to refer to WCAG 2.0 from other documents
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :We now have additional information on generally referencing and linking to WAI technical documents. Ideally we'd spend some time to integrate these better; however, I don't think it's worth the time. Instead I propose one little addition to this appendix. Thanks. (I added a a link to this appendix from that document.)
Proposed Change:
Add to the beginning: For additional guidance, see <a href="http://www.w3.org/WAI/intro/linking.html">Referencing and Linking to WAI Guidelines and Technical Documents</a>.
Related issues: (space separated ids)
WG Notes: perhaps this link should be raised in prominence beyond just as an extra sentence in Appendix A of Understanding.. perhaps it should be put at beginning of Understanding or even in the Guidelines document.. this is an important issue which comes up often in general context so perhaps it shouldn't be "buried" in appendix..?
PS - on side note, where does proposed "myth" document relate to set of WCAG/WAI document? Can it refer to other documents or is it referable by other documents?
Resolution: [DONE] The WG thanks you for your comment. The proposed change is accepted, and the proposed sentence will be added to the appendix as you request. (Please make sure the resolution is adapted for public consumption)
substantive comments
Comment LC-2532 : Need (or not) for text equivalent of AV files
Commenter: Maria Moore <maria.moore@utas.edu.au> (archived message ) Context: Audio-only and Video-only (Prerecorded): Understanding Success Criterion 1.2.1
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :I am a bit unclear about the note on http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-av-only-alt.html, that says /Note: /A text equivalent is not required for audio that is provided as an equivalent for video with no audio information. For example, it is not required to caption video description that is provided as an alternative to a silent movie.
> Surely this does not assist deaf-blind people? I would have thought that a text equivalent would be needed.
Proposed Change:
Providing an audio description of video only creates another file (the audio description), that needs a text equivalent
Related issues: (space separated ids)
WG Notes: See also http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Jul/0010.html, which is very similar:
Proposed Change:
A text equivalent would be needed for the audio description of a video-only file.
Resolution: There is never a requirement for an alternative to an alternative. If an audio description is required, it is an alternative to visual information and a visual alternative to the audio alternative for the visual content is not required.
Note that captions are not required to be "programmatically determined" so a deaf-blind person cannot necessarily access captions anyway. Also, audio descriptions only provide minimal coverage of the visual information unless extended audio descriptions are used -- which are not required.
A machine readable text description of both audio and visual information would indeed be helpful to people who are deaf-blind and is one of the ways of meeting the level A provision.
It is also explicitly required in its own provision at level AAA.
(Please make sure the resolution is adapted for public consumption)
Comment LC-2548 : Guideline 1.3 covering the needs of people with low vision
Commenter: Shawn Henry <shawn@w3.org> (archived message ) Context: Understanding Guideline 1.3: Create content that can be presented in diffe...
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Nobody
Abma, Jake
Abou-Zahra, Shadi
Allan, Jim
Auclair, Christopher
Avila, Jonathan
Babinszki, Tom
Bailey, Bruce
Bernard, Renaldo
Bernier, Alex
Blake, Matthew
Boudreau, Denis
Brewer, Judy
Butler, Shari
Campbell, Alastair
Carlson, Laura
Chakravarthula, Srinivasu
Cirrincione, Pietro
Conway, Vivienne
Cooper, Michael
Crutchfield, Elizabeth
Deltour, Romain
Dick, Wayne
Ding, Chaohai
Dirks, Kim
Dixit, Shwetank
Draffan, E.A.
Duggin, Alistair
Eggert, Eric
Elledge, Michael
Faulkner, Steve
Ferraz, Reinaldo
Fiers, Wilco
Fischer, Detlev
Foliot, John
Garrish, Matt
Garrison, Alistair
Gower, Michael
Guarino Reid, Loretta
Hakkinen, Markku
Haritos-Shea, Katie
Henry, Shawn
Hoffmann, Thomas
Horton, Sarah
Isager, Kasper
Jensen, Tobias Christian
Johansson, Stefan
Johlic, Marc
Johnson, Rick
Jones, Crystal
Joys Andersen, Wilhelm
Kapoor, Shilpi
Keim, Oliver
Kirkpatrick, Andrew
Kirkwood, John
Kiss, Jason
Kraft, Maureen
Ku, JaEun
Kurapati, Sujasree
Lauke, Patrick
Lauriat, Shawn
Lee, Steve
Lemon, Gez
Li, Alex
Li, Kepeng
Li, Liangcheng
Loiselle, Chris
Lowney, Greg
Lui, Edwina
Lund, Adam
Ma, Jia
MacDonald, David
Mace, Amanda
Manser, Erich
Martin, Debra
McCormack, Scott
McMeeking, Chris
McSorley, Jan
Milliken, Neil
Montgomery, Rachael
Mueller, Mary Jo
nicole, windmann
Niemann, Gundula
Nurthen, James
O Connor, Joshue
Oh, Jeong-Hun
Panchang, Sailesh
Pandhi, Charu
Pasi, Aparna
Patch, Kimberly
Philipp, Melanie
Pluke, Mike
Pouncey, Ian
Repsher, Stephen
Rochford, John
Runyan, Marla
Savva, Andreas
Sawczyn, Steve
Schnabel, Stefan
Seeman-Kestenbaum, Lisa
Sims, Glenda
Singh, Avneesh
Skotkjerra, Stein Erik
Sloan, David
Smith, Alan
Smith, Jim
Solomon, Adam
Spellman, Jeanne F
Strobbe, Christophe
Suprock, Greg
Swallow, David
Thompson, Kenneth
Thyme, Anne
Ueki, Makoto
Vaishnav, Jatin
Vanderheiden, Gregg
Venkata, Manoj
Wahlbin, Kathleen
Wang, Can
WANG, WEI
White, Jason
Zelmanowicz, Erica
Zerner, Adam
Zhang, Mengni
Type: substantive
editorial
typo
question
general comment
undefined
Comment :Dear WCAG WG,
There have been some issues raised around WCAG 2.0's coverage of the needs of people with low vision. At a minimum, coverage under Guideline 1.3 needs to be clarified in the Understanding document.
Additionally, we have been re-looking closely at Guideline 1.3 and Success Criterion 1.3.1 along with their corresponding sections in the Understanding document and feel that it is important to revisit this issue.
So this is a brief comment to request that we have further discussion, before the updated version of the Techniques and Understanding documents are published.
Specifics to follow. Thanks in advance.
~Shawn
Related issues: (space separated ids)
WG Notes: It appears Shawn will provide additional comments on this and that this comment is not complete or actionable at the current time. It is not surprising that there are 1.3.1 issues given that it is a "catch all" for a variety of accessibility issues. When doing evaluations there are usually about twice as many 1.3.1 issues as all the others combined. So yes we may need some revision... it does not appear Shawn has provided "specifics to follow" yet and given our timeline I propose we get her on the phone to give us direction for her comments and then we take it from there so we can get them updated in time.
Proposed resolution: revise 1.3.1 after contacing Shawn for specifics.
Proposed Resolution: Thank you. As you know we cannot change the guidelines or success criteria. But nor broaden their interpretation beyond the way they were interpreted when WCAG consensus was reached.
However, if you think that the Understanding WCAG 2.0 can be made clearer without broadening or narrowing the interpretation, please submit the language right away so we can consider it for our next release.
(Please make sure the resolution is adapted for public consumption)
Comment LC-2513 : Conflict between alternative options 1-4 and F69
Commenter: Detlev Fischer <fischer@dias.de> (archived message ) Context: Resize text: Understanding Success Criterion 1.4.2
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Adam Solomon
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :The "How to meet" document offers four alternative options to meet SC 1.4.4 (Resize Text), one of them simply "G142: Using a technology that has commonly-available user agents that support zoom". F69, on the other hand, describes the failure of clipping , truncating or obscuring text when applying text-only magnification to 200%. It seems that the How to meet" document should link support for page zoom to a (perhaps more modest) support for text-only zoom. Just affording page zoom (this works nearly always without any extra effort) does not prevent the failure 69 when scaling text only.
Proposed Change:
Change logic in the "How to meet" document: G142 alone is not good enough. In addition, text-only resizing must also work to ensure a pass of F69.
Related issues: (space separated ids)
WG Notes: Discussed 8/18. Need to revise response, Kathy Wahlbin will propose zoom-related examples for F69. [Done]
ACTION-162 Adam will updated proposal and do email call for objections
Resolution: Thank you for your comment. The title of F69 does not specifically mention text-only magnification. It can refer to zoom magnification as well. It parallels the language in the title of the success criterion itself, which mentions text resizing. Just as the title of the success criterion does not exclude zoom magnification as a means to resize text, so too the title of the failure does not exclude zoom magnification in that respect. The failure, therefore, applies equally to situations where text resize or zoom might be applied.
However, as indicated in your comment, the examples provided do in fact resize correctly with zoom, and we must therefore amend the failure document to indicate that those failure examples apply only in an environment where zoom functionality is not available. Furthermore, we have added an additional example of failure when using zoom.
Regarding requiring support for text-resize in this criterion, the group has discussed this issue at length and has concluded that zoom functionality is sufficient to meet this success criterion.
[DONE] Add http://www.w3.org/WAI/GL/wiki/F69_Example as a third example. Add text in the description to indicate that this failure applies to both text resize and zoom resize, and that support for either is sufficient to avoid the failure. Add text in the first two examples which states clearly that they fail only in environments which do not support zoom functionality. (Please make sure the resolution is adapted for public consumption)
editorial comments
Comment LC-2573 : Editorial changes to Understanding Conformance
Commenter: Shawn Henry <shawn@w3.org> (archived message ) Context: Understanding Conformance (Level of Assistive Technology Support Needed for "Accessibility Support")
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Under Level of Assistive Technology Support Needed for "Accessibility Support" list item 1 says: Accessibility support of Web technologies varies by environment
- In a company where all employees are provided with particular user agents and assistive technologies, Web technologies may need to only be supported by those user agents and older assistive technologies.
- Content posted to the public Web may need to work with a broader range of user agents and assistive technologies.
"
I think the "older" is incorrect in the first bullet. I think it should be deleted. (because the point is that if users are known to have certain AT, then you do *not* have to support older AT, yes?)
To further clarify, consider adding it to the second sub-point.
Proposed Change:
...Web technologies may need to only be supported by those user agents and assistive technologies.
Content posted to the public Web may need to work with a broader range of user agents and assistive technologies, including older versions.
Related issues: (space separated ids)
WG Notes:
Resolution: Thank you for catching this. We have edited the document as follows:
[DONE] Web technologies may only need to be supported by those specific user agents and assistive technologies deployed at a company. (These may be older versions of user agents and assistive technologies or the very newest versions).
Content posted to the public Web may need to work with a broader range of user agents and assistive technologies, including older versions. (Please make sure the resolution is adapted for public consumption)
Add a comment .