List of comments on “Techniques for WCAG 2.0” (dated 14 October 2010)

There are 45 comments (sorted by their types, and the section they are about).

1-20 21-40 41-45

question comments

Comment LC-2467: H82 missing?: Commenter: Tomas Caspers <tcaspers@mac.com> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Is there a reason why Technique H82 is missing from the latest versions or is this an oversight?; Related issues: (space separated ids); WG Notes:; Resolution: The last version of the techniques document that contained H82 was the 30 April 2008 Working Draft, and the contents of that technique are now contained in H71: Providing a description for groups of form controls using fieldset and legend elements. We believe that there were once two similar techniques that were merged, but since H82 had been published in earlier drafts, the technique number H82 is not reused to avoid any confusion when searching for the technique.; (Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2431: G93: SC 1.2.4: Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message); Context: G93: Providing open (always visible) captions; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Comment (Including rationale for any proposed change):
It should have links to SC 1.2.4 documents as G93 is listed as one of the sufficient techniques on Understanding SC 1.2.4.

http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-real-time-captions.html#media-equiv-real-time-captions-techniques-head

Proposed Change:
Add links.; Related issues: (space separated ids); WG Notes:; Resolution: Thank you A link to SC 1.2.4 is now in G93; (Please make sure the resolution is adapted for public consumption)

Comment LC-2430: G97: Only "immediately following the expanded form"?: Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message); Context: G97: Providing the abbreviation immediately following the expanded form; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Is "WAI(Web Accessibility Initiative)" NOT acceptable to meet SC 3.1.4? This also can be used "to make the expanded form of an abbreviation available by associating the expanded form with its abbreviation". In Japanese, this is usually used to provide its expanded form.

Proposed Change:
If acceptable, please add the description to G97. If not acceptable, JIS might need to have different criterion from WCAG 2.; Related issues: (space separated ids); WG Notes: BB: Changed "first instance of" to "first use of" (plain language).; Resolution: Yes - that would be acceptable. We will add your example to the examples: "The WAI (Web Accessibility Initiative) demonstrates the W3C commitment to accessibility." Change "G97: Providing the abbreviation immediately following the expanded form" to "G97: Providing the first instance of an abbreviation immediately before or after the expanded form" ---- Change procedure step 2 from "2: Check that the first use is immediately preceded by the expanded form of the abbreviation." to "2: Check that the first use is immediately preceded or followed by the expanded form of the abbreviation." ---- We think this technique would benefit from further rework based on the issues you raised. We invite you to submit a proposed edited technique.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2428: G150: procedure and policy: Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message); Context: G150: Providing text based alternatives for live audio-only content; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Comment (Including rationale for any proposed change):
Procedure #1 reads "Check that a procedure and policy is in place to ensure that text alternatives are delivered in real-time." Does this technique require having the procedure and policy only? Can we meet SC 1.2.9 by only having them? This technique should ensure that the text based alternatives for live audio-only content are provided.

Proposed Change:
Need clarification.; Related issues: (space separated ids); WG Notes:; Resolution: Thank you We have changed the procedure to Procedure 1) Check that a procedure and policy is in place to ensure that text alternatives are delivered in real-time 2) Check that procedure and policy are working by checking a random sample to see if ALT TEXT appears. Expected Results Both #1 and # 2 are true ACTION: add step 2 and revise expected result; (Please make sure the resolution is adapted for public consumption)

Comment LC-2469: SCR19 applies to SC 3.2.2 too: Commenter: Sailesh Panchang <spanchang02@yahoo.com> (archived message); Context: SCR19: Using an onchange event on a select element without causing a change of context; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I believe SCR 19 helps one to comply with SC 3.2.2 too.
SCR19: Using an onchange event on a select element without causing a change of context
At present this technique is only linked to SC 3.2.5. But if one reads the description and examples for SC 3.2.2, the need for the suggested linkage will be clear.; Related issues: (space separated ids); WG Notes:; Resolution: Thanks for catching that. We have added SC 3.2.2 Action: Add SCR19 as a sufficient technique for SC 3.2.2; (Please make sure the resolution is adapted for public consumption)

Comment LC-2432: SM7: Expected Results: Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message); Context: SM7: Providing audio description in SMIL 2.0; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Expected Results should be "#3 is true." as well as SM6.

Proposed Change:
Change it to read "#3 is true."; Related issues: (space separated ids); WG Notes:; Resolution: Thank you. It is done.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2491: F9 also relates to SC 3.2.2 On Input, not just 3.2.5 (Change on Request): Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: F9: Failure of Success Criterion 3.2.5 due to changing the context when the user removes focus from a form element; Status:
assigned to David MacDonald; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The behaviour described in F9 - changing context such as opening new windows or submitting the form - also seems to apply to the requirements of SC 3.2.2 "On Input".
The behaviour described: "removing focus from a form element, such as by moving to the next element, causes a change of context" is arguably even more disrupting than the more specific Failure F36: "Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value" - in the latter, the form might at least have been completed.

Proposed Change:
Extend applicability of F9 to SC 3.2.2 On Input AND SC 3.2.5 Change of Request; Related issues: (space separated ids); WG Notes: Per http://www.w3.org/2011/07/28-wai-wcag-minutes.html#item03, David MacDonald to revise F9 for future discussion, and leave this issue open. Consensus: this is not a failure of 3.2.1 either.; Resolution: As written, this failure does not apply to 3.2.2, since changing focus is not an input action.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2492: F60 may either apply also to SC 3.2.2 (On Input) or need further specification (context change announced/expected, window type): Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: F60: Failure of Success Criterion 3.2.5 due to launching a new window when a user enters text into an input field; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Opening a new window as a result of user text input is clearly an unexpected change of context and would seem to violate not just SC 3.2.5 (Change on Request) but also the A-level SC 3.2.2 (On input)

Proposed Change:
Either:
* Preferably, make F60 applicable also to SC 3.2.2 (On Input)
* Specify that the change in response to text input should be expected / explained before it occurs, include that in the test procedure
* Differentiate between opening a new window proper (i.e., a browser window) and opening a pseudo-window (e.g. a lightbox) which would not necessarily constitute a (disorienting) change of context; Related issues: (space separated ids); WG Notes: Prior proposal: As the comment suggests, F60 should indeed apply to SC 3.2.2 as well. The understanding document for SC 3.2.2 specifically mentions entering text into a text field, and therefore F60 represents a failure for that criterion. @@Proposed resolution: Link F60 to SC 3.2.2. Also, change the following words "for other than error reporting" in the description, to "for anything other than error reporting".; Resolution: We do not feel that F60, as written, should be a failure of SC 3.2.2, but it is causing us to discuss issues related to text fields and SC 3.2.2. We will be discussing potential modification to F37 or adding new failures for SC 3.2.2. We have added an action (ACTION 150, http://www.w3.org/WAI/GL/track/actions/150) for you to help us draft this new failure or modify F37. We are not adding this failure for this update, since it will need to go to public review and the review period for this update has ended.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2427: F61: 24 hours?: Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message); Context: F61: Failure of Success Criterion 3.2.5 due to complete change of main content through an automatic update that the user cannot disable from within the content; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Procedure #2 reads "leave the content open for 24 hours". I can live with this, but leaving the content open for 24 hours is not a realistic way. 1 hour or even half an hour would also be fine.

Proposed Change:
Why "24 hours"?
Had better change it so that the authors can test the content in reality.; Related issues: (space separated ids); WG Notes: http://www.w3.org/2002/09/wbs/35422/20110127misc/results#x2427 ACTION-122 to provide revised test procedure; Resolution: People often take many hours to complete a page. Having it change on them unexpectedly in 30 minutes or an hour is not acceptable. if it changed at 90 minutes that should be detected. Only checking for 30 minutes would miss this. 24 hours is more than enough time to check that there is not a timed refresh. 30 or 60 minutes is not enough. We chose 24 hours because that gave the user a day to complete task. We realize that there is no time period that guarantees that the data will NEVER be updated automatically. We have updated the technique to provide more flexibility in the testing approach. [DONE] Modify technique per http://trace.wisc.edu/wcag_wiki/index.php?title=F61:_Failure_of_Success_Criterion_3.2.5_due_to_complete_change_of_main_content_through_an_automatic_update_that_the_user_cannot_disable_from_within_the_content; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2496: "should" vs "must": Commenter: Glenda Sims < glenda.sims@deque.com> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
It might be useful to clearly indicate the definition of the words "should" and "must" for the purpose of requirements versus recommendations. This would apply to all parts of WCAG 2.0. I mentioning it here on this technique (G141), because this is where I recently had a debate about what "should" means versus what "must" means.

Proposed Change:
Make it obvious that "should" is recommended while "must" is required. You could use the definitions found at http://www.ietf.org/rfc/rfc2119.txt. You could also consider making the words "must" and "should" hotlink to the definition. Or, not. Just an idea.; Related issues: (space separated ids); WG Notes: I think this is a useful observation. Although we do not use these terms in a non-standard way, there has been some confusion and this is found in policy, and in automated evaluation tools where "shoulds" become "musts" ... I think we should add a paragraph The "understanding conformance." http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head says "This section will be expanded over time to address questions that may arise or to provide new examples of ways to meet the different conformance requirements." Add after the paragraph that says "The note points out that authors are encouraged to go beyond conformance to a particular level and to complete, and report if they desire, any progress toward higher levels of conformance. <Add new paragraph> The words MUST, SHOULD and MAY found in the WCAG docments are the standard use of those words as they are found in standards. (See http://www.ietf.org/rfc/rfc2119.txt) The word "must" means something is "required" within the context the section it is found. If it appears in a Success Criteria then the condition is required to meet the Success Criteria. If it is found in a technique, then the condition is required to successfully implement the technique. (Note: if "must" appears in a technique, it is important to understand that although it is necessary to meet the technique, that does not mean the technique is necessary to meet the Success Criteria. There may be other techniques which can be used to meet the Success Criteria that do not employ that technique and therefore the "musts" found in that particular technique may not be required to successfully meet that specific Success Criteria.) The word "should" indicates that a condition is "recommended" but <em>not</em> required. </add> Proposed response: Thanks you Glenda for the recommendation. We have updated the "Understanding Conformance" section of the Understanding Document to introduce a discussion of SHOULD vs MUST. It will read as follows: [insert text above]. Recommended Action @@ Add the above paragraph to the "Understanding Conformance Document" as indicated above. We have added a discussion of the uses of "must" and "should" in techniques to the introduction to the Techniques document. We hope that this will clarify interpretations of the techniques. We are not using RFC 2119 in our standard because it cannot be applied in a standard like ours with 3 levels of conformance. Please let us know whether this still leaves misinterpretations in our uses of these terms.; Resolution: We have added a discussion of the uses of "must" and "should" in techniques to the introduction to the Techniques document. We hope that this will clarify interpretations of the techniques. We are not using RFC 2119 in our standard because it cannot be applied in a standard like ours with 3 levels of conformance. Please let us know whether this still leaves misinterpretations in our uses of these terms.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2456: Reword G1 'Description' and 'Note'. (This will make "Skip to Main" as a permanent visible link): Commenter: Devarshi Pant <devarshipant@gmail.com> (archived message); Context: G1: Adding a link at the top of each page that goes directly to the main content area; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I think it is time that G1 along with the "NOTE:" at the end of the description be modified and made more forceful. Presently, it does not give the impression that the "Skip to..." MUST be visible. I would like to see the description reworded to make it more assertive.
*******************
Currently, G1 with the note (and the ensuing wording), comes across as a weak technique.
*******************

Proposed Change:
The objective of this technique is to provide a mechanism to bypass blocks of material that are repeated on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a VISIBLE link to the beginning of the main content. Activating the VISIBLE link sets focus beyond the other content to the main content. This technique is most useful when a Web page has one main content area, rather than a set of content areas that are equally important.

Note: VISIBLE LINKS MUST BE VISIBLE AT ALL TIMES, ESPECIALLY for KEYBOARD USERS. KEYBOARD USERS INCLUDE switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.

Also: http://lists.w3.org/Archives/Public/public-comments-wcag20/2010Sep/0023.html
Update on my earlier post - G1: Adding a link at the top of each page that goes directly to the main content area

I think the verbiage with the word "Must" would be incorrect in my previous post.

Sorry about that...

thanks,
Devarshi

Proposed Change:
please note the updated text (changes highlighted in UPPERCASE):

*********************
The objective of this technique is to provide a mechanism to bypass REPETITIVE NAVIGATION MENUS AND OTHER PAGE ELEMENTS on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a VISIBLE link to the beginning of the main content. Activating THIS link sets focus INTO ONE OF THE PAGE ELEMENTS IN THE main content AREA. This technique is most useful when a Web page has one main content area, rather than a set of content areas that are equally important.

Note: Visible links are IMPORTANT for USERS navigating with a keyboard including switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.
*********************; Related issues: (space separated ids); WG Notes: Here is the current wording The objective of this technique is to provide a mechanism to bypass blocks of material that are repeated on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a link to the beginning of the main content. Activating the link sets focus beyond the other content to the main content. This technique is most useful when a Web page has one main content area, rather than a set of content areas that are equally important, and when there are not multiple navigation sections on the page. Note: Visible links are necessary for those navigating with a keyboard including switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software. Examples Example 1: An online newspaper An on-line newspaper contains many sections of information: a search function, a corporate banner, sidebars, minor stories, how to contact the newspaper, etc. The lead story is located in the middle of the page. The first link that the user reaches when tabbing through the page is titled "Skip to Lead Story". Activating the link moves visual focus to the story. Pressing tab again takes the user to the first link in the main story. Example 2: A "Skip to main content" link A Web page includes a variety of navigation techniques on each page: a bread crumb trail, a search tool, a site map, and a list of related resources. The first link on the page is titled "Skip to Main Content". A user activates the link to skip over the navigation tools. Resources === http://www.w3.org/2002/09/wbs/35422/20110127misc/results#x2456 ACTION-123 Loretta to revise response in accordance with survey results Might want a stronger alternative technique but don't have anyone to write yet.; Resolution: Although we agree that using visible links is best practice, we included this technique in its current form to make it clear that links that are only visible when they have focus are sufficient. We are modifying the note in G1 to clarify both that visible links are best practice and that this technique only requires that they be visible at least when they have focus. A technique that requires visible links, such as you propose, would also be sufficient, of course. We do not have the resources to write additional techniques at this time, but would welcome the submission of a separate technique for using visible links to skip to main content. Proposed Change: Note: IT IS PREFERABLE FOR LINKS TO BE VISIBLE AT ALL TIMES, SINCE USERS NAVIGATING VIA THE KEYBOARD INCLUDE switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software. HOWEVER, SUCCESS CRITERION 2.4.1 DOES NOT REQUIRE THAT THEY BE VISIBLE WHEN THEY DO NOT HAVE FOCUS, AND LINKS THAT ARE VISIBLE ONLY WHEN THEY HAVE FOCUS CAN MEET THIS SUCCESS CRITERION.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2438: Test in G68 does not seem to fit: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G68: Providing a descriptive label that describes the purpose of live audio-only and live video-only content; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
I have noticed a discrepancy between Technique "G68: Providing a descriptive label that describes the purpose of live audio-only and live video-only content" and the test included at its end.

While the technique proposes the use of descriptive labels which are exposed to sighted users, the test at the end checks for text alternatives for non-text content that would only be exposed if the not-text content cannot be displayed.

I think the currently included test does not apply to the technique as described.

Proposed Change:
New Test
Check whether descriptive label matches / correctly describes live audio-visual content; Related issues: (space separated ids); WG Notes: Here is G68 This technique provides a descriptive label for live audio-only and live video-only content. This label may be used in combination with an alternative for time-based media for audio or an alternative for time-based media or audio description of the video. Those alternatives however are not part of this technique. The purpose of this technique is to ensure that the user can determine what the non-text content is - even if they cannot access it. NOTE: Even if full alternatives are also available, it is important that users be able to identify the non-text content when they encounter it so that they are not confused, and so that they can associate it with the full alternative when they encounter it. Examples Example 1 A live video feed of the east coast highway has the following descriptive label "Live video picture of East Coast Highway just south of the I-81 interchange showing current traffic conditions." A live audio feed of the Mississippi House of Representatives has the following descriptive label "Live audio from the microphones in the Mississippi House of Representatives." Resources Resources are for information purposes only, no endorsement implied. Related Techniques G100: Providing the accepted name or a descriptive name of the non-text content Tests Procedure 1 remove, hide, or mask the non-text content 2 display the text alternative(s) 3 check that the purpose of the non-text content is clear - even if content is lost. Expected Results #3 is true. HERE is the definition of Label label text or other component with a text alternative that is presented to a user to identify a component within Web content Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same. Note 2: The term label is not limited to the label element in HTML. === http://www.w3.org/2002/09/wbs/35422/20110127misc/results#x2438 ACTION-124 Adam to revise proposal in accordance with survey results; Resolution: We consider that ALT text is a sufficient label for non-text content per this definition of Label. The purpose of this technique is to be sure that people who cannot see know what the non-text content on the screen is. If the person can see, presumably they can identify the nontext content by looking at it. The technique as written would ensure that people who cannot see are able to determine what the nontext content is via its alternative text. The only reason that the text is removed in the example is simply to see if the alternative text really did stand in for the function. We think the use of the word "label" in this technique may be confusing, since label is often used to mean visible text that identifies a control. We are revising the technique to clarify this issue. Change the title of G68 to be "Providing a short text alternative which describes the purpose of live audio-only and live video-only content" In G68, change the following beginning of the description to read: "This technique provides a short text alternative for Live audio-only and live video-only content. This text may be used in combination with a full alternative for time-based media (for audio or video), or in combination with audio description (for video). Revise test procedure to read: 1. Remove, hide, or mask the non-text content. 2. Display the short text alternative(s). 3. Check that the purpose of the non-text content is clear - even if content is lost. For consistency of terminology, change the title, examples, and test procedure of G100 per http://trace.wisc.edu/wcag_wiki/index.php?title=G100:_Providing_a_short_text_alternative_which_is_the_accepted_name_or_descriptive_name_of_the_non-text_content; (Please make sure the resolution is adapted for public consumption)

Comment LC-2439: either/or test seems incorrect: #2 must be true: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G98: Providing the ability for the user to review and correct answers before submitting; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The first of the conditions may not apply (for example if the for is on one page). The second condition ("Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary.") must be met in any case to ensure that input is checked and may be corrected. Therefore "Expected Results: Either #1 or #2 is true" seems inadequate.

Proposed Change:
1. If user data are collected in multiple steps, the user is allowed to return to previous steps to review and change data.

2. Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary.

Expected Results

Checks #1 and #2 are true.

To remove the conditional (and possibly confusing) 'if'-clause at the beginning of check #1, the single test might need to be turned into two separate tests.; Related issues: (space separated ids); WG Notes: CURRENT TEXT Procedure In a testing application or one that causes financial or legal transactions to occur and that also collects data from users in multiple steps: 1) Determine if the user is allowed to return to previous steps to review and change data. 2) Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary. Expected Results Either #1 or #2 is true.; Resolution: Depending on how much data is collected, it may not be possible to summarize it all on one page. For example if the person was taking an essay exam. Therefore either one of these two approaches may be the most logical. insert new step 1 to test procedure: "Check that user is prompted to review the data and confirm" reword existing steps: "2. If user data are collected in multiple steps, the user is allowed to return to previous steps to review and change data. 3. Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary." change expected results to be "Either #2 or #3 are true"; (Please make sure the resolution is adapted for public consumption)

Comment LC-2441: Test does not cover appropriateness of audio description: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G166: Providing audio that describes the important video content and describing it as such; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
As it stands, the test in technique G166 only checks whether a link to the audio alternative is provided. It does not check the equivalence of the audio alternative. Testing just for the link is not sufficient

Proposed Change:
Add a second checkpoint #2 for checking whether the audio alternative is adequate.
Both Check #1 and Check #2 must be true.; Related issues: (space separated ids); WG Notes: Current wording: Procedure For a Web page that contains video-only content: Check that there is link to an audio alternative immediately before or after the video-only content. Expected Results Check #1 is true.; Resolution: We do not include any quality checks in our techniques since they are subjective. â€œAdequateâ€ is not a testable term. Unfortunately, we do not feel it is possible to include subjective terms in our testing procedures. We have clarified the test procedure to indicate that it should be descriptive. ACTION: Change step 1 of test procedure to read "Check that there is link to an audio alternative which describes the contents of the video immediately before or after the video-only content."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2442: Missing explicit requirement that styleswitcher be positioned at the top of the page: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The text of this technique describes in both examples provided that the styleswitcher should be at the "top of the page". This requirement, however, is neither included in the description nore is it checked in the test section of the technique.

Proposed Change:
Add a further (fourth) requirement for the technique to be used successfully, preferably in second place:

"2. The link or control on the original page must be placed at the top of the page"; Related issues: (space separated ids); WG Notes:; Resolution: This technique does not require that the style switcher be at the top of the page. This is just good practice and therefore we included it in the examples to encourage it. It is therefore not in the technique nor in the test criteria. However, we have added a note about this in the description. ACTION: Add to end of first paragraph of description: "Placing the link or control prominently on the page will assist users in accessing the conforming content readily."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2465: Test needs specification of window size and criteria for compliance: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The test as it stands is not particularly useful as it does not specify the viewport size, which will have an effect on scalability and occurrence of clipped text and text overlapping. It also does not specify what it means that "text size can be increased to 200% of the original size" - is the requirement that the text is still legible / not clipped?

Proposed Change:
If the test is to determine whether enlarged text is still usable / legible (and this is the only meaningful test), the viewport / window size to be used in the test must be specified (WAT and Web developer toolbar allow the setting of the window to 1024 x 768 px, for example), and criteria for compliance must be given (e.g. "the text is still fully legible (i.e. no parts are clipped, boxed do not overlap).; Related issues: (space separated ids); WG Notes: See http://www.w3.org/2002/09/wbs/35422/20110127misc/results#x2465; Resolution: Good points. The goal is to increase the text size in the expected viewport size, that is, the viewport size for which the content was designed. Of course, this will depend on the designer's expectations of the devices available to the user. However, the tester has no way to reliably determine those expectations. Using a viewport size that is smaller than expected can produce incorrect failures. For testing purposes, we have selected "1024 x 768 or larger" as the expected viewport size, so the initial step in the procedure is now Set the viewport size to 1024px x 768px or larger". Note that this does not ensure legibility of the text. Depending upon the characteristics of the device and the design of the page, text many be very small physically. However, it gives us a basis on which to compare functionality with the enlarged text version. We have also added an additional test step to clarified what must be true after increasing the text size: Check that after increasing the text size to 200% of the original size, there is no loss of content or functionality (e.g. no parts of the text are clipped, boxes do not overlap, controls are not obscured or separated from their labels, etc); (Please make sure the resolution is adapted for public consumption)

Comment LC-2466: equirement for 200% text increase nearly impossible to meet in most cases: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
In addition to the comment regarding the test case spec. in G178, it should be noted that for most web pages using several columns, the requirement for a 200% increase of text size will be impossible to meet (the same goes for browser based text-only resizing) and is therefore likely to be ignored. Such ignorance is helped by the interpretation of alternative options to meet Success Criterion 1.4.4 (Resize text), since option 1 (G142) suggests that supporting zoom resizing (which most modern browsers offer out of the box without any effort by the designer) is already sufficient. This appears as a disincentive regarding the provision of text-only resizing and the additional effort of creating fluid layouts that resize gracefully.

Proposed Change:
The (additional) requirement to allow a more modest text-only resizing (say, 150%) might raise the bar in a meaningful way and not de-incentivise designers in the same way as the current all-to-easy way of meeting success criterion 1.4.4 *without any effort*.; Related issues: (space separated ids); WG Notes:; Resolution: If the two columns are equal in width then it is impossible to not meet this criteria with ZOOM. Simply increase the zoom to 200% and the column will fit very nicely on-screen and allow the user to read all of the text in the column without horizontal scrolling. They can then move over to the other column and read the other, without horizontal scrolling as well. Note that the horizontal scrolling requirement is only at level AAA. Therefore the zoom would satisfy level AA unless of course the browser does not support this. Therefore this technique would work at level AA but not at level AAA for a full width page, but it would work at AAA for a page with 2 equal width columns. You will note that G178 is listed as sufficient for 1.4.4 which is at level AA but it is not listed as sufficient for 1.4.8 which is at level AAA.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2443: The test should include a check whether the function to turn off blinking content is documented: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G187: Using a technology to include blinking content that can be turned off via the user agent; Status:
assigned to Bruce Bailey; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Following the provision of Technique G4: "If keyboard shortcuts are used, they are documented" the test in G187 should include a check whether the function to turn off blinking content is documented (e.g., press the "Escape" key to turn off blinking)

Proposed Change:
Add a fourth checkpoint and extend the final statement:

4. Check if the browser's stop animation command (usually the Escape key) is described in the immediate context of the blinking content.

Check #3 and #4 are true.; Related issues: (space separated ids); WG Notes:; Resolution: We only state that they should be documented, not that they should be in the immediate context of the blinking content. For example this might be documented on the opening page of a long document full of things that blink. In fact the switch to turn off the blinking may occur at the front so that it turns off all of the blinking on all of the pages at once. Also, all the techniques are optional. If G4 and G187 are both required then there's no need to put the requirement G4 in G178. If they are not both required then G4 stands as a separate technique. We don't embed techniques and other techniques if they are not needed. Add to end of first para of G187 description: "This feature can be provided either through interactive controls that conform to WCAG or through keyboard shortcuts. If keyboard shortcuts are used, they are documented."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2444: Test does not check top position of link or mechanism: Commenter: Detlev Fischer <fischer@dias.de> (archived message); Context: G191: Providing a link, button, or other mechanism that reloads the page without any blinking content; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The example of technique G191 makes it clear that the link or mechanism to load a non-blinking version of the page should be at the top of the page:

"A link at the very top of the page reloads the page with the blinking text replaced with text that is styled to be highly visible but does not blink"

Proposed Change:
Include a check that the mechanism is located at the top of the page - placed elsewhere, it is not helpful. Instead of
"1. Check that there is a mechanism to reload page to turn off blinking."

change to:

"1. Check that there is a mechanism at the top of the page to reload page to turn off blinking.; Related issues: (space separated ids); WG Notes:; Resolution: This technique does not require that the control be at the top of the page. This is simply good practice so we included it in both of the techniques to encourage it. However since it is not required for the technique, it is in neither the description nor the test.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2500: Re: HTML Headings technique: duplicated: H42 and H69: Commenter: Sailesch Panchang <spanchang02@yahoo.com> (archived message); Context: H42: Using h1-h6 to identify headings (and H69); Status:
assigned to Michael Cooper; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
See old exchange on this topic below.
Now I refer to Techniques working draft (latest) of Oct 2010.
See http://www.w3.org/TR/WCAG20-TECHS/html.html
H42 refers to proper use of headings for SC 1.3.1 and H69 for use of headings to skip blocks (SC 2.4.1).
But part of the description under H69 which was correctly placed under h42 is now moved to h69... and is completely out of place.
Refer to:
"In some technologies, headings are designed to convey logical hierarchy. Skipping levels in the sequence of headings may create the impression that the structure of the document has not been properly thought through or that specific headings have been chosen for their visual rendering rather than their meaning. Authors are encouraged to nest headings hierarchically. When headings are nested hierarchically, the most important information is given the highest logical level, and subsections are given subsequent logical levels.(i.e., h2 is a subsection of h1). ..."
Again this Web page is about HTML techniques so why does this description start with "In some technologies"? Does it apply to HTML / XHTML or not?
And the note for example #2 of H42 refers to skipping blocks of content.
Refer to:
"Note: It is important to note that the example code below is intended to show how headings can be used to bypass blocks of information. It is not intended to prescribe what level of heading should be used for a particular section of the web page."
So why is this note and example under H42?
Completely out of place again.

The technique is one and the same: proper use of headings. And it serves two purposes and SCs. So merge the techniques into one instead of running around in circles. I had suggested this in 2009.
There are several techniques that refer to multiple SC. So I fail to understand your resistance for this one.

Sailesh Panchang
Web Accessibility Specialist
www.deque.com

--- On Mon, 12/1/08, Loretta Guarino Reid <lorettaguarino@google.com> wrote:

From: Loretta Guarino Reid <lorettaguarino@google.com>
Subject: Re: HTML Headings technique: duplicated
To: "Sailesh Panchang" <spanchang02@yahoo.com>
Cc: public-comments-wcag20@w3.org
Date: Monday, December 1, 2008, 5:58 PM

On Fri, Nov 14, 2008 at 1:23 PM, Sailesh Panchang <spanchang02@yahoo.com> wrote:

H42: Using h1-h6 to identify headings

relates to SC 1.3.1

H69: Providing heading elements at the beginning of each section of content

relates to SC 2.4.1

Comment: Both descriptions are essentially the same. I suggest they be merged into a single technique and reference both SC

Thanks,

Sailesh Panchang

================================
Response from the Working Group
================================

H42 should describe the use of heading mark-up to label headings semantically, but also contained a good deal of discussion about how to use headings. We have moved the discussion and examples of ways to use headings to organize content from H42 to H69. See http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H42.html and http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H69.html .; Related issues: (space separated ids); WG Notes: Removed proposal to require nested headings. Move (copy?) Example 2 of H42 to H69. (adam) 08192011 revised response. After looking over example 2, decided it was relevant to H42, just need to remove the words "bypass" etc. from the note. Rest of comment also addressed; Resolution: Re: Discussing heading hierarchy in the description: H69 involves providing heading elements in order to fulfill SC 2.4.1. It is more relevant to advise the author to properly nest headings (even though it is not required here), since the author is adding content and can possibly affect the heading hierarchy. H42, on the other hand, involves proper semantic notation of currently existing headers. In such a case, it is less likely the author will be able to affect the heading hierarchy. Please note in any event, that even in H69, nesting headers is only advisable and not required. Re: the words "in some technologies": The technique does relate to HTML and therefore the words "in some technologies" can be removed. Re: Example #2 note: The comment is correct in that mentioning "bypass blocks of navigation" in the note is not relevant here, yet the example certainly is, as well as the note itself, which relates to choice of markup, and this technique is about correct markup. Therefore, we should remove the above words from the note, and leave the example as is. Re: Merging the two techniques: The usage of headers in these techniques are not identical. H42 involves proper semantic markup, while H69 involves adding headers to the content. Therefore, they should not be merged. [DONE] Proposed Resolution: 1. Remove "in some technologies" from the description, so that the paragraph begins "Headings are designed to convey..." 2. Remove the reference to bypassing blocks of navigation in the note to example #2, so that is starts out "It is important to note that the example code below is not intended to prescribe what level of heading should..." 3. Update UA notes for H69 per http://lists.w3.org/Archives/Public/w3c-wai-ig/2011JulSep/0177.html. No other changes to be made.; (Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-45

Add a comment.