W3C

List of comments on “Understanding WCAG 2.0” (dated 27 April 2006)

Quick access to

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

1-20 21-40 41-60 61-80 81-100 101-120 121-127

question comments

Comment LC-787: Text-Alternatives
Commenter: Joe Clark 1 <joeclark@joeclark.org> (archived message)
Context: How to Meet Success Criterion 1.1.1
Not assigned
Resolution status:

Comment:

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html

Text alternatives

Providing what description is possible is also desired. If the intent of the author in creating the content - or the intent of the page author in putting the content on the page - is known and can be described, this is also very useful

"Intent of the page author"? What is this talking about?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-788: Text-Alternatives
Commenter: Joe Clark 1 <joeclark@joeclark.org> (archived message)
Context: How to Meet Success Criterion 1.1.1
Not assigned
Resolution status:

Comment:

Text alternatives

Linking to live textual information, e.g., if it is a traffic Webcam, linking to a site that provides textual traffic reports

If my Webcam is pointed out my window and depicts my obscure street or intersection, exactly how am I going to locate a traffic-report site that covers my neighbourhood? And how is that actually "equivalent" given that a sighted visitor can watch traffic in real time, while a "textual traffic report" has to be written and published post-facto and can never keep up?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-992
Commenter: Shawn Henry <shawn@w3.org> on behalf of W3C WAI (archived message)
Context: Document as a whole (Intent)
Not assigned
Resolution status:

Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):

It would be extremely useful to have an easy way to refer to specific guidelines and success criteria. Trying to refer to them by numbers or their long text is awkward. More importantly, it is a significant barrier to common Web developers being able to communicate about them, and it makes the guidelines even more esoteric.

I propose including “shortnames�? or “handles�? in the “Understanding�? doc. I understand that it is quite difficult to do. I think it is OK for them to not be technically accurate, and instead make them easy and use common terminology, e.g.,:
- “Alt-text�? for “Guideline 1.1 : Provide text alternatives for all non-text content�?
- “Multimedia alternatives�? for “Guideline 1.2 : Provide synchronized alternatives for multimedia�?
- “Separate content and presentation�? for “Guideline 1.3 : Ensure that information and structure can be separated from presentation�?
- “Contrast�? for “Guideline 1.4 : Make it easy to distinguish foreground information from its background�?

I understand the concerns with shortnames/handles being used inappropriately; however, I think the benefits far outweigh the risks.

Also, I think that putting these in the “Understanding�? doc and not the /TR/WCAG10 doc helps some with concerns about them not being insufficient to convey the full meaning of the long text.


Proposed Change:

Include shortnames/handles for each guideline and success criteria (and principle while you’re at it since those are easy :).
1018 1328
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1405: > documentation is FANTASTIC.
Commenter: Hanna Kutcher <hkutcher@bex.net> on behalf of Accessibility Consultant (archived message)
Context: Document as a whole (Intent)
Not assigned
Resolution status:

Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):

Pat yourselves on the back and don't let anyone tell you otherwise, your documentation is FANTASTIC. I found it very helpful while redesigning the interface for Safari Books Online to meet WCAG 2.0 guidelines (not an easy task). Your compliance techniques were indispensable. All the techniques are well-written, cristal clear, and "trustworthy" meaning that I know the techniques are based on what works for real people, not just in theory. Thanks to you, I have a prototype I and the client can be proud of. Your efforts continue to ensure that compliance isn't something you do to "get the sticker", but something you do to make sites better for everyone.

Proposed Change:

Treat yourselves, you deserve it. Don't forget to post those party photos. :-)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-597
Commenter: Martin Stehle <pewtah@snafu.de> (archived message)
Context: Document as a whole (Techniques for Addressing Success Criterion 3.1.5)
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

The note "Different sites may address...sufficient by the working group" is a little bit misleading in case of deaf people.

Proposed Change:

Please add to the note that in case of deaf people it is wrong to think about deaf people as human beings not able to understand "texts above upper secondary education level". It is not about cognitive impairments, it is about linguistic matters. It is just that many deaf people understand sign language better than written language, because sign language is their mother tongue. With sign language "texts above upper secondary education level" are more understandable for deaf people.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-782: ACCUM RESP
Commenter: Joe Clark 1 <joeclark@joeclark.org> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Comment:

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html

Endorsement of "non-W3C technologies"

A deficiency of WCAG 1 was its chauvinism toward anything not invented by the W3C. They pretty much didn't want you to use any "non-W3C technologies"; there's a whole [3] guideline telling you not to. WCAG 2 tries to be technology-neutral. In so doing, it authorizes the use of "HTML" that was never ratified by a specification, notably embed.

While this is the only reliable method to include multimedia on a Web page (still, in 2006), is univerally understood by graphical browsers, and can easily be made legal via a custom DTD, it still isn't real HTML. I find its inclusion curious given WAI's ideology of yore. (Elsewhere, the Understanding document lists the blink element as a failure method. That isn't real HTML either, thankfully.)

3. http://www.w3.org/TR/WAI-WEBCONTENT/#gl-use-w3c
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1087: REORGANIZE
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Intent vs Benefits: These two sections are essentially the same

Proposed Change:

Either differentiate the two sections more, or merge them
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1091
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Script: The techniques and examples are very script heavy. It appears, to a casual reader, that the W3C is advocating scripting above other technologies, such as PDF, XHTML or CSS.

Proposed Change:

Ensure that techniques and examples are evenly spread over a variety of technologies
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-595
Commenter: Martin Stehle <pewtah@snafu.de> (archived message)
Context: How to Meet Success Criterion 1.2.5 (Benefits: How Success Criterion 1.2.5 helps people with disabilities)
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

The thesis "People whose primary language is a sign language sometimes have limited reading ability" is not always true. The reading ability of native signers is broad, from low to top. The focus on captions is not meeting the reality. Many native signers are able to understand captions. The focus has to move to the complete content, i.e. the texts.

Proposed Change:

Replace it with "These individuals may not be able to read and comprehend the textual contents and thus require a sign language interpretation to gain access to the multimedia content."
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-596
Commenter: Martin Stehle <pewtah@snafu.de> (archived message)
Context: How to Meet Success Criterion 1.2.5 (Benefits: How Success Criterion 1.2.5 helps people with disabilities)
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

The thesis "Some people who communicate using sign language and are proficient readers may have impaired vision which may make it difficult to read the captions on the screen. A sign language interpretation may be easier to view." is misleading: Captions are zoomable, a video with a signer is not zoomable to meet impaired vision.

Proposed Change:

Suggestion: Delete it.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-591
Commenter: Martin Stehle <pewtah@snafu.de> (archived message)
Context: How to Meet Success Criterion 1.2.5 (Intent of this success criterion)
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

Reasons of why using sign language videos are wrong.

Proposed Change:

Replace it with: "The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in the sign language to understand whole texts. Many people, especially native signers, find it easier to follow sign language than to read the text, since the text are often a second language to them."
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1407: linearization
Commenter: David MacDonald <Befree@magma.ca> on behalf of eramp WCAG Team Member (archived message)
Context: Understanding Guideline 1.3 (Intent)
Not assigned
Resolution status:

Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):

I\'ve been up to to my eyeballs in the documents lately for a multination client who is developing a policy. And have noticed a few things I hadn\'t noticed before.

Although GL 1.3 says \"Ensure that information and structure can be separated from presentation\" we have not said *anywhere* in the document that we discourage table layout. If we discuss layout tables (ie. table summary element) and do not mention our prefference to CSS layout then we are tacidly endorsing layout tables I would say.



Proposed Change:

Propose that we add a note to all the techniques that address table layout (F46,F49,G57 etc.) which would say something like:

\"Note: Although Layout tables are allowable under the GUidelines, the working group recommends the use of CSS layout rather than HTML layout tables because CSS layout is more in line with the principle of separation of presentation and content.\"
LC-673
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1083: level-change color/variations/programmatic
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: How to Meet Success Criterion 1.3.5
Not assigned
Resolution status:

Move to Level 1: From what I understand, this is the equivalent of making sure information is not provided via colour alone, so why is it at Level 2?

Proposed Change:

Move 1.3.5 to Level 1
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1525: COLOR/VARIATIONS/PROGRAMMATIC
Commenter: David MacDonald <Befree@magma.ca> (archived message)
Context: Understanding Guideline 1.4 (Techniques)
Not assigned
Resolution status:

Part of Item: Techniques
Comment Type: general comment
Comment (including rationale for proposed change):

Web safe colors, web friendly colours
The access Working group GOC has recently made a requirement for web friendly colours.
They believe that some versions of magnifiers (older) only handle web safe or web friendly colours and then they dither non friendly colours. They believe that the dithering process will affect contrast. For instance, a light background that is not safe might get dithered darker, and a dark foreground might be dithered lighter. And the combination could cause lower overall contrast in older user agents.


Proposed Change:

Discuss why or why not web safe/friendly is an issue.

Add something like:

Note: some older user agents are limited to web friendly, web safe colours. If older user agents in your baseline, use web friendly/safe colours.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1095: Timing
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: How to Meet Success Criterion 2.2.6
Not assigned
Resolution status:

Example - A questionnaire with a timeout: In this example, there are several recommendations that certainly would make the questionnaire more accessible (alert popups, information on timeout etc) but these do not actually relate to this (or any) SC. These are excellent requirements - they should be developed into SC

Proposed Change:

Create new SC (I am happy to help with this)
1097
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1110: link-text
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: How to Meet Success Criterion 2.4.4
Not assigned
Resolution status:

Click here: Please clarify whether or not this SC allows for link text such as "Click here" and "more". If so this SC should be rewritten to outlaw this ext

Proposed Change:

Clarify or rewrite SC
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1113: set-of-web-units
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: How to Meet Success Criterion 2.4.7
Not assigned
Resolution status:

Small sites: What if a site is only three pages - is it still required to provide a breadcrumb trail etc?

Proposed Change:

Clarify SC
LC-1193
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1114
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: How to Meet Success Criterion 2.4.7 (Techniques)
Not assigned
Resolution status:

Add a technique (or example) to use the LINK REL attributes of Next, Index etc
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-980: link-text
Commenter: Sean Curran <sean@srcurran.com> (archived message)
Context: How to Meet Success Criterion 2.4.8 (Intent)
Not assigned
Resolution status:

Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):

A few other pointers that should be included.

-Don\'t use the same term/word/sentince to symbolize a link if they go different places
-show links have been visited
-don\'t recommend to repeat the same text over and over hard on screen readers.

Proposed Change:

Add the aditional pointers.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1116: Errors
Commenter: Gian Sampson-Wild <gian@tkh.com.au> (archived message)
Context: How to Meet Success Criterion 2.5.1 (Examples)
Not assigned
Resolution status:

Examples: The example implies that this SC requires that correctly filled out fields are kept available after reload - is this what this SC requires?

Proposed Change:

Clarify the SC

Response:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0140.html
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-60 61-80 81-100 101-120 121-127

Add a comment.


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