W3C

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

Quick access to

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
Not assigned
Resolution status:

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?
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(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
assigned to Michael Cooper
Resolution status:

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
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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).
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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
(space separated ids)
(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)
Not assigned
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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
(space separated ids)
(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
assigned to David MacDonald
Resolution status:

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".
(space separated ids)
(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
Resolution status:

> "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)
(space separated ids)
(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
Not assigned
Resolution status:

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
(space separated ids)
(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
assigned to Michael Cooper
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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"
(space separated ids)
(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
Not assigned
Resolution status:

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>
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(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
assigned to David MacDonald
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-21

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:39:38 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org