W3C

Disposition of comments for the Accessibility Guidelines Working Group

Single page view

1-20 21-40 41-60 61-80 81-94

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-670 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Tests
Comment Type: TE
Comment (including rationale for proposed change):

First step in test should be to check if longdesc is required.

Proposed Change:

Add first step \"Check if short text alternative is sufficient for image\". If not sufficient then go on to step 2.
Since this technique is specifically about using a longdesc and a list of related techniques describing alternative techniques for including text alternatives is provided, the Working Group does not believe that the test procedure needs to determine whether or not a short text alternative is sufficient. A developer implementing this technique has already determined that a longdesc is necessary; the test procedure just needs to check whether the longdesc has been created correctly. tocheck
LC-672 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):

H51 seems to be the same as F34 \"using white space characters to format tables in plain text content\".

Proposed Change:

Remove either H51 or F34 or describe difference between them.
Technique H51 is specific to HTML and F34 is specific to plain text. F34, Failure due to using white space characters to format tables in plain text content, does prevent tabular data in plain text content. An author using plain text must present the data in a format other than tabular (e.g. linear format). tocheck
LC-676 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):

Labeling of form controls is covered by H44 so these 2 techniques should be rolled into one.

Proposed Change:

Combine H65 and H44 into one technique or clarify differences between the two.
The Working Group strives to make each individual technique as specific as possible. Both techniques are about labelling form controls but they use two different strategies to provide the label. H44 uses the label element and H65 describes the use of the title attribute on a form control and are applicable in different situations. Thus, the Working Group believes that the techniques should remain separate. tocheck
LC-680 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

All layout tables have no summary? What about first first layout table with description? Could be others too. A description of layout table is beneficial in some cases.


Proposed Change:

Allow for summary on first level layout table if summary describes navigation of table.
The working group has received a lot of feedback that users do not want summaries on layout tables because their use can cause assistive technologies to announce unnecessary information about tables or to attempt to parse the table as though it were a data table.

In light of the above, if you have data that supports your suggestion that a summary on the first layout table is beneficial, please submit it for our consideration.
tocheck
LC-699 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Does not apply to all text. Only text that is relative, pertains or necessary.

Proposed Change:

Change wording so it applies only to necessary text.
While there are exceptions within the success criterion about when 5:1 or 7:1 contrast requirements would be required, the technique describes how to determine whether enough contrast exists to meet the success criterion. Because different techniques apply in different situations, the working group does not feel that it would be practical to attempt to describe the exceptions and situations which makes a technique sufficient or applicable within the techniques themselves. Also, the word 'important' is not sufficiently unambiguous to make such a success criterion testable. Instead, authors would refer to the How to Meet documents to determine which techniques are sufficient to meet the success criteria. tocheck
LC-702 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Not a good technique. Jim Thatcher\'s article (referenced from this technique) says \"Better than such a \"jump table\" would to be to markup the sections with headings markup\".
Also better is to create an index.

Proposed Change:

Remove technique or provide examples of how it\'s more useful than other techniques.
This technique is not necessarily more useful than other techniques. However, the working group felt it was sufficient to meet the criterion. tocheck
LC-705 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Too broad and undefined. How many links? Where should they be placed? All documents? Which terms? This technique is untestable as is.

Proposed Change:

Clarify the technique so it is more specific.
The technique is the "standard" use of hyperlinks on the internet to connect related information. If following any series of links can be used to locate information in the set of Web pages, that is a use of this technique. This technique does not specify how many links on a page, where they should be placed, or how they should be used. As long as links are used in a reasonable way, it should be nearly impossible for content to fail to use this technique.

We would welcome suggestions for ways to make the description of the technique clearer.
tocheck
LC-707 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Good technique but which sites require a sitemap? Should sitemap really contain *all* links? Contain hierarchy, structure? Alphabetic, category? Same as site\'s organization?

Proposed Change:

Describe when to use sitemap instead of other organizational structures. Provide other examples of good sitemaps and describe characteristics of bad sitemaps.
Thank you for your comments. A sitemap is one possible technique available for satisfying SC 2.4.7, but it is not required for any site, as long as the success criterion is satisfied.

Sitemaps that contain links to all pages in the site satisfy this technique, but the technique can be satisfied with fewer links.

There are a variety of ways in which a site map might be organized. We encourage you to send suggestions for ways in which the test procedure might be able to check whether the site map reflects the site's organization.
tocheck
LC-710 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Refers only to change of focus but problem can occur with other actions. i.e. select, onmouseout, onblur or page loading etc.

Proposed Change:

Broaden the technique to include other actions that should not cause change of context. Or describe exactly what constitutes an \"activate\" action.
This is a general technique, rather than an HTML technique, which is why the general concept "activate" is used rather than a technology-specific event. The success criterion only identifies changes of focus as actions that should not cause changes of context, although as you point out, changing context on other types of actions can also be problematic. Focus is singled out because it is often unavoidable when navigating content via the keyboard.

Note also that issues with page loading are covered in F52, onblur in F55 and that actions such as select are covered in techniques for SC 3.2.2 (on Input) and onmouseout in SC 2.1.1 (Keyboard).
tocheck
LC-768 Joe Clark 3 <joeclark@joeclark.org> (archived comment)
Comment (including rationale for any proposed change):

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

Trivial examples

One of the most common examples of using inconsistent labels for components with the same function is to use a button that says "search" in one page and to use a button that says "find" on another page when they both serve the identical function.

And the words have identical meaning.

Proposed Change:
Trivial examples can still be helpful if they illustrate the issue. Since the words are being used with identical meaning, there is no reason to change the word from page to page, which requires a person to think about whether they are being used identically. Using inconsistent labels also makes it harder for a person to jump to the button quickly if his user agent provides quick methods for navigating to controls by searching for their name. tocheck
LC-770 Joe Clark 3 <joeclark@joeclark.org> (archived comment)
Comment (including rationale for any proposed change):

Testing in browsers

The blink value of the text-decoration property is not supported by Internet Explorer. For Windows or Mac? It is supported in Netscape/Mozilla family browsers. Not tested in others (e.g., Safari, Opera). And why wasn't it tested in those "others"?

Proposed Change:
The Working Group does not have the resources to test all techniques in all operating systems, user agents and available assistive technologies, but welcomes any assistance in testing and documentation of these issues for future drafts. When information is available it is provided in the User Agent and Assistive Technology Support Notes section. This technique has been updated to specify the operating system used for testing and now reads:

The blink element is not supported by Internet Explorer 6 in Windows. It is supported in Netscape/Mozilla family of user agents and Opera on Windows.
tocheck
LC-773 Joe Clark 3 <joeclark@joeclark.org> (archived comment)
Comment (including rationale for any proposed change):

CSS defines the blink value for the text-decoration property. When used, it causes any text in elements with this property to blink at a predetermined rate. This cannot be interrupted by the user, nor can it be disabled as a user-agent preference.

User stylesheets would seem to be useless in this regard, as they do not permit the rewriting of selectors. However, User Agent Accessibility Guidelines [4] Checkpoint 3.3 requires the ability to toggle blinking text. This appears to be a user-agent problem, in whole or in part.

Proposed Change:
The Working Group agrees that the ability to stop blink should be provided by user agents. However, real accessibility problems occur when user agents fail to do this, and this is a widespread problem. Therefore a failure technique to cover this situation was included in WCAG. Failures, like techniques, are non-normative, and can be easily changed when user agents catch up. If in the future user agents do provide this functionality as required by UAAG, the author's responsibility to do this in order to ensure conformance to this SC would be absolved, and we can update our techniques. tocheck
LC-778 Joe Clark 3 <joeclark@joeclark.org> (archived comment)
Comment (including rationale for any proposed change):

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

A user clicks on a link, and a new window appears. The original link has no associated text saying that it will open a new window. [...] Check if elements that open new windows have associated text saying that will happen. The text can be displayed in the link, or available through a hidden association such as an HTML title attribute.

target="_blank" is programmatically determinable and it is up to the user agent to warn the user. JavaScript is another story and should be addressed by the Techniques.

Proposed Change:
You are correct that target="_blank" is programmatically determinable, but the working group does not feel that it is sufficient for a content provider to rely on this feature to satisfy SC 3.2.5. It is intentional that WCAG 2.0 bans all popup windows without explicit alert beforehand at Level AAA. tocheck
LC-589 Martin Stehle <pewtah@snafu.de> (archived comment)
Comment (including rationale for any proposed change):

The note "These techniques may need to be adapted for Web-based presentation" is not really helpful.

Proposed Change:

Link to examples, e.g. http://www.taubenschlag.de/videos/index.html. Add a english translation of the German guidelines for Sign Language Videos.
"These techniques may need to be adapted for Web-based presentation" is helpful because it makes it clear that there may be some distinctions between what works on TV and what works on the web. It is a sort of disclaimer that says "here are some resources that may help, but be aware that they are not designed for the web and although some strategies might be useful, others may not be transferable to the web." It is beyond the scope of these guidelines to go further than that. If someone provides techniques for web videos we will be glad to link to those.

It is beyond the scope of this group to translate German techniques documents. If somemone else does it, we will be glad to link to them if they will be helpful in meeting our guidelines.
yes
LC-834 Rick Hill <rrhill@ucdavis.edu> (archived comment)
4. You can’t use offscreen positioning to add labels (e.g., to forms)
that only some people, like users of assistive technology, can
perceive. Everybody has to see them.
This technique describes a way to add hidden text to links, not to add labels to form fields. For links, this can be useful when sighted users are using the context of a link to interpret its text, but the context is not easily available to users of assistive technology.

We agree that it is not appropriate to use such a technique for adding labels to forms.
tocheck
LC-560 Bruce Bailey <bruce.bailey@ed.gov> on behalf of DoED/OCIO (archived comment)
Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):

G14 is associated with 1.3.2. As written, it is too restrictive and is more applicable to 1.3.4. Unfortunately, that does not leave a technique for 1.3.2.

I have also commented that 1.3.4 may be rated at too low a level. This comment assumes that 1.3.2 and 1.3.4 remain unchanged.

Proposed Change:

Associate G14 with 1.3.4.

Just one idea: Add a technique for 1.3.2 where red H3 headings are underlined and green H3 headings are italicized.
We have added a technique to Situation A in "How to meet 1.3.2" that reads, "Ensuring that when text color is used to convey information, the text style is visually differentiated without color." yes
LC-523 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Item Number: H1: Adding the dir attribute to a block level element to change its directionality...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):

Says H1 is referenced from 1.3.1 but it's not. It is referenced from 1.3.3.

Proposed Change:

H1 could fall under both 1.3.1 and 1.3.3. Fix applicability so it falls under the appropriate SC.
Thank you for catching this error. After reviewing comments from the Internationalization Working Group, we believe the direction of text is only an accessibility issue when it affects the proper sequencing of mixed-direction text, so we have deleted this technique. tocheck
LC-701 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Confusing technique.
Does Jim Thatcher\'s article state this?
Examp1e 1 \"Skip navigation links\" is same as G1.
It seems that breaking up the page into several pages would be better.

Proposed Change:

Provide more examples of where this is used to clarify its use.
While Jim Thatcher's article does not include this technique, we think it is a generally helpful resource for Skip Navigation. We have also added a reference to the Navigation Section of his Web Accessibility tutorial, which includes some examples of pages with multiple sets of navigation links.

We have updated the descriptions of techniques G1, G123, and G124 to indicate when they might be most effective for different types of content.

New Description for G1 (http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/#G1 ):
"The objective of this technique is to provide a mechanism to bypass blocks of material that are repeated on multiple Web units by skipping directly to the main content of the Web unit. The first interactive item in the Web unit is a link to the beginning of the main content. Activating the link sets focus beyond the other content to the main content. This technique is most useful when a Web unit has one main content area, rather than a set of content areas that are equally important."

New Description for G123 (http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/#G123 ):
"The objective of this technique is to provide a mechanism to bypass a block of material by skipping to the end of the block. The first link in the block or the link directly preceding the block moves focus to the content immediately after the block. Activating the link advances the keyboard focus past the block. When there are multiple blocks to be skipped, the user skips from block to block via these links."

New Description for G124 (http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/#G124 ):
"The objective of this technique is to provide a mechanism to bypass blocks of material by providing a list of links to the different sections of the content. The links in this list, like a small table of contents at the beginning of the content, set focus to the different sections of the content. This technique is particularly useful for pages with many independent sections, such as portals. It may also be combined with other techniques for skipping blocks within a section."

Added Example 4 to G123 (http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/#G123 ):
Example 4: HTML page with several blocks of navigation links
This example demonstrates both the use of Heading elements at the beginning of each section (H69) and links that skip to the end of each section. This allows people to skip blocks of repeated content using keyboard navigation or using heading navigation, depending on the capabilities of their user agents. Note that some sections of the content are wrapped in a <div> element to work around a limitation of Internet Explorer (see the User Agents Notes for [Creating HTML links to skip blocks of content]).
tocheck
LC-665 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):

There needs to be a technique the describes how to include words within an image in the alternate text.

Proposed Change:

All text within the image that is relative to the document should be included in the alternate text. Relates to technique H36 and others.
The working group believes that the technique you are requesting is covered by example 1 of technique H37 and thus, there does not need to be a specific technique covering words in images. However, we have updated techniques H37 and G94.

We have added the following to the description of H37: When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a longdesc should be provided as well with the complete text.

We have updated example 1 in H37 to:
Example 1. An image on a website provides a link to a free newsletter. The image contains the text "Free newsletter. Get free recipes, news, and more. Learn more." The alt text matches the text in the image.

We have also added the following test procedure to H37:
1. Examine each img element in the content
2. Check that each img element which conveys meaning contains an alt attribute.
3. If the image contains words that are important to understanding the content, the words are included in the text alternative.

We added the following expected results to H37:
Check #2 is true. If the non-text content contains words that are important to understanding the content, Check #3 is also true.

We also added the following to the description of G94:
"When non-text content contains words that are important to understanding the content, the alt text should include those words. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a long text alternative should be provided as well with the complete text."

We added the following example to G94:
A heading contains a picture of the words, "The History of War" in stylized text. The alt text for the picture is "The History of War".

We added the following item to the test procedure of G94:
4. If the non-text content contains words that are important to understanding the content, the words are included in the text alternative.

We have updated the Expected results of G94 to:
Step 3 is true. If the non-text content contains words that are important to understanding the content, Step 4 is also true.
tocheck
LC-666 Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived comment)
Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):

None of the tests are expressed as testable statements. None of the tests have examples.
Tests already exist at:
http://www.w3.org/WAI/GL/WCAG20/tests/

Proposed Change:

Express the tests as testable statements. Include example files.
Use the existing tests.
Each of the techniques has a test procedure and an expected result from the procedure. We have test files (actually example files for pass and failure) for some of the techniques, most of which came from the location you cited http://www.w3.org/WAI/GL/WCAG20/tests/ There is now a joint task force with ERT WG that will be working on identifying or developing sample files for the other techniques. tocheck

1-20 21-40 41-60 61-80 81-94


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