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

Your comments on WCAG 2.0 Last Call Draft of April 2006 (2 of 3)

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:31:51 -0700
Message-ID: <824e742c0705171631u4c1f71a4h5e7630dd9e785acf@mail.gmail.com>
To: "Chris Ridpath" <chris.ridpath@utoronto.ca>
Cc: public-comments-WCAG20@w3.org

Comment 15:

Source: http://www.w3.org/mid/20060602140636.9B52533205@kearny.w3.org
(Issue ID: LC-670)

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.

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

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.

----------------------------------------------------------
Comment 16:

Source: http://www.w3.org/mid/20060602141352.7FA5033205@kearny.w3.org
(Issue ID: LC-671)

Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):

HTML technqiues H46 and H53 are also referenced from SC 1.1.1. In SC
1.1.1 they are used for
\"Providing long description for non-text content that serves the same
purpose and presents the same information\".
In SC 1.2.7 they are used for \"Providing a full multimedia text
alternative including any interaction\".
Are these the same thing? If different then there should be 2 techniques.

Proposed Change:

Clarify the use of H46 and H53 or create new techniques.

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

These are technology specific techniques for providing any type of
alternate content.  They must be used in conjunction with a General
technique that specifies what needs to be provided by the technique.
The techniques are not sufficient by themselves.   This is clearer in
our new way of listing sufficient techniques.  To see what this looks
like go to the Quick Reference sheet and look up SC 1.2.7
http://www.w3.org/WAI/WCAG20/quickref/

----------------------------------------------------------
Comment 17:

Source: http://www.w3.org/mid/20060602141709.EB37733205@kearny.w3.org
(Issue ID: LC-672)

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.

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

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).


----------------------------------------------------------
Comment 18:

Source: http://www.w3.org/mid/20060602142221.3736133207@kearny.w3.org
(Issue ID: LC-673)

Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):

Contains the text \"Use of layout tables is not recommended...\". The
text \"not recommended\" is unclear. Does this mean \"must not\" or
\"should not\"?

Proposed Change:

Remove text \"not recommended\" or define its meaning.

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

Layout tables may be used but we don't want to encourage their use.
H39 has been modified to clarify the recommendation.

----------------------------------------------------------
Comment 19:

Source: http://www.w3.org/mid/20060602142448.327CE33205@kearny.w3.org
(Issue ID: LC-674)

Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):

There needs to be a technique on the use of layout tables.

Proposed Change:

Add a technique describing the use of layout tables. Layout tables are
OK as long as they are not nested too deep (more than 4 levels). They
should not have too many rows or colums (not more than 4 X 4).

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

The working group has previously considered creating a technique on
using layout tables. We decided not to, however, because we don't want
to encourage their use. Even though layout tables are supported by
assistive technologies and create no accessibility problems on legacy
sites, we do not want to encourage their use on new or modified sites.
One issue with layout tables, however, is the failure to make sense
when linearized which is addressed by technique F49. To clarify this,
we have changed the title of F49 to "Failure of SC 1.3.3 due to using
an HTML layout table that does not make sense when linearized".

----------------------------------------------------------
Comment 20:

Source: http://www.w3.org/mid/20060602143220.B27BB33205@kearny.w3.org
(Issue ID: LC-675)

Part of Item: Tests
Comment Type: TE
Comment (including rationale for proposed change):

The example showing an implicit label association is misleading: \"First name \"
This label is explicitly associated with the form control (the label
contains the form control, it is not implied).
Technique H65 states this is OK \"...by including the form control
within the label element\".
If there was more than one control within the label element then it is
ambiguous and wrong.
If the label does not contain the form control then there is an
implicit relationship.
The \"note 2\" text is incorrect: \"Labels for these elements are
implicitly associated via the value attribute\".
Using an attribute of the element is an explicit association, not implicit.

Proposed Change:

Do not use the word \"implicit\" to describe relationship of label
containing control or label using attribute.

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

Our use of the term "implicit" to describe the relationship of a label
element that contains a form control is correct per the HTML 4.01
specification. See
http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 which contains
the following sentence "To associate a label with another control
implicitly, the control element must be within the contents of the
LABEL element."

However, we see how the current wording creates a problem and have
included the following revisions to address this issue:

We have removed "either explicitly via the for attribute or by
including the form control within the label element" from step one of
the procedure for H65.

In Technique H44, we have merged notes 1 and 2 as follows:

Note 1: The label element is not used for the following because labels
for these elements are provided via the value attribute (for Submit
and Reset buttons), the alt attribute (for image buttons), or element
content itself (button).
* Submit and Reset buttons (input type="submit" or input type="reset")
* Image buttons (input type="image")
* Hidden input fields (input type="hidden")
* Script buttons (button elements or )

We have also repeated the user agents notes from H65 in H44.

----------------------------------------------------------
Comment 21:

Source: http://www.w3.org/mid/20060602143356.46E9A33205@kearny.w3.org
(Issue ID: LC-676)

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.

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

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.

----------------------------------------------------------
Comment 22:

Source: http://www.w3.org/mid/20060602144924.A4300DAF01@w3c4-bis.w3.org
(Issue ID: LC-677)

Part of Item: Description
Comment Type: ED
Comment (including rationale for proposed change):

The use of the word \"label\" can be confusing. Its use here does not
refer to the label element.

Proposed Change:

Use the word \"name\", \"identifier\" or something similar so readers
do not think this is a technique about using the label element.

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

Thank you for pointing out this potential source of confusion.

The title for H71 has been changed to "Providing a description for
groups of form controls using fieldset and legend elements"

The description for H71 has been changed to "The objective of this
technique is to associate a description (such as a prompt or question)
with a related group of radio buttons or checkboxes using the fieldset
and legend elements. Generally, a set of radio buttons or checkboxes
is related when they share the same value for the name attribute.
Using fieldset and legend to associate a description with a group of
form controls creates a programmatic association between the
description and the group of form controls. This makes it possible for
people using screen readers to hear the description as well as the
available responses."

----------------------------------------------------------
Comment 23:

Source: http://www.w3.org/mid/20060602145548.E2641DAF01@w3c4-bis.w3.org
(Issue ID: LC-678)

Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Technique is poorly defined. There are several ways to group related
sentences other than using a P element (i.e. lists, tables).
Technique may not apply to other languages.
Technique deals with writing style which is difficult to describe and test for.

Proposed Change:

Clarify the use of P element in relation to other text structuring elements.

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

The working group agrees that this technique is poorly defined and
should be removed. Upon examination based on your comment, we have
determined that, even though

elements are useful for accessibility, determining when they should be
required is highly subjective.

----------------------------------------------------------
Comment 24:

Source: http://www.w3.org/mid/20060602150228.D3276DAF01@w3c4-bis.w3.org
(Issue ID: LC-679)

Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Does not mention other semantic markup used improperly in layout
tables (see H43).

Proposed Change:

Include other semantic markup SCOPE, ID, HEADERS in list of elements to avoid.

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

The working group does not see scope and headers as "common failures"
while the abuse of th, caption, and summary in layout tables is rather
common. Therefore, we want to keep focus on the failures most commonly
occurring by naming them in the title of the technique.

And the working group does not feel that id attributes should be
prohibited in layout tables as there are valid uses for them in layout
tables (scripts, CSS, etc.).

We do agree, however, that if scope and headers are used in layout
tables, it would be a failure. Therefore, we have added the following
to the end of the first paragraph in F46:

Although not commonly used in a layout table, the following structural
markup would also be failures of SC 1.3.1 if used in a layout table:
- headers attributes
- scope attributes

----------------------------------------------------------
Comment 25:

Source: http://www.w3.org/mid/20060602150453.DCEA247BA5@mojo.w3.org
(Issue ID: LC-680)

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.

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

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.

----------------------------------------------------------
Comment 26:

Source: http://www.w3.org/mid/20060602150742.37C3F47BA5@mojo.w3.org
(Issue ID: LC-682)

Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Should also include Applet, Object and Embed.

Proposed Change:

Include other examples of applet, object and embed that make use of
pattern and color.

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

Since this is a general technique the working group does not want to
refer to the HTML specific applet and embed elements.   However, we
have modified the description to refer to non-text content rather than
specifically to images.  We have also added an additional example.


----------------------------------------------------------
Comment 27:

Source: http://www.w3.org/mid/20060602151623.A117347BA5@mojo.w3.org
(Issue ID: LC-688)

Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Very vague and difficult to test for. The words \"meaningful
sequence\" are not defined. As this is a level 1 it should be clearly
defined.

Proposed Change:

Provide clear examples of when this problem occurs and how to test for it.
Define \"meaningful sequence\".

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

We have modified the test procedure in G57 to describe how to test
that content is meaningful. This removes the need to define
"meaningful sequence". We believe the description of the technique
provides an example.

----------------------------------------------------------
Comment 28:

Source: http://www.w3.org/mid/20060602151938.9B90B47BA5@mojo.w3.org
(Issue ID: LC-690)

Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Seems similar to H1. What is the difference between using DIR
attribute on inline and block elements?

Proposed Change:

Roll H1 and H56 into one technique or describe differences between use
of DIR attribute on inline vs. block elements.

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

Based on comments from the internationalization working group, we have
determined that text direction is only an accessibility issue when
mixing text directions is done in a way that affects the sequencing of
the text. So we have removed technique H1.

----------------------------------------------------------
Comment 29:

Source: http://www.w3.org/mid/20060602152633.9E1F933205@kearny.w3.org
(Issue ID: LC-695)

Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):

Very difficult to test for this.
Says to use Q element which fails under IE.
WCAG doc itself does not use Q element.
Should be techniques about misuse of semantic markup for presentation.

Proposed Change:

Describe clearly when this applies.
Do not recommend use of Q element.
Add techniques that discourage use of semantic markup for presentation
(i.e. misuse of Hx, BLOCKQUOTE etc.)

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

We have provided additional information about the issues surrounding
use of the Q element, and suggested approaches for minimizing these
issues. The Working Group continues to see the Q element as valuable
in spite of inconsistent user agent support at this time, and
therefore decided to retain the technique with its caveats.
Received on Thursday, 17 May 2007 23:32:15 UTC

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