Your comments on WCAG 2.0 Last Call Draft of April 2006 (6 of 8)

Comment 75:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1102)

Limiting the number of links per page: Firstly this should be an
advisory technique under a specific SC, not under the entire GL
(otherwise how do we know what level it is aimed at?). Secondly, why
is this a technique? A portal site or a news site etc would have
difficulty complying and I believe the number of links on a page is
entirely dependent on the content. It will be diffiicult to define a
"limit"

Proposed Change:

Remove this advisory technique

----------------------------
Response from Working Group:
----------------------------

Because the technique is advisory, it is not associated with any
level. Levels are associated with conformance statements, but are not
an indication of importance.

This is an advisory technique for the guideline rather than for one of
the success criteria because it does not address any of the success
criteria, but is a technique that can improve the accessibility of the
content for some users.

The technique is also advisory because there is no clear test for how
many links a page could contain before it would fail.

We agree that there are sites, such as portals or news sites, which
would have a difficult time using this technique. Such sites should
use other techniques to make keyboard navigation manageable and to
make the organization of the page easy to understand.

----------------------------------------------------------
Comment 76:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1103)

Frames: 2.4.1 is a Level 1 SC. I don't believe we should be advocating
frames at the minimum level (see Techniques section). There are better
ways to group blocks of repeated content

Proposed Change:

Remove the frame technique

----------------------------
Response from Working Group:
----------------------------

If a page is already using frames, then this is a sufficient technique
for grouping the repeated content. So we are keeping it in the list of
sufficient techniques, but we have added to the technique description
to indicate that other techniques are preferred if the content doesn't
already use frames.

----------------------------------------------------------
Comment 77:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1104)

Heading: Heading "Additional techniques (Advisory) for 2.4.1 should be
the same heading level as "Common failures…"

----------------------------
Response from Working Group:
----------------------------

We have fixed this error.

----------------------------------------------------------
Comment 78:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1105)

Benefits: The benefits section does not describe this SC

Proposed Change:

Rewrite the Benefits section

----------------------------
Response from Working Group:
----------------------------

Thank your for bringing this to our attention. We have changed SC
2.4.2(formerly 2.4.3) to "Web page have descriptive titles" and have
also reflected this change in success criterion 2.4.6 (formerly 2.4.5)
and support documents for both success criteria. The SC 2.4.2 Benefits
section now reads:
- This criterion benefits all users in allowing users to quickly and
easily identify whether the information contained in the Web page is
relevant to their needs.
- People with visual disabilities will benefit from being able to
differentiate content when multiple Web pages are open.
- People with cognitive disabilities, limited short-term memory and
reading disabilities also benefit from the ability to identify content
by its title.
- This criterion also benefits people with severe mobility impairments
whose mode of operation relies on audio when navigating between Web
units.

----------------------------------------------------------
Comment 79:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1106)

Examples: The information provided in the Examples should be in the
Techniques section (eg. Setting the id3 property of an mp3)

Proposed Change:

Rewrite Techniques &/or Examples

----------------------------
Response from Working Group:
----------------------------

Thanks for catching this. Many of the examples were obsolete and have
been removed.

----------------------------------------------------------
Comment 80:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1107)

JPG: Are we requiring that all JPG images have EXIF data?  If not this
example should be removed or moved to advisory.

Proposed Change:

Remove JPG example

----------------------------
Response from Working Group:
----------------------------

We have removed the JPG example.

----------------------------------------------------------
Comment 81:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1108)

TITLE attribute: Recent research has discovered that screen readers
differ in how they read the TITLE attribute and some assistive
technologies, such as magnifiers usually can't access the information
at all.

Proposed Change:

Remove the TITLE attribute technique or specify that it is not
supported on a variety of assistive technology

----------------------------
Response from Working Group:
----------------------------

We have added more user agent and assistive technology limitations in
their support for the title attribute. The working group would like to
see better user agent support for the title attribute, but feels that
this should remain a sufficient technique while efforts to improve
user agent and assistive technology support are made. It has been made
an advisory technique for SC 2.4.8, where the link text itself must be
sufficiently descriptive without depending upon the title attribute
content.

----------------------------------------------------------
Comment 82:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1109)

Supplemental text: I completely disagree with supplementing link text
with hidden text via CSS. If more information is required in order to
understand the link, then it should be available to everyone, not just
people who use screen readers

Proposed Change:

Remove this Technique

----------------------------
Response from Working Group:
----------------------------

The description of this technique indicates that this is an
appropriate technique when information is already provided in the
surrounding context but is needed as part of the link text to
interpret the link text when it is displayed out of context. The
supplementary text would be information that is already available to
all when the link is read in context.

----------------------------------------------------------
Comment 83:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1110)

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

----------------------------
Response from Working Group:
----------------------------

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.

----------------------------------------------------------
Comment 84:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1111)

Example: The text "Example of the results of a failure to meet the
success criterion" is incomprehensible

Proposed Change:

Rewrite example

----------------------------
Response from Working Group:
----------------------------

Thank you for the comment. We have rewritten the example to make the
problem clearer.

----------------------------------------------------------
Comment 85:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1112)

Home link: why is the technique to add a home link an additional technique?

Proposed Change:

Change the additional technique to a mandatory technique

----------------------------
Response from Working Group:
----------------------------

No techniques are mandatory. Any technique that is sufficient to meet
the success criterion may be used.

The technique to add a home link was made advisory because it is not
considered sufficient by itself to satisfy success criterion 2.4.7.
Just locating the home page, while helpful, is not enough to orient
the user within the set of web units because the user has no
information about the organization of the web units.

----------------------------------------------------------
Comment 86:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1113)

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

Proposed Change:

Clarify SC

----------------------------
Response from Working Group:
----------------------------

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.

----------------------------------------------------------
Comment 87:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1114)

Add a technique (or example) to use the LINK REL attributes of Next, Index etc

----------------------------
Response from Working Group:
----------------------------

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

----------------------------------------------------------
Comment 88:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1115)

Benefits: Add that this benefits people with cognitive disabilities

----------------------------
Response from Working Group:
----------------------------

Thank you for the suggestion, we have added the following to the
benefits section of How to Meet Success Criterion 3.3.1 (formerly
2.5.1):

This success criterion may help people with cognitive, language, and
learning disabilities who have difficulty understanding the meaning
represented by icons and other visual cues.

----------------------------------------------------------
Comment 89:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1116)

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 from Working Group:
----------------------------

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.

Received on Thursday, 17 May 2007 23:48:11 UTC