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

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

1-20 21-21

question comments

Comment LC-2472: Sufficient techniques- definition and guidance: Commenter: Sailesch Panchang <spanchang02@yahoo.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 this guidance contradictory and confusing?

"How to meet WCAG 2.0" doc states:
"Authors are encouraged to apply all techniques that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users".

On the other hand, refer to "Sufficient and Advisory Techniques" under Intro to Understanding WCAG 2.0, which states:
"In order to provide guidance and examples for meeting the guidelines using specific technologies (for example HTML) the working group has identified sufficient techniques for each Success Criterion that are sufficient to meet that Success Criterion. Sufficient techniques are provided in a numbered list where each list item provides the technique or combination of techniques that can be used to meet the Success Criterion".
"Most Success Criteria have multiple sufficient techniques listed. Any of the listed sufficient techniques can be used to meet the Success Criterion".

So in the above, one doc says any one technique is sufficient and the other doc encourages more than one technique to be implemented. So which is it. I do realize one uses "encourages". But:
Specifically, consider SC 2.4.1 for skipping blocks of content:
There are two groups of sufficient techniques: one for an actual skip nav link and the other set for proper structural markup like heading, frames, etc.

One may conclude that if headings are implemented (H69) of group#2 of sufficient techniques, then SC 2.4.1 is met.
But user agent notes for H69 acknowledge that this does not work in all situations. The actual skip nav link technique does work for a wider set of situations.

Then are individual techniques of the second group really sufficient?
So while group# 2 of the sufficient techniques for SC 2.4.1 is helpful and enhances navigation abilities, they are not sufficient by themselves given today's user agent scenario.

As for me, besides skip nav, I recommend headings and use of landmark roles too to clients.

Please can you share your thoughts?; Related issues: (space separated ids); WG Notes:; Resolution: You seem to have interpreted it correctly. - You CAN use just one of the techniques and you would meet the absolute REQUIREMENTS for the success criterion. - However, that is not all you can do in many situations. There are other things you can do beyond the minimum needed to pass the success criteria. And we encourage people to go beyond the minimum. As to part 2 of your question, if you know that a technique will not work, then you should not use it. However, there are always grey areas where a developer many not know if current user agents support something even though many do or future ones would. In this case the Working Group's decisions on sufficiency can be helpful to the developer. That is the case here. In the end though, if you know that there are no AT that will work with the described technique the way you are using it (or in the context you are using it), then you should not use it because the accessibility support requirement of the conformance requirements would not be met.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2454: WCAG 2 conformance claim: validating code: Commenter: Sailesh Panchang <spanchang02@yahoo.com> (archived message); Context: Parsing: Understanding SC 4.1.1; 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:
SC 4.1.1 requires limited validity checks for markup: unique ID values, proper tag nesting and closing and a check for duplicate attributes.

However, the WCAG 2 Understanding documentat suggests that conformance claim could include something along the lines of:
"The documented set of accessibility-supported content technologies relied upon for this claim includes XHTML 1.0 (Transitional), CSS 2 and JavaScript 1.2. "
Refer: example conformance claims on http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head
Does this imply that one can make such a statement only after ensuring that markup / CSS / JS code is valid?
Please clarify whether validating the code for CSS / JS / XHTML beyond what is suggested in SC 4.1.1 is required for a conformance claim if for instance, all three technologies are used.; Related issues: (space separated ids); WG Notes:; Resolution: No, this just says that you depend on those technologies in making your claim. That just tells the user that if they use a browser that doesnâ€™t support JS or CSS the page might not be accessible. In the spirit of success criterion 4.1.1, any modifications made to the DOM should also preserve these same properties, e.g., elements properly nested, no duplicate IDs, etc.; (Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2429: SC 3.2.1 Keyboard users only?: Commenter: Makoto Ueki <makoto.ueki@gmail.com> (archived message); Context: On Focus: Understanding SC 3.2.1; 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:
SC 3.2.1 uses "focus", not "keyboard focus". My understanding is that this SC is applied to mouse focus as well. However "Examples of Success Criterion 3.2.1" and the one and only Sufficient Technique G107 mention only keyboard users. This could mislead readers to misunderstand that this SC is applied to keyboard use only.

Proposed Change:
If this SC is also applied to mouse users, for example, please add a failure about it. "When a user moves the focus to a text field by clicking on it, a new window or a popup window is opened." or something like that.

Also having a note which explains that mouseover doesn't move focus to the element would be helpful.; Related issues: (space separated ids); WG Notes:; Resolution: This provision only applies to keyboard focus not to the mouse cursor. We will add the following to Understanding 3.2.1: Focus may be moved to a control either via the keyboard (e.g. tabbing to a control) or the mouse (e.g. clicking on a text field). Moving the mouse over a control does not move the focus unless scripting implements this behavior. Note that for some types of controls, clicking on a control may also activate the control (e.g. button), which may, in turn, initiate a change in context.; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2462: Understanding WCAG 2- SC 1.3.1: Commenter: Sailesh Panchang <spanchang02@yahoo.com> (archived message); Context: Info and Relationships: Understanding SC 1.3.1; 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:
Under Intent it states:
â€œit may be most appropriate to duplicate some information (for instance, in an HTML table, providing the summary both in the paragraph before the table
and in the summary attribute of the table itself).â€
Comment: Not sure why summary attribute needs to be present if it duplicates text in para above.
This is giving fodder to those who wish to banish the summary attribute.
If this duplication is alright, why then having alt that is identical to anchor text in image link not alright?

Response from WG:
With the table, the text in the paragraph above is not programmatically associated with the table (except if using WAI-ARIA). The summary is linked. With your second example, both texts are programmatically associated to the link.

Response from Commenter:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0020.html

Thanks for the response.
Sorry, I disagree. A sighted user can only associate the data table with some explanatory text in a paragraph on the page by reference to a sentence in the text that refers to the table like, "In the accompanying table ..." or "Table-1 refers to ...".
Programmatic association does not help the sighted user. A screen reader user too will be in the same position and he must not have to access this content twice - once through table's summary attribute. Programmatic association is not required here. Programmatic association / markup is required to expose structure / relationships that may not be otherwise quickly or easily apparent to assistive technology users.
In fact it is misuse or misapplication of table summary if it duplicates page-text. The summary is meant to assist non-sighted users understand table structure of complex tables or salient / key data revealed by the table which is evident to sighted users.; Related issues: (space separated ids); WG Notes: I think in light of WAI-ARIA we can update two paragraphs that have examples... they would actually meet his request and not compromise the principle, while still allowing redundancy... Sept 22 draft: Proposed Response: In light of WAI-ARIA developements, we have updated to paragraph to include programmatically associating the visual text with the table, and discouraging redundancy, while not forbidding it for many reasons including legacy content. We have updated the paragraph as follows: "Some technologies do not provide a means to programmatically determine some types of information and relationships. In that case there should be a text description of the information and relationships. For instance, "all required fields are marked with an asterisk (*)". Where possible WAI-ARIA should be used to programmatically associate the text. In some legacy situations, or where WAI-ARIA is not available, it is acceptable to have the text description near the information it is describing (when the page is linearized), such as in the parent element or in the adjacent element. There may also be cases where it may be a judgment call about what information should appear in text and when text should be directly associated. For instance, in an HTML table, there are some situations when the Summary attribute should be used to give an explanation to screen reader users which is not available to a sighted user. In other situations the text summary should appear in a paragraph before the Table so that all can see it, and it would be associated using aria-describedby. In rare situations redundancy can be used, where information appears programmatically, and in separate text. However, this can be "chatty" for screen reader users, and in light of the increasing support for WAI ARIA, is not usually necessary. Wherever possible it is necessary for the information to be programmatically determined rather than providing a text description before encountering the table." See Michael's comments at http://www.w3.org/2002/09/wbs/35422/20110922misc/results#x2462 10/6/11 Response: Thank you for your comment. Generally speaking, programmatic association is required when possible. On the other hand, context generated by reading order proximity can also be taken into consideration. In the case of the table summary example at hand, it seems possible that a screen reader user would have difficulty associating a table with a preceding paragraph (assuming it is not a table caption), depending on the actual reading order proximity and other factors. It would therefore seem prudent to repeat at least some of the more essential information contained in that paragraph. We have therefore decided to change the text in question to: "and it may be appropriate to duplicate some information (for instance, in an HTML table, providing a summary attribute with a concise description of essential information contained in the paragraph before the table)..." @@proposed resolution: Change text to: "and it may be appropriate to duplicate some information (for instance, in an HTML table, providing a summary attribute with a concise description of essential information contained in the paragraph before the table)..."; Resolution: We have removed the sentence that discusses duplicating information, so that this paragraph now reads: [DONE] There may also be cases where it may be a judgment call about what information should appear in text and what would need to be directly associated. However, wherever possible it is necessary for the information to be programmatically determined rather than providing a text description before encountering the table.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2463: WCAG 2 techniques for SC 1.3.2 and 2.4.3: Commenter: Sailesh Panchang <spanchang02@yahoo.com> (archived message); Context: Meaningful Sequence: Understanding SC 1.3.2; 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:
Further to my email on the same subject sent last week:
It appears from reading the 'understanding' material for SC 1.3.2 and 2.4.3, and associated techniques, that the expected reading order determined visually is key to identifying correct reading sequence from an accessibility standpoint.
G59(Placing the interactive elements in an order that follows sequences and relationships within the content) states:
"When the order of the HTML source matches the visual order of the Web page, tabbing through the content follows the visual layout of the content. When the source order does not match the visual order, the tab order through the content must reflect the logical relationships in the content that are displayed visually".
Then C27: suggests making the DOM order match the visual order.
â€œThe objective of this technique is to ensure that the order of content in the source code is the same as the visual presentation of the contentâ€.
Then it goes on to describes the problems if the DOM order does not match visual order. These are accurate and very valid. So if above stated objective is not attained, then does the content not fail the SC?
Comment:
For every page there is only one intended reading order and the author sets out the page in that manner. This will generally be the order one might reasonably expect based on a visual inspection of the page. The focus order of nav elements should follow that reading order.
It is the userâ€™s prerogative to read / navigate it in a different order if he so chooses. And he may do so because the alternate order helps him to better understand the content or simply because only certain blocks of content are of immediate relevance / interest. Proper structural markup would support this.
If these techniques are to be applied to make content comply with SC 1.3.2 then can one conclude that if actual reading and focus order do not follow expected visual order, then there is a problem and content fails SC 1.3.2 / SC 2.4.3?

I agree that CSS can be used to change presentation. But it should not suggest a reading / focus order that is different from DOM / actual order that is programmatically determinable.; Related issues: (space separated ids); WG Notes:; Resolution: You may be confusing techniques with success criteria. One technique may suggest one solution while another techniques suggests quite another - and the two may conflict. Techniques are just that. They are optional. You do not need to use them. You often have a choice between techniques. You also don't need to use any of the techniques listed here. You can make up your own if you know that it will meet the success criteria. The techniques were created for 3 reasons. 1) in order for us to be sure there were ways to meet each SC 2) to learn more about the SC and their implications by creating solutions for each 3) to provide easy ways for people to find solutions But techniques are not required and they are not rules. And there are sometime good reasons for things to differ from the DOM. Though they should be good reasons.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2501: I feel that the 2 sufficient techniques should be 'and' not 'or': Commenter: Sheena McCullagh <sheena.mccullagh@blueyonder.co.uk> (archived message); Context: Bypass Blocks: Understanding SC 2.4.1; 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:
I had originally read this that 1 and 2 were exactly that an 'and', then someone I know who does accessibility testing for a living, pointed out to me that I was wrong. They are not 'and', ie you can do one or the other. However I see a problem with that:

Skip links are of main benefit to sighted users who navigate via the keyboard and are of only very limited benefit to screen reader users. However H69 (heading elements) is only of use to screen readers and provides no help whatsoever for sighted users navigating via the keyboard. (I don't know enough about map, frame and scripting to comment on those, but as they have been grouped with H69, I suspect that they too are of little or no benefit to sighted people who navigate with the keyboard.)

Nonetheless, if someone writes a web page to H69, they would be deemed to have passed SC 2.4.1, even though they have not provided any method for sighted keyboard users to bypass blocks of content that are repeated on multiple pages. The most number of hits of the tab key that I counted before getting to the main page content on one web site was 69 each time I went onto a new page.

Proposed Change:
Please make it 'and' so that both sighted keyboard users and screen reader users are helped. At the moment it's perfectly possible to help only one of those groups and not help the other and still pass this SC.

Response from WG:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0015.html

It is only necessary to implement one of the listed sufficient techniques for this, or any other, success criterion. Authors may choose to implement more than one technique to improve usability, of course.

Skip links may not be the preferred mechanism for screen reader users, but links work for them, so skip links will permit them to skip over the repeated content.

The User Agent Notes for H69 discuss the native support for navigating by headings that is provided in Opera, and notes that for other browsers, plugins may be needed. Authors who rely on H69 must ensure that it is accessibility supported for their users.

Response from commenter:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0021.html

You've completely missed my point. If H69 etc is used to pass this criterion you are only helping screen reader users.

What about those of us who navigate with the keyboard but are sighted, ie do not use assistive technology of any sort? Correct heading structure is of no benefit what-so-ever to us.

If you don't want an AND, perhaps 2.4.1 should be split into two requirements so that the first requirement is to provide a method for keyboard users to bypass blocks and the second requirement is to provide a method for AT users to bypass blocks. As we both know there is a precedent for splitting a single SC into various requirements - 1.4.8.

Comment from Sailesh Panchang:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0059.html

Sheena and I are not talking usability here but accessibility. And WCAG2 addresses needs of a wider spectrum of PWDs than just screen reader users. Sighted keyboard users are an important constituency for SC 2.4.1.
Yes headings work with screen readers and Opera but skip nav works for a wider set of users as stated earlier. For the limited purpose of SC 2.4.1, the skip-nav technique is a sufficient technique. H69 is not. It enhances "usability".
Use of headings may be required to satisfy SC 1.3.1 (see H42) and as an auxiliary benefit will help navigation too. By requiring H42 for SC 1.3.1 and the skip-nav technique for SC 2.4.1, the techniques will address the needs of a larger set of PWD and the WCAG 2 will do more for accessibility. Not less.
As H69 has user-agent limitations I had suggested do away with H69 as h42 is present some 2-3 years ago. I reiterate that.
Finally, one does not go around adding heading tags simply to help keyboard navigation but to mark up section headings to expose structure. But websites can be required to add one skip nav link as has been the practice since S508 became law.
There are many many U.S. fed gov websites that do not implement headings because it was not needed by S508 but do have skip nav link.
Not sure many are aware of a plugin to make keyboard navigation work with headings for browsers like IE and FF. Maybe a links should be given as a resource for H69 if it is retained. H69 may be an advisory technique ..

[1] http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Mar/0011.html; Related issues: (space separated ids); WG Notes: jon G: Browser vendors want to make their browsers as lean as possible, and push "optional" functionality into plugins. Issue considered when we added this technique. UA support isn't any worse. https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/ Will Walker work? https://addons.mozilla.org/en-US/firefox/addon/headingsmap/ --- Removed HeadingsMap <https://addons.mozilla.org/en-US/firefox/addon/headingsmap/>; Resolution: The author of web content needs to be sure that the technique used to meet a success criterion is supported by the user agents available to his users. We add User Agent notes to advise authors of limitations in user agents support for a technique, and we have done so with H69. Because there are environments in which there is sufficient user agent support, we continue to list it as a sufficient technique for SC 2.4.1. We notice that the trend among browsers is to provide minimal functionality in the browsers themselves, but to support plugin and extension mechanisms for adding functionality that isn't needed by all users. This lets users customize the browser to their own needs. Support for keyboard navigation via header appears to be one of the functions that will usually be found in such extensions. We are adding to the Resources for H69 to list some of the plugins currently available for providing keyboard navigation via headers: [DONE] Add to Resources: For Firefox, the following plugins provide header navigation via the keyboard: Accessibility Evaluation Toolbar <https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/> Heading Navigation Greasemonkey User Script <http://juicystudio.com/article/heading-navigation-greasemonkey-user-script.php> [DONE] Also add to Resources: Heading navigation in web browsers <http://www.456bereastreet.com/archive/201003/heading_navigation_in_web_browsers> [DONE] Add to end of User Agent Notes: "See the Resources section for references to some of these plugins."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2474: Require both sufficient techniques: Commenter: Sheena McCullagh <sheena.mccullagh@blueyonder.co.uk> (archived message); Context: Bypass Blocks: Understanding SC 2.4.1; 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 feel that the 2 sufficient techniques for SC 2.4.1 should be 'and' not 'or'.

I had originally read this that 1 and 2 were exactly that an 'and', then someone I know who does accessibility testing for a living, pointed out to me that I was wrong. They are not 'and', ie you can do one or the other. However I see a problem with that:

Skip links are of main benefit to sighted users who navigate via the keyboard and are of only very limited benefit to screen reader users. However H69 (heading elements) is only of use to screen readers and provides no help whatsoever for sighted users navigating via the keyboard. (I don't know enough about map, frame and scripting to comment on those, but as they have been grouped with H69, I suspect that they too are of little or no benefit to sighted people who navigate with the keyboard.)

Nonetheless, if someone writes a web page to H69, they would be deemed to have passed SC 2.4.1, even though they have not provided any method for sighted keyboard users to bypass blocks of content that are repeated on multiple pages. The most number of hits of the tab key that I counted before getting to the main page content on one web site was 69 each time I went onto a new page.

Proposed Change:
Please make it 'and' so that both sighted keyboard users and screen reader users are helped. At the moment it's perfectly possible to help only one of those groups and not help the other and still pass this SC.; Related issues: (space separated ids); WG Notes:; Resolution: It is only necessary to implement one of the listed sufficient techniques for this, or any other, success criterion. Authors may choose to implement more than one technique to improve usability, of course. Skip links may not be the preferred mechanism for screen reader users, but links work for them, so skip links will permit them to skip over the repeated content. The User Agent Notes for H69 discuss the native support for navigating by headings that is provided in Opera, and notes that for other browsers, plugins may be needed. Authors who rely on H69 must ensure that it is accessibility supported for their users.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2461: Understanding WCAG 2- SC 2.4.3: Commenter: Sailesh Panchang <spanchang02@yahoo.com> (archived message); Context: Focus Order: Understanding SC 2.4.3; 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 first two list items(out of six) following Examples repeat the text under Intent verbatim. I do not understand why.
The fifth list item says the left nav links are made to appear before main content via CSS but the left nav links actually main content in the code. And this helps navigating to main content directly and this passes SC 2.4.3.
Comment:
I think it fails SC 2.4.3.
A sighted keyboard user will be confused if he cannot tab to a set of links that appear before main content. In a left to right and top-down system one might expect tab focus to go to left nav links first. For a screen reader user too, this may pose problems: there may be an h1 before main content and no heading before left nav links. So it may be difficult to identify end of main content. If the page layout has been explained to a blind user, he too will be confused if he cannot navigate to left nav before main content.
(If left nav appear after main content visually and in tab order, it is another matter).; Related issues: (space separated ids); WG Notes: RE: Repeated text They are there because they are examples. They were also used in the description because it was felt that it aided understanding for those examples to be in the intent. RE NAV order. This is always a problem. It is why a "skip to main content" link has been suggested. [ TAKE TO COMMITTEE FOR DISCUSSION] - having to tab through all nav links is a problem - jumping past them and having to tab through the whole page to get to them is also a problem. Best solution is: Skip Nav link and nav tabs come first in order. Do we say that? Is that what we want to say? (Someday ARIA and good browsers will help here) @@ACTIONS: - Remove first item from examples. (The one that starts "the way that sequential..."); Resolution: [DONE] We have removed the first example. [DONE] We are rewording the second example so it reads more like an example: 2. On a web page that contains a tree of interactive controls, the user can use the up and down arrow keys to move from tree node to tree node. Pressing the left arrow key expands a node, then using the down arrow key moves into the newly expanded nodes. We do not believe that Example 5 fails 2.4.3, since the tab order still follows the reading order, and the reading order follows a logical order.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2498: Understanding SC 2.4.6 needs improvement: Commenter: Sailesch Panchang <spanchang02@yahoo.com> (archived message); Context: Headings and Labels: Understanding SC 2.4.6; 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:
SC 2.4.6 requires a label to describe purpose, meaning purpose of associated components including interactive controls.
But this is not clear from reading the content for Understanding SC 2.4.6. The SC refers to headings and labels but the examples that follow do not contain an example for form labels. (The definition of label is wider than HTML form label).
Only G131 in the "How to" doc seems to clearly suggest that label refers to labels for interactive components. SC 3.3.2 only requires a label ... does not say label's purpose is clear.
I often see form controls with poor labels / title attributes and I flag SC 2.4.6.
Suggestion: The Understanding SC 2.4.6 and examples should explicitly refer to labels for form controls and interactive components.; Related issues: (space separated ids); WG Notes: adam: do labels in fact only refer to interactive components? What about table captions?; Resolution: Thank you for your comment. The understanding document for 2.4.6 contains examples only for headers, and we agree that an example for labels should be added, since they are part of the success criterion. We have therefore decided to add an example, describing a label for an interactive control. [DONE] Proposed resolution: 1. In the section "Examples of Success Criterion 2.4.6", add as bulleted example 4 the following example (taken from g131): "A form asking the name of the user A form asks the name of the user. It consists of two input fields to ask for the first and last name. The first field is labeled "First name", the second is labeled "Last name"." 2. Remove the words "Example 3" from the third bulleted example in the section "Examples of Success Criterion 2.4.6".; (Please make sure the resolution is adapted for public consumption)

Comment LC-2479: Translation of an easy-to-read text: Commenter: Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (archived message); Context: Reading Level: Understanding SC 3.1.5; 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 example 4, we translated the example of text that is easy to read. In French it counts more words than in English, 134 words. We tried to keep it as simple as possible.
As suggested by Shadi in an e-mail exchange, we submit this change to the working group to find out if it still acceptable as translated in the French language.
See direct link at:
http://www.braillenet.org/accessibilite/comprendre-wcag20/CAT20110222/meaning-supplements.html#meaning-supplements-examples-head; Related issues: (space separated ids); WG Notes:; Resolution: Thank you. This is definitely acceptable, and we appreciate the care you are taking in preserving the level of language difficulty while translating.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2499: Mixup in Understanding doc: SC 3.2.2 and SC 3.2.5: Commenter: Sailesch Panchang <spanchang02@yahoo.com> (archived message); Context: On Input: Understanding SC 3.2.2 (also SC 3.2.5); 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:
Issue 1: For SC 3.2.5 (AAA) it says in the "Understanding" doc that: " ... eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of
forms after selecting an item from a list, etcetera."
Comment: Auto submission of form after making a selection from a list should not be listed under SC 3.2.5 as it needs to be fixed in order to comply with SC 3.2.2.
If a form auto-submits and refreshes the page's content as one tabs off a SELECT control after navigating up and down the choices and making a selection, it is a violation of SC 3.2.2.
H84 explains how a button placed after the SELECT will fix the issue.
The "Understanding" doc explains that the intent of SC 3.2.2 is to ensure that entering data or selecting a form control has predictable effects. So there is no doubt that this is indeed an SC 3.2.2 issue.

Issue 2: Refer to Understanding doc for SC 3.2.2.
One of the items under benefits is:
"â€¢ Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected."
Comment: This refers to a new browser window and not just a pop-up in the same page like for an advertisement. A new browser window popping up is an SC 3.2.5 (AAA) issue and should not be listed under SC 3.2.2. The item has already been listed under benefits for SC 3.2.5.
By the way, the browser does convey to AT that a new window is being launched.; Related issues: (space separated ids); WG Notes: Replace "such as a new window popping up": "Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as the display of a generated or hidden content area on the page (for example, a lightbox)."; Resolution: RE: Issue 1: It is often true that an action or practice will cause more than one SC to be violated. The fact that something fails 3.2.2 does not mean that it would not also fail 3.2.5 or be discussed there and vice versa. However - you are correct that we should go further in "Understanding SC 3.2.5". So we have added to the end of the sentence so that it reads "This Success Criterion aims to eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of forms after selecting an item from a list, or changing the content on the page simply because the person navigated to a section but did not select any link or button or issue any command other than navigation. " RE: Issue 2: People working toward level A conformance need to see this in 3.2.2 and will not be looking at 3.2.5. Opening a new window is a change of context and is therefore covered under SC 3.2.2.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2455: Note at end of sufficient techniques for 3.3.2 is ambiguous: Commenter: David MacDonald <david@eramp.com>; Context: Labels or Instructions: Understanding SC 3.3.2; 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 Government of Canada has pointed out an ambiguous note: read our correspondence below

From: Pirthipal.Singh@tbs-sct.gc.ca [mailto:Pirthipal.Singh@tbs-sct.gc.ca]
Sent: September-14-10 10:19 AM
To: David@eramp.com
Subject: Quick Question

Hi David

Hope things are going well.

We have a question: In success criteria 3.3.2 (http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/minimize-error-cues.html), there is an ambiguous note at the end of sufficient techniques which states

Note: The techniques at the end of the above list should be considered "last resort" and only used when the other techniques cannot be applied to the page. The earlier techniques are preferred because they increase accessibility to a wider user group.

The use of the terms "last resort"Â and "techniques at the end of the above list"Â are causing confusion. For example, are techniques 4+5 fine or does one follows sufficient techniques from the top (and only use latter ones if the earlier ones cannot be met).

Would you be able to clarify?

P.S. My recommendation would be not to put in ambiguous terms like that for sufficient techniques. If a sufficient technique is not considered sufficient, it should not be in the sufficient techniques.

Pirthipal Singh
Team Leader - Web Standards Office | Chef d'equipe - Bureau de normes web
Information Technology Division | Division de la technologie de l'information
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | SecrÃƒÂ©tariat du Conseil du TrÃƒÂ©sor du Canada
Ottawa, Canada K1A 0R5
Pirthipal.Singh@tbs-sct.gc.ca
Telephone | TÃƒÂ©lÃƒÂ©phone 613-948-1888 / Facsimile | TÃƒÂ©lÃƒÂ©copieur 613-946-9342 / Teletypewriter | TÃƒÂ©lÃƒÂ©imprimeur 613-957-9090
Government of Canada | Gouvernement du Canada
Hi Pirth

You are probably right... I actually donÃ¢â‚¬â„¢t remember when that got added ...

I think they are talking about these two techniques in the note:
Ã¢â‚¬Â¢ H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
Ã¢â‚¬Â¢ G167: Using an adjacent button to label the purpose of a field

The Title attribute has flakey support in User agents... ItÃ¢â‚¬â„¢s not really the authorÃ¢â‚¬â„¢s fault... but JAWS does allow the user to set the Title attribute for different settings ... although most blind people donÃ¢â‚¬â„¢t know that and itÃ¢â‚¬â„¢s also not the best behaviour anyway... so thatÃ¢â‚¬â„¢s why I think they added the note but let the techniques stand. For G167, screen readers are pretty smart about looking around a field for something that might be a label so it would probably read ok, but again itÃ¢â‚¬â„¢s not really a programmatic association. Giving advice like this is pretty ambiguous. The note telegraphs that the committee was not thinking that the techniques were going to become mandatory...

IÃ¢â‚¬â„¢ll add your comments, and suggest the techniques be demoted to advisory.

Cheers
David MacDonald

Proposed Change:
Change H65 and G167 to advisory techniques for 3.3.2

And review H71 (using fieldset) to consider whether it should be sufficient or advisory; Related issues: (space separated ids); WG Notes:; Resolution: This was meant to apply to techniques H65: Using the title attribute to identify form controls when the label element cannot be used (HTML) G167: Using an adjacent button to label the purpose of a field We should have named them rather than referring to them in list order. Note that we encourage the use of additional techniques even though these techniques are technically sufficient. [DONE] ACTION TAKEN: We have changed the note to read: "Note: The techniques H65 and G167 in the above list should be considered "last resort" and only used when the other techniques cannot be applied to the page. The earlier techniques are preferred because they increase accessibility to a wider user group."; (Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2497: Make document titles more visible through italicising or other emphasis: Commenter: Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (archived message); Context: Document as a whole; 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:
While skimming the document, it would be easier for the reading to see document titles if they are emphasised through italics or with quoting.

Proposed Change:
See for example, in heading "sufficient and advisory techniques" following sentence:
"for an explanation of how this document fits in with other Web Content Accessibility Guidelines (WCAG) 2.0 documents.
Emphasize "Web Content Accessibility Guidelines".; Related issues: (space separated ids); WG Notes: There are a lot of different opinions about the use of italics online, however, it is not as good on screen as it is on paper because of the way pixels are created. Recommend that this suggestion not be acted on. Recomended response: There are a lot of different opinions about the use of italics online, however, it is not as easy to read on screen as it is on paper because of the way pixels are created on most monitors. Also, emphasis is not the semantic for a heading that we would choose. Recommended action: none; Resolution: We are concerned that this may complicate the visual presentation and make the documents more difficult to read. IF we have time, we will investigate adding a class to the mark-up so that this type of styling could be investigated in the future.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2468: Editorial Errors from Tomas Caspers: Commenter: Tomas Caspers <tcaspers@me.com> (archived message); Context: Document as a whole; Status:
assigned to; 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:
> "Extended audio description can provide the additional information they needed to understand the video"

It should either read:

"Extended audio description can provide the additional information needed to understand the video"

or:

"Extended audio description can provide the additional information they need to understand the video"

â€”â€”â€”â€”

> "A live text caption service will enable live audio to be accessible to people who are Deaf or hard of hearing, or who cannot otherwise hear the audio."

"deaf" should be written with a lower case "d".

â€”â€”â€”â€”

> "In these cases there are number of different reading orders for a Web page that can satisfy the Success Criterion."

There is an "a" before number missing.

â€”â€”â€”â€”

> "The arrow is clearly labeled with "Next" and the instructions state, "To move to the next section of the survey, select the green arrow icon labeled 'Next' in the lower right below the last survey question." This example uses both positioning, color and labeling to help identify the icon."

Shouldn't it be "â€¦in the lower right cornerâ€¦"?

â€”â€”â€”â€”

> "The intent of this Success Criterion is to encourage authors who are using technologies that are capable of achieving a specific visual presentation to enable people who require a particular visual presentation of text to be able to adjust the text presentation as required."

What are authors encouraged to do? It's not said in this sentence.

â€”â€”â€”â€”

> "Rather, it means that content that uses analog, time-dependent input cannot conform to this Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA."

Shouldn't that be path-depending instead of time-depending?

â€”â€”â€”â€”

> "An essential animation can be paused without effecting the activity"

Shouldn't it be "affecting the activity"?

â€”â€”â€”â€”

> "A test is designed so that time to complete the test does not effect the scoring"

Shouldn't it be "affect the scoring"?

â€”â€”â€”â€”

> "This allows access by people with cognitive limitations or attention disorders to be able to focus on the content."

Seems like there are two sentences that were connected without rearraging the verbs.

â€”â€”â€”â€”

> "Some common examples of technical terms include: Homo sapien, Alpha Centauri, hertz, and habeas corpus."

Must read Homo sapiens

â€”â€”â€”â€”

> "A skip to navigation link is provided to navigational content at the end of a page. The link is consistently located at the top of each page so that keyboard users can easily locate it when needed."

First it says that the link is at the end of the page, then it says it's at the top?

Also: is "to navigational content" correct or should it read "to navigate content"

â€”â€”â€”â€”

> "If the references to the next page read "page 1", "page 2", "page 2" etcetera, the labels are not the same but they are consistent."

Is it correct that page 2 is repeated? Schouldn't that read "page 3"?

â€”â€”â€”â€”

> "In the case of an unsuccessful form submission, users may abandon the form because although they may be aware that an error has occurred, they may be unsure of how to correct the error even though they are aware that it has occurred."

even though they are aware that it has occurred. <- this is repeated in this sentence!

â€”â€”â€”â€”

> "whether there are no workarounds if the Success Criteria is not met"

"â€¦ criteria are â€¦" or "â€¦ criterion is â€¦"

â€”â€”â€”â€”

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Jan/0013.html:

> Major sections of the document are pages titled title "Understanding Guideline X" and "Understanding Success Criterion X."

..."pages titled title..." â€“ the second title should be deleted here.

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0000.html:

> Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size.

What is ex in this context supposed to mean? Or should it read e.g.?

> For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present large-scale images of text to a user.

Shouldn't "large-scale" not be in front of tex? ..."to successfully present images of large-scale text to a user."

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0002.html:

during the translation of the latest version of "Understanding WCAG" <http://www.w3.org/TR/2010/NOTE-UNDERSTANDING-WCAG20-20101014/complete.html> into German we found some link errors:

> (Success Criteria <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-pause">2.2.3</a>, <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-no-exceptions">2.2.4</a> and <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-server-timeout">2.2.5</a> may also apply.)

2.2.3 links to 2.2.2, 2.2.4 links to 2.2.3, whereas 2.2.5 is correct

The following link points to the wrong definition / fragment identifier (two instances)

> (no <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#videodef" class="termref">audio</a> and no interaction); Related issues: (space separated ids); WG Notes: Bruce (02 May 2011) competed all edits and added in DIFF attributes to UNDERSTANDING doc. The last item (wrong definition / fragment identifier) is a change to WCAG.; Resolution:; (Please make sure the resolution is adapted for public consumption)

Comment LC-2470: no link to single file version of Understanding doc: Commenter: David MacDonald <david100@bell.net> (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:
The overview document for the Understanding document
http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html

should have a link to the single file version.
http://www.w3.org/TR/UNDERSTANDING-WCAG20/complete.html

Proposed Change:
Place a link somewhere near the top of the file that says something like:
The Understanding document is available as a single file here:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/complete.html; Related issues: (space separated ids); WG Notes:; Resolution: Thank you for catching this. We will fix it. [DONE] Add link to single file version; (Please make sure the resolution is adapted for public consumption)

Comment LC-2473: Editorial comments from Sylvie Duchateau: Commenter: Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (archived message); Context: Document as a whole; 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:
Understanding Success Criterion 1.3.2

"(None currently documented)" stands at the beginning of examples, although examples are available

This sentence should be removed as examples are available.

Proposed Change:
Remove the sentence. We did this in the CAT translation as agreed with Michael Cooper.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0007.html:
Understanding Success Criterion 3.1.5

"None currently documented" should not be there.
The sentence stands here although examples are available.

Proposed Change:
Remove sentence. We did this in our CAT version as agreed with Michael Cooper.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Feb/0008.html:

In Understanding Success Criterion 2.2.1:
Link to SC 3.1.2 links to Guideline 3.1;
the link does not directly point to SC 3.1.2 but to the Guideline above. Located in the quotation of SC 2.2.1.consistent-behavior.html#consistent-behavior-receive-focus

Proposed Change:
Link to: consistent-behavior-receive-focus.html
Note: we changed the link in the French CAT translation.; Related issues: (space separated ids); WG Notes:; Resolution: Thank you for catching these errors. We will correct them as proposed. [DONE first two, pending discussion on approach for third] Make suggested edits; (Please make sure the resolution is adapted for public consumption)

Comment LC-2453: techniques link to 20081211 version: Commenter: Andrew Arch <andrew@w3.org> (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:
Many techniques in the Understanding doc (e.g. from http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html) seem to link to the 2001/11 version of the Techniques (eg http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G93) rather than the latest release (ie http://www.w3.org/TR/WCAG20-TECHS/)

Proposed Change:
Update links to always link to "Latest Version"; Related issues: (space separated ids); WG Notes:; Resolution: Thank you for pointing this out. These shouldn't refer to latest versions, because there may be changes in one that's only meaningful when viewed in light of the change in another. However, the links should have been to the correct updated version, and we will fix this. [DONE] ACTION: Update links in understanding doc (and thus also how to meet) to always link to correct dated version. Also check the techniques doc to be sure this is true there as well.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2477: Expanding acronym of WCAG 2.0 in the document title: Commenter: Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (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:
Hello all,
During the translation process of Understanding WCAG 2.0, one reviewer found that it may be useful to expand the acronym WCAG 2.0 the first time it occurs in the document, that is in the H1 of the overview file. That would mean:
<h1><a name="title" id="title"> </a>Understanding WCAG 2.0 </h1>
replaced by:
<h1><a name="title" id="title"> </a>Understanding <acronym title="Web Content Accessibility Guidelines">WCAG</acronym> 2.0 </h1>; Related issues: (space separated ids); WG Notes:; Resolution: Proposed response: This is a good suggestion. We will do that. [DONE] use Acronym to expand WCAG in its first instance of each document... in the H1 Title... <h1><a name="title" id="title"> </a>Understanding <acronym title="Web Content Accessibility Guidelines">WCAG</acronym> 2.0 </h1>; (Please make sure the resolution is adapted for public consumption)

Comment LC-2480: Make title of a document easier to identify: Commenter: Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (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:
Hello all,
While translating Understanding WCAG 2.0, we had an issue raised by a reviewer about a better identification of document titles in text.
She thinks that it would be useful to quote the title or to write it with italics.
Example where this occurs:
"Specific techniques for meeting each
Success Criterion for this guideline are listed in the understanding sections for each Success Criterion (listed below)".
The suggestion is to write in the "understanding" sections or to write understanding with italics.; Related issues: (space separated ids); WG Notes: The translator may have been reading a black and white copy of the document.... there are several ways that the headings are distinguished (1) by colour (2) by size (3) by bold style In the printed version the colour would not be there to distinguish and they would only be relying on size and bold, and that would naturally be a bit harder to distinguish, but it is still distinguishable. Italics are harder to read for the online version (which is primary) and are not recommended for Titles because of the way monitors create pixels... putting it in quotations would not be the proper semantics.; Resolution: We are concerned that this may complicate the visual presentation and make the documents more difficult to read. If we have time, we will investigate adding a class to the mark-up so that this type of styling could be investigated in the future.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2495: Punctuation at the end of list items: Commenter: Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (archived message); Context: Document as a whole; 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:
During the review process of the French translation of Understanding WCAG 2.0, the French reviewers noted that punctuations would not be used in an appropriate way, in particular at the end of each item of a list ul li. They request that punctuations should be reviewed in a future version of the document.

Proposed Change:
In particular, concerning the three items list, just before heading 3 "sufficient and advisory techniques" the three items list should end with a full stop, as we reach the intent of a section.
Actual wording:
"descriptions of the intent of the Success Criteria, including benefits, and examples" should be changed in:
descriptions of the intent of the Success Criteria, including benefits, and examples."
We inform the Working Group that we added this full stop at the end of the list, but only for this particular issue.; Related issues: (space separated ids); WG Notes: David adds: I suggest we look into the punctuation issue... there are a lot of debates within the French community about the correct way to write French and this may be more about that than incorrect punctuation... since this document was created by French speaking people, I just sent the comment to a native French person... Follow up: Denis, a native Quebec french speaker said the following: "Hi David,...Sylvie is right, form a France-native perspective. Punctuation rules are slightly different here in Quebec, but since the document translation has been led by her and the folks at BrailleNet, I say we should do as she asks. I'd say agree to her comment and have the modifications brought to the document." It appears the change was made and a response sent, so not further action would be necessary if that is the case. (Editorial Change); Resolution: Response sent: Thank you for catching this. We corrected this instance, and hope to make a complete review of the documents at some point.; (Please make sure the resolution is adapted for public consumption)

1-20 21-21

Add a comment.