W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007

Your comments on WCAG 2.0 Public Working Draft of May, 2007 (2 of 3)

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:27:09 -0700
Message-ID: <824e742c0711032127i2f5cc260sce6523e57e7f2846@mail.gmail.com>
To: "Gian Sampson-Wild" <gian@tkh.com.au>
Cc: public-comments-WCAG20@w3.org

Comment 10: LC-1112:Why isn't this technique sufficient
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0071.html
(Issue ID: 2323)
----------------------------
Original Comment:
----------------------------

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.
----------------------------
Response from GSW:
----------------------------
I am still unclear as to why this is not under the "Sufficient techniques"
section

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

The working group does not understand what is unclear about the
explanation in our response about why we did not consider this a
sufficient technique.

Only techniques (or combinations of techniques) that are sufficient in
themselves to meet the success criteria are listed as sufficient.
This technique by itself is not sufficient as described above (in
original response from the Working Group).



----------------------------------------------------------
Comment 11: LC-1110: Understanding SC 2.4.4 should be rewritten
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0073.html
(Issue ID: 2324)
----------------------------
Original Comment:
----------------------------

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.
----------------------------
Response from GSW:
----------------------------
If this is the case then the intents and benefits section needs to be
rewritten as it is peppered with benefits that are reliant on the pure link
text being comprehensible (eg. tabbing from link to link) not the link text
and its surrounding content.
In addition to this I still believe that WCAG2 should outlaw "click here"
and "more" links.

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

The Intent and Benefit section encourages the use of link text that is
sufficient without additional context. So this means of satisfying the
success criterion is described first, and the benefits are described
to make it clear why this is the preferred option.

We have updated the Intent section to try to make this as clear as possible.

----------------------------------------------------------
Comment 12: LC-1109: contextual information not available to low vision users
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0074.html
(Issue ID: 2325)
----------------------------
Original Comment:
----------------------------

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.
----------------------------
Response from GSW:
----------------------------
Yes but that assumes that people who cannot access the context of the link
can access the hidden information, which is not the case for magnifier
users.

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

@@ add to response that there is a new sufficient technique to hide
for everybody (see Cynthia's suggestion in response)

The working group agrees that screen magnifiers do not provide low
vision users with the hidden context, and we have added language to
the technique to discourage its use for satisfying SC 2.4.4, where
there are better techniques available.

However, this is one of the few techniques available for satisfying SC
2.4.8 in situations where link text would become highly repetitive in
order to describe the purpose of the link out of context. We feel it
should remain available for use in this situation.

----------------------------------------------------------
Comment 13: LC 1103: deprecate use of frames
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0078.html
(Issue ID: 2326)
----------------------------
Original Comment:
----------------------------

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.
----------------------------
Response from GSW:
----------------------------
I do not agree with the use of frames in this SC. If it is to remain in this
SC I would like it indicated in the "Understanding WCAG2" document that
frames are not preferred.

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

We have clarified the description for H70 to say: "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, because many people using assistive
technology have trouble with frames."

----------------------------------------------------------
Comment 14: LC 1100: Clarify relation between 2.3.1 and 2.3.2
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0081.html
(Issue ID: 2327)
----------------------------
Original Comment:
----------------------------

Comment 73:

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

Seizures: This is a Level 3 SC yet the Intent specifies that it is intended
not to cause seizures.

Proposed Change:

Clarify the SC. If it is intended not to cause seizures it should be at
Level 1.

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

The primary seizure provision is already at Level A.  This provision is an
extra measure that can be taken for those who want to go above and beyond.
It covers all flashing including very small areas of the screen that would
not be sufficient to cause problems.  The purpose is to allow users to use
extreme magnification and still not have a problem.  This goes beyond all
current standards.
----------------------------
Response from GSW:
----------------------------
I am happy for this to remain at Level 3 - I trust that the WG has
sufficient research to back this up - however my comment actually pertains
to the use of "preventing seizures" as an intent. If WCAG2 has a SC in Level
3 that is intended not to prevent seizures then I am sure there will be
questions in the larger web community as to why it is at such a high level.
I understand why it is there and accept that it is the proper position for
it (assuming there is research behind this) however just saying "to prevent
seizures" doesn't explain why this is at Level 3 and not at Level 1 - like
Checkpoint 7.1 was in WCAG1. I would recommend removing this intent or
clarifying that it builds on previous SC and that those previous SC are - in
most cases - sufficient enough to prevent seizures.

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

Thank you.  We agree that was not very clear.  We have revised the
intent to read:

The purpose of this success criterion is to further reduce the chance
of seizures.   Seizures cannot be completely eliminated since some
people are so sensitive.  However, by eliminating all 3-per-second
flashing over any area of the screen, the chances of a person having a
seizure are further reduced than when just meeting the measures
ordinarily used today in standards internationally, as we do at Level
A.

----------------------------------------------------------
Comment 15: LC-1096: Move SC 2.2.6 to Level A
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0088.html
(Issue ID: 2328)
----------------------------
Original Comment:
----------------------------

Comment 69:

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

2.2.6: This should be at Level 2. If someone is using an authenticated
session and cannot complete the information before automatic logoff, then
being able to continue after re-login is imperative in order to use the
system. Otherwise the system is inaccessible

Proposed Change:

Move 2.2.6 to Level 1

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

The working group has discussed this issue. The criteria for having
something at Level AA is that it must be something that can reasonably be
applied to all Web content. But there are valid reasons, such as financial
security or personal information where this cannot be done because it is
against regulations to preserve any of this information once a session
expires or is terminated. The working group therefore decided to put this
requirement at Level AAA.
----------------------------
Response from GSW:
----------------------------
I disagree with this decision. One solution would be to put this at Level 1
or Level 2 and temper the SC by saying "except where the form has legal or
financial purposes" as has been done in other SC

Received on

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

This success criterion requires control of the server that may not be
possible for some authors and technologies. It's not appropriate for
all sites because on some sites it could place a very heavy load on
servers, and not all servers will have the capacity to handle that
load. It is also a new success criterion in WCAG 2.0 and there is
little if any experience with the requirement and the solutions. For
these reasons the Working Group feels it is best positioned at level
AAA.


----------------------------------------------------------
Comment 16: LC-1071: Properly positioned labels
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0100.html
(Issue ID: 2329)
----------------------------
Original Comment:
----------------------------

Comment 48:

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

Properly positioned labels: 10.2 no longer maps to any particular SC.
Although this checkpoint was included in WCAG1 to assist people who use
screen readers, prior to the uptake of explicit labelling, this is still a
very important SC for people who use magnifiers and people with cognitive
disabilities.

Proposed Change:

Create a new SC the equivalent of 10.2 (I am happy to write this)

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

Assistive technology has advanced since the WCAG 1.0 guidelines were
released. As long as the label is explicitly associated with a field,
assistive technologies can present the information to the user in an
understandable manner. However, since visual positioning can be important,
especially for pages translated into other languages, we have added an
advisory technique to Success Criterion 1.3.1 and Guideline 3.2 titled
"Positioning labels to maximize predictability of relationships."

Note: The mapping has been removed from the WCAG document itself. The
working group will work in coordination with the EOWG WCAG 2.0 Materials
Support Task Force in the creation of transition materials and will consider
these comments when the mapping is updated.
----------------------------
Response from GSW:
----------------------------
I believe this needs to be a mandatory technique - not advisory. It is
imperative for people with cognitive disabilities and those using magnifiers

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

We have reviewed this and feel that it can not be required for the
reasons stated previously.

----------------------------------------------------------
Comment 17: LC-1077: SC 1.2.7 should be Level A
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0101.html
(Issue ID: 2330)
----------------------------
Original Comment:
----------------------------

Comment 53:

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

Transcripts: Why isn't this at Level 1?  Shouldn't the equivalent
information be provided at Level 1?

Proposed Change:

Move to Level 1

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

Success criteria 1.2.2, 1.2.3 and 1.2.7 build upon one another. At Level A,
SC 1.2.2 can be satisfied either by providing a full text alternative for
multimedia or by providing audio description of the video. At level A,
multimedia will either have a full text alternative or an audio description.

At Level AA, SC 1.2.3 requires an audio description. So multimedia that
satisfies level AA either has only an audio description, or both an audio
description and a full text alternative.

At Level AAA, SC 1.2.7 requires a full text alternative, so at level AAA
content will have both  an audio description and a full text alternative.

Success criterion 1.2.7 is not required at Level A because audio
descriptions are usually more effective than transcripts. This is due to the
fact that they contain much additional rich audio information from the
sounds track and because they allow individuals who are blind the option of
viewing the material with other people. Full text descriptions, however, are
an option for meeting this guideline at Level A.
----------------------------
Response from GSW:
----------------------------
Audio descriptions may be more effective than transcripts for people with
audio impairments but what about people who are blind? Are captions required
at Level A? What about people who can't operate the multimedia file? Or
whose assistive technology does not interact with the multimedia file?

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

> Audio descriptions may be more effective than transcripts for people with
audio impairments but what about people who are blind? At Level A,
audio descriptions or  multimedia alternatives to text satisfy SC
1.2.2.

Audio descriptions are not an accommodation for people with audio
impairments; they are an accommodation for people who are blind.

> Are captions required at Level A?

Yes, SC 1.2.1 (Captions) is at Level A.

> What about people who can't operate the multimedia file?

Operating the multimedia file would be covered under Principle 2. If
the concern is keyboard access for operating the multimedia file, this
would be covered under GL 2.1.

> Or whose assistive technology does not interact with the multimedia file?

We assume this concern refers to assistive technology that cannot
interact with the controller for playing the multimedia. We are not
aware of assistive technology that interacts directly with multimedia
files.

Assistive technology support for interacting with the multimedia file
is a question of whether the technology is accessibility supported. If
it is not, then use of the multimedia would not comform.



----------------------------------------------------------
Comment 18: LC-1075: testability of text alternatives
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0103.html
(Issue ID: 2331)
----------------------------
Original Comment:
----------------------------

Comment 52:

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

Example 6: Add another alt text example "Shaking a world leader's hand can
subtly affect the distribution of power in the relationship" and "Shaking
hands is a purely Western artifice"

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

The Working Group feels that your first proposed example reveals an opinion
and is thus not appropriate alternative text for the situation described in
the photograph.  While the second alternative may be true, it does not
sufficiently describe the image.  We have not updated the example with these
additional alternatives. Instead, we are including the following example:

On one page a checkmark is used to indicate that an item should be ordered
and and on another page it is used to indicate that a step has been
completed.  The same alt text "checked" could be used but since they serve
different purposes, different text alternative may make it easier to
understand.
----------------------------
Response from GSW:
----------------------------
How does this fit with testability? Surely if the same alternative text
could be used, or different alternative text could be used then it doesn't
conform with testability.
Any my comment was about what images are intended to convey - sometimes they
are specific to the site. Another (perhaps clearer) example would be an
image of the world. On a travel site the alternative text might be
"International travel" (especially if it is used to link to the
international travel section). On an environmental site the alternative text
might be "Our earth is precious", or "We've only got one earth so we must
treasure it". On a university web site it might be "international campuses".

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

We agree that different alternative text can be appropriate for the
same image in different contexts, and that your example of images of
the world is a good one. We have added it to the examples for
Understanding SC 1.1.1.

----------------------------------------------------------
Comment 19: LC-1072: advisory techniques should have conformance levels
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0105.html
(Issue ID: 2332)
----------------------------
Original Comment:
----------------------------

Comment 49:

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

Advisory techniques: There should not be any advisory techniques unless they
are linked to a particular SC. Having advisory techniques linked to a GL
only, means that the level (A, AA or AAA) is not specified.

Proposed Change:

Move all GL advisory techniques to specific SC

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

Because WCAG 2.0 success criteria are written as testable statements, it  is
not always possible to associate techniques that are difficult to test or
subjective in nature with success criterion. However, the working group
feels that it is important to make these technqiues available for authors
who are interested in improving the accessibility of their content beyond
the minimum conformance requirements. Note that regardless of association
with a success criterion or guideline, whether an author chooses to
implement advisory technqiues does not impact the level of conformance
claimed.
----------------------------
Response from GSW:
----------------------------
Advisory techniques are not testable - that's why they are advisory.
Therefore there should be no problem in associated advisory techniques with
a particular SC and therefore a particular level.

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

Advisory techniques cannot be associated with a success criterion that
they do not address.   However, we have added new SC that relate to
some of the advisory techniques that were previously under guidelines
and have been able to move those techniques down to the SC .

Move from GL 1.2 to SC 1.2.4:
 Providing audio description for live multimedia (future link) [LC-487]

Remove from GL 1.3 (superceded by SC 1.4.4):
  Providing resizable text (future link)

Move from GL 1.3 to SC 1.3.1:
  G140: Separating information and structure from presentation so that
Web pages can be presented different ways without losing information
[LC-1201]

Add to SC 2.4.9, but do not remove from GL 2.4:
  Providing mechanisms to navigate to different sections of the
content of a Web page (future link) [LC-928]

In GL 3.1, change "Setting expectations about auto-generated or
user-contributed content (future link)" to "Setting expectations about
content in the page from uncontrolled sources (future link)"

Add to SC 1.4.3, 1.4.5, but do not remove from GL 3.1:
  Using a light pastel background rather than a white background
behind black text (future link)

Move from GL 3.1 to new SC 2.4.X (Focus Visible):
  Highlighting a link or control when the mouse hovers over it (future link)

Added new SC 1.4.8 : For the visual presentation of blocks of text, a
mechanism is available to achieve the following: (Level AAA)

-foreground and background colors can be selected by the user
-width is no more than 80 characters:
-text is not aligned on both the left and the right
-line spacing is at least space-and-a-half within paragraphs, and paragraph
spacing is larger than line spacing
-text is resized without assistive technology up to 200 percent in a
way that does not require the user to scroll horizontally to read a
line of text

+ advisories
Additional Techniques (Advisory) for 1.4.8
Using a hover effect to highlight a paragraph, list items, or table
cells(HTML, CSS)
Presenting text in sans serif font or providing a mechanism to achieve
this (CSS)
Using bulleted/numbered/vertical lists rather than inline lists
Using upper and lower case according to the spelling conventions of
the text language
Providing large fonts by default
Avoiding the use of text in raster images
Avoiding scaling font sizes smaller than the user-agent default
Providing sufficient inter-column spacing [LC-569 (add)]
Avoiding centrally aligned text [LC-1253]
Avoiding chunks of italic text [LC-1253]
Avoiding overuse of different styles on individual pages and in sites [LC-1253]
Making links visually distinct [LC-1300]
Providing expandable bullets
Show/hide bullet points]
Putting an em-space or two spaces after sentences




----------------------------------------------------------
Comment 20: LC-1070: Clarify relying on CSS to convey information
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0106.html
(Issue ID: 2333)
----------------------------
Original Comment:
----------------------------

Comment 47:

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

Baseline CSS: This mapping essentially says that if CSS is in the baseline
then information can be put into the style sheet and not in the HTML. This
appears to allow formatting (ie headings) via CSS and not HTML, important
images included in CSS and not HTML, etc. How is someone who uses a screen
reader going to interpret this? How are they going to be able to access the
information they require?

Proposed Change:

Clarify baseline requirements

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

If CSS is an accessibility-supported Web technology, then the author can
rely on it to satisfy success criterion. However, the success criterion must
still be satisfied. So, for instance, if non-text content that conveys
information is included via CSS, SC 1.1.1 requires that a text alternative
also present equivalent information. This information must be
programmatically determined, that is, exposed to assistive technologies.

So even if most of the features or functionality of a Web technology are
accessibility supported, it may not be possible to use certain functionality
in the technology and still conform to WCAG.

We have completely rewritten the Conformance section, and this should now be
clearer.
----------------------------
Response from GSW:
----------------------------
I don't believe this is clear from reading the conformance section. Perhaps
some examples would assist? For example an image that is integral to the
user shouldn't sit within CSS because it cannot be accessed by AT -
therefore it should sit within the HTML so that AT can access it and it's
alternative text. Another example should be that developers use <h1> etc
instead of <class="heading1"> as the former is a recognized element by AT.

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

Since the May 2007 draft, we have revised the conformance section
significantly and have provided additional details in the
Understanding document related to conformance. Your example of
including important information within images is covered by failure
F3: Failure of SC 1.1.1 due to using CSS to include images that convey
important information. The use of CSS to indicate headings would be a
failure of 1.3.1 and is addressed through failure F2: Failure of 1.3.1
due to using changes in text presentation to convey information
without using the appropriate markup or text.
Received on Sunday, 4 November 2007 04:27:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:09 UTC