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-788 : Text-Alternatives
Commenter: Joe Clark 1 <joeclark@joeclark.org> (archived message ) Context: How to Meet Success Criterion 1.1.1
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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?
Related issues: (space separated ids)
WG Notes: [TEAMC]
The objection here is to an advisory technique. I don't really agree that Joe's example of his personal webcam qualifies as a "traffic webcam". But I do think there are issues with this technique.
Practically speaking, text traffic reports would probably not be "live textual information". A traffic report would probably be issued at fixed times during the day so it is not "live". And it would probably provide overall traffic information across a metropolitan area call out only the problem areas. So it would not actually be a text equivalent for any particular webcam at an intersection. That intersection might not be mentioned at all in the traffic report unless there is a problem there.
I think this is a good thing for municipalities to do though and recommend changing the title of this technique to more accurately reflect what it is.
Discussed in the 31 August 2006 telecon:
resolution: accept LC-788 with edits
http://www.w3.org/WAI/GL/2006/08/31-wai-wcag-minutes.html
{partial-accept}
DONE Change technique title from
"Linking to live textual information, e.g., if it is a traffic Webcam, linking to a site that provides textual traffic reports"
to
"Linking to textual information that provides comparable information (e.g. for a traffic Webcam, a municipality could provide a link to the text traffic report.)
Internal WD uddated 1 Sept.
Resolution: We agree that it would not be practical to provide a live textual equivalent to your personal webcam that is providing a view of your neighborhood streets. It might be possible, however, for a municipality to provide a link to traffic reports which are useful to users who can't see the webcam image. Since it is not correct to call a regional traffic report an "equivalent" for a webcam of a particular intersection, however, we have changed the title of this technique to be more accurate.
Note also that this is an advisory technique. It is not in any way required by WCAG. It is just something extra that people can do to make things more accessible where it applies. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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 :).
Related issues: 1018
1328
(space separated ids)
WG Notes: [EDITORZ]
Discussed in the 13 July 2006 telecon:
resolution: accept Issue LC-952, Issue LC-1018 and Issue LC-1328 as proposed
http://www.w3.org/2006/07/13-wai-wcag-minutes.html
{accept}
DONE First draft of handles can be found at
http://www.w3.org/WAI/GL/2006/07/SC-handles.htm
Handles implemented in internal WD 30 August.
Resolution: We have included short handles in the draft to make the success criterion easier to reference. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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. :-)
Related issues: (space separated ids)
WG Notes: [TEAMA] [TEAMB] [TEAMC]
Discussed 06 July 2006
accepted by unanimous consent
http://www.w3.org/2006/07/06-wai-wcag-minutes.html
Resolution: Thank you.
Thank you very much. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes: [TEAMB]
Discussed at Team B meeting on 6-27-2006. Decide to incorporate comments from Team B Survey results of June 22 (http://www.w3.org/2002/09/wbs/35422/teamb062206/results) into the database.
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0056.html
Suggested new wording to address survey comments.........
"On sites designed for people who are deaf, a sign language version of the page may be easier to understand than a written language version since sign language is commonly the first language of this user group."
Discussed 29 June 2006
resolution: accept 557 as worded "For some people who are deaf, a sign language version of the page may be easier to understand than a written language version since sign language may be their first language."
http://www.w3.org/2006/06/29-wai-wcag-minutes.html
DONE - XML source updated 28 June 2006.
Resolution: Thanks you for your suggestion. We have replaced the sentence
"For sites designed for people who are deaf a sign language version of the page may be most useful for users who cannot understand the text well."
with the sentence
"For some people who are deaf, a sign language version of the page may be easier to understand than a written language version since sign language may be their first language." (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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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
Related issues: (space separated ids)
WG Notes: [EDITORZ] [HOLD]
Discussed in the 01 March 2007 telecon:
Accepted by unanimous consent.
http://www.w3.org/WAI/GL/2007/03/01-wai-wcag-minutes.html
Resolution: WCAG 2.0 was carefully written to be technology neutral and to allow non-W3C technologies to be used. As you noted, the guideline talking about using W3C technolgies is from WCAG 1.0 not WCAG 2.0. It was one of the aspects of WCAG 1.0 that we specifically did not bring forward.
With regard to embed, as you point out, "this is the only reliable method to include multimedia on a Web page (still, in 2006), is univerally understood by graphical browsers". This is why it is included. It is one example of non-W3C technology. The guidelines allow a wide range of others. (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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Intent vs Benefits: These two sections are essentially the same
Proposed Change:
Either differentiate the two sections more, or merge them
Related issues: (space separated ids)
WG Notes: [EDITORZ]
Notes (2/14 Editors):
Due to the fact that we have the quickref, this can now be done.
Discussed in the 22 February 2007 telecon:
Accepted by unanimous consent.
http://www.w3.org/WAI/GL/2007/02/22-wai-wcag-minutes.html
{accept}
DONE Merge benefits sections with Intent. In some cases, this may mean including a list (ex. "Specific benefits include:"). For others, this may mean merging the two sections.
Internal WD updated 27 March 2007.
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0093.html
Resolution: We have combined these two sections.
(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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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
Related issues: (space separated ids)
WG Notes: [EDITORZ]
Discussed in the 20 July 2006 telecon:
Accepted by unanimous consent.
http://www.w3.org/2006/07/20-wai-wcag-minutes.html
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0098.html
New issue: http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=2348
Resolution: The examples have to match the technologies. The scripting examples are only used where we are trying to demonstrate dynamic content. Scripting is the most common method for this. If you have other examples you think could be included, please submit them. We are always looking for additional good examples. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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."
Related issues: (space separated ids)
WG Notes: [TEAMA] Adopted this wording as part of the proposed resolution for 591
Accepted, June 8 2006 teleconference
http://www.w3.org/WAI/GL/2006/06/08-wai-wcag-minutes.html
DONE - Intent was updated per 591 on 16 June.
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0056.html
Resolution: We have adopted your recommendation into the intent sections for SC 1.2.5 with a slight revision to indicate that this isn't true for all. It now reads as follows:
'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 the content of the audio track of multimedia presentations. Written text, such as that found in captions is often a second language to them. Some of these individuals may not be able to read and comprehend the textual content of captions or may not be able to read it quickly enough and thus require a sign language interpretation to gain access to the multimedia content.' (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes: [TEAMA]
I recommend adopting the comment... and delete the bullet in the "Benefits section of 1.2.5.
Accepted June 8, 2006 teleconference
Accept
DONE - Delete the bullet about vision impaired people reading captions from the "Benefits section of 1.2.5.
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0056.html
Resolution: Your comment has been adopted and the bullet about vision impaired people reading captions has been deleted from the benefits section of how to meet SC 1.2.5. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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."
Related issues: (space separated ids)
WG Notes: [TEAMA]
I don't think we should say "native signers" It would be the first mention of a specific ethnicity in our guidelines. It is assuming that Native deaf people can't read, and that might not be percieved properly if we mention that. Recommed a partial acceptance.
--
08 June 2006:
resolution: adopt LC-591 resolution with Bruce Bailey's modified language.
http://www.w3.org/WAI/GL/2006/06/08-wai-wcag-minutes.html
--
DONE revise intent for 1.2.5 to read:
The intent of this success criterion is to enable people who are Deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions, is often a second language. Some individuals will require sign language interpretation to gain full access to the multimedia content.
XML source updated 16 June 2006.
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0056.html
Resolution: The intent section for 1.2.5 has been revised to read:
The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions, is often a second language. Some individuals will require sign language interpretation to gain full access to the multimedia content. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.\"
Related issues: LC-673
(space separated ids)
WG Notes: [TEAMC] []
MC: I'm not sure the guidelines as written specifically require separation of content and presentation, although that is a philosophy and technique for meeting many of the SC. They also don't appear to specifically prohibit abusing the semantics of elements except in very particular cases, which is what the recommendation against layout tables would come from. Nevertheless, it could be consistent with overall coding philosphy to put an advisory note in the techniques document as suggested.
Discussed in the 20 July 2006 telecon:
Resolution: Send LC-1407 back to team C to look at all techniques related to table layout and create consistent language for F46, H2, H73 and H39
http://www.w3.org/2006/07/20-wai-wcag-minutes.html
Current wording in the techniques:
H2 Combining adjacent image and text links for the same resource
Sometimes the text and the icon link are rendered in separate, adjacent table cells to facilitate page layout. Note that CSS, rather than a layout table, is preferred to ensure the proper layout. If CSS is used, this technique can be applied to combine the links.
H39 Using caption elements to associate data table captions with data tables
Use of layout tables is not recommended. However, if layout tables are used, then the caption element is not recommended. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A caption would “break" this transparency by calling attention to the table.
H73 Using the summary attribute of the table element to give an overview of data tables
Use of layout tables is not recommended. However, if layout tables are used, then the summary attribute is not recommended. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A summary would “break" this transparency by calling attention to the table. A null summary (summary="") on layout tables is acceptable.
F46 Failure of SC 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables
While the preference is to use CSS for visual formatting, tables are often used to visually layout content in an HTML document. When a table is used for layout purposes the th element should not be used. Since the table is not presenting data there is no need to mark any cells as column or row headers. Likewise, there is no need for an additional description of a table which is only used to layout content. Do not include a summary attribute and do not use the summary attribute to describe the table as, for instance, "layout table". When spoken, this information does not provide value and will only distract users navigating the content via a screen reader. Empty summary attributes are acceptable on layout tables, but not recommended.
F49 Failure of SC 1.3.3 due to changing the meaning of content by positioning information with HTML layout tables
Has nothing about layout tables not being recommended.
Discussed in the 07 September 2006 telecon:
resolution: unanimous acceptance of Team b and team c items that everyone agreed with
Team B: LC-540, LC-759, LC-932, LC-1298, LC-1381
Team C: LC-673, LC-1407, LC-1166
http://www.w3.org/WAI/GL/2006/09/07-wai-wcag-minutes.html
[accept]
DONE In H2, change "Sometimes the text and the icon link are rendered in separate, adjacent table cells to facilitate page layout. Note that CSS, rather than a layout table, is preferred to ensure the proper layout. If CSS is used, this technique can be applied to combine the links." to "Sometimes the text and the icon link are rendered in separate, adjacent table cells to facilitate page layout. Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. If CSS is used, this technique can be applied to combine the links."
DONE In H39, change "Use of layout tables is not recommended. However, if a layout table is used, then the caption element is not recommended." to "Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. If a table is used for layout, the caption element is not used."
DONE In H73, change "Use of layout tables is not recommended. However, if layout tables are used, then the summary attribute is not recommended." to "Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. However, if a layout table is used, then the summary attribute is not used or is null."
DONE In F46, change "While the preference is to use CSS for visual formatting, tables are often used to visually layout content in an HTML document." to "Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content."
DONE In F49, insert the following as the first paragraph of the description: "Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. If a layout table is used, however, it is important that the content make sense when linearized."
Internal WD updated 9 Sept.
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0051.html
Resolution: Techniques H2, H39, H73, F46, and F49 have been modified to clarify the recommendation that layout tables not be used. (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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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
Related issues: (space separated ids)
WG Notes: [TEAMB]
Discussed in the 08 February 2007 telecon:
No resolution
http://www.w3.org/WAI/GL/2007/02/08-wai-wcag-minutes.html
Discussed in the 01 March 2007 telecon:
Accept as amended.
http://www.w3.org/WAI/GL/2007/03/01-wai-wcag-minutes.html
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0004.html
Resolution: Because assistive technology may not be able to preserve shape, size, visual location, or orientation of components when it transforms content to an alternate presentation, this success criterion has been moved to level A. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes: [TEAMC]
Becky - I think this is as much of a usability as an accessibility issue since non-web safe colors may render unexpectedly for all users. I'm also not sure how we would classify "older user agents" - are there certain versions we can refer to. Isn't this a non-issue if the luminosity contrast calculates properly?
David - I've looked into this and there is no strong evidence that non-web safe colors cause significantly accessibility barriers. See also
http://www.accessifyforum.com/viewtopic.php?t=1149
This was an issue the Canadian Government wanted me to address with the committee. They are requiring web safe colors but I don't think we should. SO I am proposing re-jecting it.
There is however, one related thing we need to clear up in 1.4 contrast. When we do forground background contrast checks. If the monitor is dithering, we will get very different results based on which pixel we chose as the foreground and background. Because dithering is several colours side by side. eh. Red and yellow make orange. Some pixels might be darker than other even though they are side by side. I explore this issue with graphical demonstrations here
http://www.eramp.com/david/general/dithering.htm
Discussed in the 01 February 2007 telecon:
Resolution: accepted by unanimous consent
http://www.w3.org/WAI/GL/2007/02/01-wai-wcag-minutes.html
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0051.html
Resolution: The group does not have any evidence of significant accessibility issues arising from the use of non-safe web colours. The Web-safe colour palette is the 216-colour intersection of the 256-colour palettes of the Windows and Mac OS of the 1990's. Neither Windows nor Mac uses those palettes by default, nor do Unix variants, so this concern appears to have been overcome by technology advances. (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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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)
Related issues: 1097
(space separated ids)
WG Notes: THIS IS A VERBATIM DUPLICATE OF 1097 (except this is filed against HTM and the other against WCAG. Same SC)
[TEAMC]
Same as LC-1097
Resolution: This example illustrates the use of techniques for both 2.2.6 and 2.2.1. To make this clear, we have added a note that reads, "Refer to [Techniques for Addressing Success Criterion 2.2.1] for techniques related to providing notifications about time-outs." to the listing of sufficient techniques in 2.2.6. (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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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
Related issues: (space separated ids)
WG Notes: [TEAMB]
Discussed in the 31 August 2006 telecon:
resolution: sent back to Team B to consider survey comments.
http://www.w3.org/WAI/GL/2006/08/31-wai-wcag-minutes.html
Discussed in the 07 September 2006 telecon:
sent back to Team to consider comments
http://www.w3.org/WAI/GL/2006/09/07-wai-wcag-minutes.html
Discussed in the 14 September 2006 telecon:
Resolution: refer link text issues back to team B with the understanding that Ben's format will be used for the definition and the 2.4.8 supplemental language gets worked out and Loretta and David work out the link focus issue for 2.4.4. Accept the rest of the resolution as proposed pending resolution of the previously stated items.
http://www.w3.org/WAI/GL/2006/09/14-wai-wcag-minutes.html
Discussed in the 28 September 2006 telecon:
Resolution:Send "SC 2.4.4 and How to Meet Success Criterion 2.4.4" back to Team B for further work. Action item taken by David to clean up failures and add more examples. Action item by Team B: take survey comments and update Wiki pages to update survey comments, take sufficient techniques and make them general as opposed to specific HTML techniques.
http://www.w3.org/WAI/GL/2006/09/28-wai-wcag-minutes.html
Techniques for paragraph, list itm and table cell remain as HTML techniques, since we need to mention HTML concepts like block element.
Discussed in the 05 October 2006 telecon:
Resolution: accept proposal as amended
http://www.w3.org/WAI/GL/2006/10/05-wai-wcag-minutes.html
Response:http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0073.html
New issue: http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=2324
Resolution: SC 2.4.4 allows for link text such as "Click here" and "more" as long as the purpose of the link can still be determined from programmatically determined context such as the enclosing sentence, paragraph, or list item. We have added such an example to How To Meet SC 2.4.4, to clarify that they are permitted. However, the Intent section of How To Meet SC 2.4.4 has been changed to encourage authors to make the link text as meaningful as possible.
(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
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Small sites: What if a site is only three pages - is it still required to provide a breadcrumb trail etc?
Proposed Change:
Clarify SC
Related issues: LC-1193
(space separated ids)
WG Notes: [TEAMB]
Sent to survey 17 Aug. Edited for comments, 18 Aug. We still need to resolve the "set of web units" issue.
Discussed in the 24 August 2006 telecon:
resolution: 1113 back to team B
http://www.w3.org/WAI/GL/2006/08/24-wai-wcag-minutes.htm
Discussed in the 31 August 2006 telecon:
resolution: accept LC-1113 as proposed
http://www.w3.org/WAI/GL/2006/08/31-wai-wcag-minutes.html
{accept}
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0070.html
Resolution: Even for a small site, understanding your location within the site may be desirable. However, there are sites for which this success criterion would not make sense, which is why it is at Level AAA.
This success criterion does not intend to suggest that breadcrumbs are required of all web sites. Breadcrumbs are merely one option for meeting this success criterion. It might be more appropriate to use one of the other listed techniques. There may also be techniques that are appropriate for orienting a user on a small web site that would not be appropriate on a large web site, such as providing links to the home page. (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Add a technique (or example) to use the LINK REL attributes of Next, Index etc
Related issues: (space separated ids)
WG Notes: [TEAMB]
Discussed in the 27 July 2006 telecon:
resolution: accept LC-1114 as amended
http://www.w3.org/WAI/GL/2006/07/27-wai-wcag-minutes.html
{already covered}
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0069.html
Resolution: These are described in the HTML technique "H59: Using the link element and navigation tools [1]", which is listed in the technology-specific techniques for SC 2.4.7.
[1] http://www.w3.org/TR/WCAG20-TECHS/Overview.html#H59 (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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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.
Related issues: (space separated ids)
WG Notes: [TEAMB]
SC 3.2.4 should address some of these issues.
Is a UAAG requirement like showing visited links an issue that we need to address for programming technologies that are implementing their own UI? Or is this already covered by SC 4.1.2?
Discussed in the 31 August 2006 telecon:
accept LC-980, LC-1113, LC-1293, LC-996, LC-694 as proposed by unanimous consent
http://www.w3.org/WAI/GL/2006/08/31-wai-wcag-minutes.html
Resolution: Success criterion 3.2.4, "Components that have the same functionality within a set of Web pages are identified consistently." means that links that go to the same place should have the same description. If links that go to different places have the same description, then the description is not sufficient to determine the purpose of the link. The Intent section of How To Meet SC 2.4.4 points this out: "Links with the same purpose and destination are associated with the same description (per Success Criterion 3.2.4), but links with different purposes and destinations are associated with different descriptions."
Showing links that have been visited is a User Agent responsibility, and is required by Checkpoint 10.2 of the User Agent Accessibility Guidelines (Highlight selection, content focus, enabled elements, visited links). Success Criterion 4.1.2 has been modified to require that the state of interactive controls be programmatically determined, so that user agents can satisfy this requirement.
Avoiding unnecessary text repetition is an issue that the working group has struggled with. Often, text repetition is introduced by the desire to have link descriptions that make sense when read out of context. SC 2.4.4 permits links to have descriptions that depend on their context, so that contextual information won't have to be repeated.
(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)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :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
Related issues: (space separated ids)
WG Notes: [TEAMC]
Discussed in the 17 August 2006 telecon:
resolution: unanimous consent to accept the following proposals from the Editorz: LC-847, LC-849, LC-850, LC-1006, LC-987, LC-936, LC-890, LC-852
resolution: unanimous consent to accept the following proposals from Team C: LC-1047, LC-1082, LC-1089, LC-1116, LC-1117, LC-1196, LC-1326
resolution: unanimous consent to accept the following proposals from Team B: LC-1127
http://www.w3.org/WAI/GL/2006/08/17-wai-wcag-minutes.htm
{partial-accept}
DONE Modify first example in the HTM 2.5.1 to:
• Identifying errors in a form submission.
An airline Web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, phone number, seating preference and e-mail address. If any of the fields of the form are either not completed or completed incorrectly, an alert is displayed notifying the user which field or fields were missing or incorrect.
Updated internal WD 25 August.
Resolution: You are right that the success criteria doesn't require all correctly filled out fields to be kept available after reload. We don't believe we can require this at Level A, however, as there may be valid reasons, such as security and privacy, for not doing this. We have modified the example to use an alert instead of a page reload. If authors use this technique, a good benefit is that the user's original entries will be preserved even though the success criterion doesn't require it. (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 .