- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:32:01 -0700
- To: "Chris Ridpath" <chris.ridpath@utoronto.ca>
- Cc: public-comments-WCAG20@w3.org
Comment 30:
Source: http://www.w3.org/mid/20060602153215.7560633205@kearny.w3.org
(Issue ID: LC-698)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
Very broad. Should only be used when there is ambiguity. i.e. if there
is only one image then OK to refer to it as \"see image below\".
Does the use of \"top\" (WCAG2 navigation buttons) fall under this?
What about G74 that uses text \"Details in text following the chart:\"
Proposed Change:
Make it clear that this is needed only if there is ambiguity.
----------------------------
Response from Working Group:
----------------------------
Note that we already have a failure (F1: Failure of SC 1.3.3 due to
changing the meaning of content by positioning information with CSS)
that addresses part of your comment.
With regard to ambiguity, even with only one image, if it is referred
to by position, as in "see image below", it could be misleading as
users may not find the image "below". Regarding links to the top of
the page, the link does not violate this success criterion as it is
not identified by or referred to by shape or position. The fact that
the link targets the top of the page is a different issue not related
to this success criterion, since it describes where the link will go,
rather than instructing the user where to find something. Regarding
G74, this does not violate the success criterion since the language
used is "sequential" rather than "spatial" ("following", not "below").
A note was added to How to Meet 1.3.5 to clarify that aspect.
----------------------------------------------------------
Comment 31:
Source: http://www.w3.org/mid/20060602153423.308A733205@kearny.w3.org
(Issue ID: LC-699)
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.
----------------------------
Response from Working Group:
----------------------------
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.
----------------------------------------------------------
Comment 32:
Source: http://www.w3.org/mid/20060602161944.3613966363@dolph.w3.org
(Issue ID: LC-700)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
Should be modified so you must set all colors or no colors. (i.e. Just
specifing text and background colors without vlink colour is wrong)
Proposed Change:
Change text so it says \"set all colors or no colors\".
----------------------------
Response from Working Group:
----------------------------
The current title already talks about foreground colors (plural). To
address your issue we have added a note to F24 (Failure of SC 1.4.2
(formerly 1.4.1) due to specifying foreground colors without
specifying background colors or vice versa):
NOTE: All states of the text should be included. For example, text,
link text, visited link text etc.
----------------------------------------------------------
Comment 33:
Source: http://www.w3.org/mid/20060602180530.90B5BDAF01@w3c4-bis.w3.org
(Issue ID: LC-702)
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.
----------------------------
Response from Working Group:
----------------------------
This technique is not necessarily more useful than other techniques.
However, the working group felt it was sufficient to meet the
criterion.
----------------------------------------------------------
Comment 34:
Source: http://www.w3.org/mid/20060602181106.3B07247BA5@mojo.w3.org
(Issue ID: LC-703)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
It\'s unclear how many are in a group.
\"related\" is not defined. Are all links on a page related?
Proposed Change:
Navigation and menu are good examples. Provide other examples or keep
it to navigation and menu or define what \"related\" links are.
----------------------------
Response from Working Group:
----------------------------
The purpose of this technique is to define how to use structural
markup in HTML to group sets of links. The links to be grouped are
defined by the success criterion, that is, groups of links that are
repeated on multiple pages. We have modified the test procedure so
that it no longer requires identifying why the links are being
grouped, but just checks for appropriate grouping markup.
----------------------------------------------------------
Comment 35:
Source: http://www.w3.org/mid/20060602182328.9EA52DAF01@w3c4-bis.w3.org
(Issue ID: LC-704)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
This technique suggests that using frames to group material is on par
with using headers, div\'s, link groups etc. Is that the intent?
Is this really a problem? Are there examples of sites that change
frame content types?
The requirement for NOFRAMES has been dropped. Is this an oversight or
is NOFRAMES really no longer necessary?
Proposed Change:
Add text that explains this technique is useful *if* frames are used
in the page. If frames are not used then don\'t add them just for
grouping blocks of material.
----------------------------
Response from Working Group:
----------------------------
Thank you for the suggestion. We added a noframe element to the
example, and clarified that this technique is appropriate when frames
are already being used.
The following changes were made:
In H70, we changed applicability to "HTML 4 and XHTML 1.0 documents
that use frames"
Added noframes element to example as third item of frameset:
Added second paragraph to description:
This technique is appropriate when framesets are already used to
organize the content of the page; other techniques are preferred for
pages that are not already using framesets. An advisory technique
about using noframes is available in SC 4.2.1.
Added to resources for H70:
Accessible Navigation
Added to resources for H64:
Accessible Navigation, "Implementing Frame Titles"
----------------------------------------------------------
Comment 36:
Source: http://www.w3.org/mid/20060602182732.B9931DAF01@w3c4-bis.w3.org
(Issue ID: LC-705)
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.
----------------------------
Response from Working Group:
----------------------------
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.
----------------------------------------------------------
Comment 37:
Source: http://www.w3.org/mid/20060602183116.ADB50DAF01@w3c4-bis.w3.org
(Issue ID: LC-706)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
Too broad. Not all documents require a TOC so must specify which ones do.
Is this the same as navigation links?
Is this for a document or whole site?
Proposed Change:
Specify when this is needed.
Describe how this is different from navigation links.
Describe how TOC for document is different from TOC for site.
----------------------------
Response from Working Group:
----------------------------
This technique satisfies Success Criterion 2.4.5, "More than one way
is available to locate content within a set of Web pages where content
is not the result of, or a step in, a process or task." There must be
several ways to locate any of the Web pages in a set, although they
needn't be the same for all the Web pages in the Web site.
We have expended the description in this technique to clarify when a
Table of Contents is appropriate. This is a potential technique to
satisfy Success Criterion 2.4.5 for any document that is represented
as multiple Web pages. Documents that are represented as a single Web
page may also provide a table of contents, but this success criterion
does not apply to that situation.
----------------------------------------------------------
Comment 38:
Source: http://www.w3.org/mid/20060602183640.1CCDE47BA5@mojo.w3.org
(Issue ID: LC-707)
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.
----------------------------
Response from Working Group:
----------------------------
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.
----------------------------------------------------------
Comment 39:
Source: http://www.w3.org/mid/20060602191328.9C91466363@dolph.w3.org
(Issue ID: LC-708)
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
The text \"modify or delete data in data storage systems\" is very
broad. Even submitting a search to Google will do this - Google will
store info about your request.
Proposed Change:
Add text that describes data as important or non trivial to enter again.
----------------------------
Response from Working Group:
----------------------------
We have revised this to read:
2.5.3 Error Prevention: For forms that cause legal commitments or
financial transactions to occur, that modify or delete
user-controllable data in data storage systems, or that submit test
responses, at least one of the following is true:
1. Reversible: Transactions are reversible. [LC-1196]
2. Checked: Submitted data is checked for input errors before going
on to the next step in the process.
3. Confirmed: A mechanism is available for reviewing, confirming,
and correcting information before finalizing the transaction.
----------------------------------------------------------
Comment 40:
Source: http://www.w3.org/mid/20060602191816.2C40A66363@dolph.w3.org
(Issue ID: LC-709)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
Very broad. How long before deleted material is really gone? Is
recovering from backup OK. Call to admin required to regain backup OK?
Type of information is not specified. Could be trivial information
like stored by search engine.
Proposed Change:
Add text to explain that this applies only to non trivial information.
Or info that is difficult to enter again. Define parameters for
getting backup. Can\'t be difficult like phoning sys admin.
Put a time limit on getting backup info. Perhaps session timeout.
----------------------------
Response from Working Group:
----------------------------
This is a general technique and will need to be executed by
server-side methods. The working group will not be making specific
server-side techniques and so the technique needs to be broad to cover
the many ways of accomplishing the retrieval of information needed to
correct the transaction. There is a time limit given in the technique
of 1 week. These are web content guidelines so by definition the
technique does not apply to non web actions like making a phone call
to system admin.
We have added text to explain that the retrievable information that is
stored is that which would be needed to correct the transaction.
----------------------------------------------------------
Comment 41:
Source: http://www.w3.org/mid/20060602192548.7FF1E47BA5@mojo.w3.org
(Issue ID: LC-710)
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.
----------------------------
Response from Working Group:
----------------------------
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).
----------------------------------------------------------
Comment 42:
Source: http://www.w3.org/mid/20060602193554.2A18847BA5@mojo.w3.org
(Issue ID: LC-711)
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
The \"set of web units\" is not defined. Does this include every single page?
Proposed Change:
Define which pages of the site must have this. Or describe exclusions.
----------------------------
Response from Working Group:
----------------------------
We have changed the title of the failure to indicate that the web
pages are part of the same set of web pages, and we have added "set of
web pages" to the glossary
(http://www.w3.org/TR/2007/WD-WCAG20-20070517/#set-of-web-pagesdef ):
set of Web pages
collection of Web pages that have a specific relationship to
each other and that are created as a body of work by an author, group
or organization
----------------------------------------------------------
Comment 43:
Source: http://www.w3.org/mid/20060621144200.17FD733201@kearny.w3.org
(Issue ID: LC-841)
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
The Success Criterion (1.3.1 level 1) that calls for the presence of
labels is at a different level from the Success Criterion (2.4.5 level
3) that requires the labels actually describe the item. This applies
to such items as form labels, headings, titles and table captions.
This is an inducement for placeholder text and will functionally
decrease accessibility. Examples: web pages with the title \"title
goes here\", table captions of \"table caption\" and form control
labels \"control name goes here\" are perfectly acceptable. If the
requirements for the presence of the label are lower than the
requirement than the label actually be descriptive it will be an
incentive for authoring programs to put in placeholder text. Requiring
that a label be present without a requirement that the label be useful
does not make sense.
Proposed Change:
Change the level of SC 2.4.5 to level 1 (same level as SC 1.3.1).
Or remove SC 2.4.5 and modify SC 1.3.1, SC 2.4.3 and any SC that
requires text so they include the text from SC 2.4.5. Example: change
SC 2.4.3 so it reads \"Web units have titles that describe the web
unit\".
----------------------------
Response from Working Group:
----------------------------
Success criteria 1.3.1 does not require the presence of labels,
headings, titles, or table captions which would affect the design of
the page. It only requires that if these items are present on the
page, they must be coded so that the structure can be determined
programmatically.
A new Level AAA success criteria has been added, SC 2.4.9 "Where
content is organized into sections, the sections are indicated with
headings.".
We have added "descriptive" to SC 2.4.2 (formerly 2.4.3) and moved it
to level A.
SC 2.4.6 (formerly 2.4.5) has been moved to Level AA. It addresses
descriptive headings and labels, which may need to be understood in
context. While headings may not have sufficient descriptive power in
isolation, when viewed in the context of a structured document, they
do have sufficient descriptive power.
----------------------------------------------------------
Comment 44:
Source: http://www.w3.org/mid/20060621172836.CD8A733201@kearny.w3.org
(Issue ID: LC-872)
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
Success Criterion 2.4.4 should be at level 1 and is currently at level
2. Good link text is very important for people with visual impairments
as well as people with cognitive impairments. Poor link text was
identified as a key problem in the DRC report
(http://www.drc-gb.org/PDF/2.pdf). Good link text is at least as
important as skip-navigation links which is at level 1.
Proposed Change:
Move SC 2.4.4 to level 1.
----------------------------
Response from Working Group:
----------------------------
This success criterion has been moved to level A because without it,
it requires significantly greater effort (and keystrokes) for
assistive technology users to determine link context.
----------------------------------------------------------
Comment 45:
Source: http://www.w3.org/mid/20060621175238.786B5DAEA3@w3c4-bis.w3.org
(Issue ID: LC-873)
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
There needs to be a SC for color contrast at level 1. Documents with
very poor contrast between text and background do not provide even a
minimum level of accesibility.
The guideline text starts with \"Make it easy...\" which means the
user should not have to work to get color contrast. Highlighting text
within the document to change the contrast is not easy for many people
with disabilities and should not be taken as a method of meeting the
SC.
This has been discussed recently on the WCAG list but there was no
resolution so I\'m submitting this comment.
Proposed Change:
Create a SC for color contrast at level 1. The luminosity ratio should
be similar to what is currently at level 2 (5:1).
----------------------------
Response from Working Group:
----------------------------
The description of conformance levels in WCAG 2 has been rewritten to
clarify the levels (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels).
Because level A attempts to put the fewest possible limitations on
presentation, and because assistive technology will be able to present
the text or text equivalents of this content to the user, the working
group felt that this was most appropriate at level AA.
----------------------------------------------------------
Comment 46:
Source: http://www.w3.org/mid/20060621180109.22C8BBDA8@w3c4.w3.org
(Issue ID: LC-874)
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
It\'s still unclear what \"parsed unambiguously\" means when applied
to CSS documents. Even a loose interpretation is still a heavy burden
for authors as this SC is level 1 and may not improve accessibility.
(This was discussed on list but no resolution.)
Proposed Change:
Clearly define what \"parsed unambiguously\" means when applied to CSS
documents. Move SC to level 2 for CSS documents.
----------------------------
Response from Working Group:
----------------------------
To make this requirement easier to understand, we have reworded SC
4.1.1 to clarify that it must be possible to parse content without the
need for user agent repair. The revised SC reads as follows:
4.1.1 Content implemented using markup languages has elements with
complete start and end tags, except as allowed by their
specifications, and are nested according to their specifications.
(Level A)
Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quote are not complete.
We believe this is appropriate at Level A for CSS as well as other technologies.
----------------------------------------------------------
Comment 47:
Source: http://www.w3.org/mid/20060621183542.983FF47BA1@mojo.w3.org
(Issue ID: LC-875)
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
The technique H71 (fieldset and legend) under SC 1.3.1 is helpful but
not necessary for all groups of controls. This is now at level 1 and
should be moved to level 2. An example file was posted to the list
(http://checker.atrc.utoronto.ca/docs/file2.html) that is very
accessible and commonly used but fails the SC. Authors should not be
forced to use fieldset and legend for all groups of controls.
Proposed Change:
Move H71 to level 2.
----------------------------
Response from Working Group:
----------------------------
WCAG 2.0 techniques do not have any assigned level. Each technique
provides an example of how to meet one or more success criteria and
are not absolute requirements. There is often more than one technique
that can be used to meet a particular success criterion. Technique
H71 is one mechanism which can be used to meet SC 1.3.1, but is not
the only mechanism. If appropriate technique H44, Using label
elements to associate text labels with form controls can also be used
with radio buttons and check boxes. In order to clarify when
fieldsets are appropriate the following paragraph has been added to
the description of H71:
When a small group of related radio buttons includes clear
instructions and distinct selections it may not be necessary to use
fieldsets and legends; technique H44, Using label elements to
associate text labels with form controls, may also be sufficient.
In addition, your example has been added to technique H44.
Example 3: A small, related group of radio buttons with a clear
description and labels for each individual element. Note: To provide
clear associations and instructions for a large set of related radio
buttons technique H71, Providing a label for groups of radio buttons
or checkboxes using the fieldset and legend elements, should be
considered.
Received on Thursday, 17 May 2007 23:32:21 UTC