Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear David MacDonald ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.

We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.

This message contains the comments you submitted and the resolutions
to your comments. Each comment includes a link to the archived copy of
your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly
archived.

We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.

Thank you,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1:

Source: http://www.w3.org/mid/20060525174454.1E37147B9F@mojo.w3.org
(Issue ID: LC-605)

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

I think there are problems with the idea that someone can claim level
3 conformance if they do only 50% of the techniques that apply to
their content. That means someone could claim Level 3 conformance and
have an audio track that has a loud background when there is a Level 3
SC that specifically says don't do this.  I realize that some Level
three items are very difficult. But that is what level 3 is all about
- going above and beyond. (If some of our Level 3 SC are
unrealistically difficult then let's remove those ones) On the other
hand, if we are just providing level 3 as a way to encourage people to
provide extra accessibility then it should not be a Level but rather a
separate advisory section of our guidelines. I don't think we can
allow people to say they have reached a level of conformance while
blatantly while breaking the GL or SC in that level. I think it
undermines the integrity of our Guidelines. I think it will be a
source of much confusion and conflict in the public and among
disability groups.

Proposed Change:

Require 100% of Level 3 SC that apply to the content to be met in
order to meet Level 3. If there are some SC that the group identifies
as unrealistically difficult then remove them to a separate document
called something like "going the extra mile."

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

We have changed the definition of Level AAA conformance so that all
Level AAA Success Criteria that apply to the content types used must
be satisfied.

----------------------------------------------------------
Comment 2:

Source: http://www.w3.org/mid/20061025212659.E180BBDA8@w3c4.w3.org
(Issue ID: LC-1525)

Part of Item: Techniques
Comment Type: general comment
Comment (including rationale for proposed change):

Web safe colors, web friendly colours
The access Working group GOC has recently made a requirement for web
friendly colours.
They believe that some versions of magnifiers (older) only handle web
safe or web friendly colours and then they dither non friendly
colours. They believe that the dithering process will affect contrast.
For instance, a light background that is not safe might get dithered
darker, and a dark foreground might be dithered lighter. And the
combination could cause lower overall contrast in older user agents.


Proposed Change:

Discuss why or why not web safe/friendly is an issue.

Add something like:

Note: some older user agents are limited to web friendly, web safe
colours. If older user agents in your baseline, use web friendly/safe
colours.

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

The group does not have any evidence of significant accessibility
issues arising from the use of non-safe web colours. The Web-safe
colour palette is the 216-colour intersection of the 256-colour
palettes of the Windows and Mac OS of the 1990's. Neither Windows nor
Mac uses those palettes by default, nor do Unix variants, so this
concern appears to have been overcome by technology advances.

----------------------------------------------------------
Comment 3:

Source: http://www.w3.org/mid/20060624142801.C3C7D66364@dolph.w3.org
(Issue ID: LC-1305)

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

Loretta, Michael , Cynthia and myself have been looking at the Level 3
compliance issue. And one of the things we felf we needed to determine
is if it is actually possible to do Level 3, without there being some
conflict between the guidelines that would make it impossible.

It appears there is a conflict.

2.2.4 Except for real-time events, timing is not an essential part of
the event or activity presented by the content.

The problem arises when we consider that captioning, sign language,
and most multi-media  require a capacity to react or understand within
a certain time frame, and therefore they are content where timing is
an essential part of the event.

Multi media is amajor helper to people so we don\'t want to forbid it.
We don\'t want Level 3 to omit content that can address cognitive
issues such as 2.2.4.

Proposed Change:

Propose to make other exceptions besides \"real-time events\" in 2.2.4.

2.2.4 \"Except for captions, sign language, and non-interactive
multimedia (i.e., movies), timing is not an essential part of the
event provided by the content...\"

Then we would could define \"non-interactive\" as something that
requires does not require an action from the user.

The multimedia would have to have a pause and play button but perhaps
that is a user agent issue.

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

Thank you, this clarification has been accepted. SC 2.2.4 has been
modified to read, "Timing: Timing is not an essential part of the
event or activity presented by the content, except for non-interactive
multimedia and  real-time events." and a note added to the Intent
section of How to Meet 2.2.4 to read, "Note: Video only, such as sign
language, is covered in Guideline 1.1".

----------------------------------------------------------
Comment 4:

Source: http://www.w3.org/mid/20060630042240.7EC3EBDA8@w3c4.w3.org
(Issue ID: LC-1407)

Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):

I\'ve been up to to my eyeballs in the documents lately for a
multination client who is developing a policy. And have noticed a few
things I hadn\'t noticed before.

Although GL 1.3 says \"Ensure that information and structure can be
separated from presentation\" we have not said *anywhere* in the
document that we discourage table layout. If we discuss layout tables
(ie. table summary element) and do not mention our prefference to CSS
layout then we are tacidly endorsing layout tables I would say.



Proposed Change:

Propose that we add a note to all the techniques that address table
layout (F46,F49,G57 etc.) which would say something like:

\"Note: Although Layout tables are allowable under the GUidelines, the
working group recommends the use of CSS layout rather than HTML layout
tables because CSS layout is more in line with the principle of
separation of presentation and content.\"

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

Techniques H2, H39, H73, F46, and F49 have been modified to clarify
the recommendation that layout tables not be used.

----------------------------------------------------------
Comment 5:

Source: (Original comment not archived)

We need a definition of "relationship" for the glossary as it pertains
to SC 1.3.1


1.3.1 Information and relationships conveyed through presentation can
be programmatically determined, and notification of changes to these
is available to user agents, including assistive technologies. [How to
meet 1.3.1]


Here is my recommendation:

Definition of *Relationships*:

"Meaningful associations between distinct chunks of content"

Examples of chunks that have relationships include:
-a heading and the paragraph which follows it;
-a section title and the subsections that are within it;
-a control and its label;
-the boxes in an organization or flow chart;
-and table cells and their headers

Note: "Chunks" could also be "Blocks" or "Pieces"

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

We have added a definition of "relationships" that reads, "meaningful
associations between distinct pieces of content."


----------------------------------------------------------
Comment 6:

Source: (Original comment not archived)

Currently, 2.1.1 is not clear that HTML fallback techniques for
Javascript dropdown menus are sufficient. Nor is our conformance
section clear that deficiences on one web unit can be made up on
another web unit. For example the LongDesc (1.1) provides an
alternative on a separate web unit. But our conformance is "web unit"
based. We need to allow for this.

This came up because many corporate web sites are meeting 508
compliance by having a JavaScript dropdown menu where the top item is
a keyboard accessible link that goes to a separate page that has all
of the links that were in the dropdown menu.

WebAim recommends this technique here.

http://www.webaim.org/techniques/javascript/eventhandlers.php  (see example 2)

Real examples are here:
http://www.cab-acr.ca/english/default.shtm
http://www.futurescholar.com/Home.htm

When I read 2.1.1 and I thought about the (per Web Unit) conformance
it seemed to me that our current wording didn't allow it. Ben thought
it might be able to go in Guideline 4 but if someone had JavaScript in
their Baseline then I think 2.1.1 would apply… I talked with Michael
and Bruce and they both thought we should clarify that this is a
viable navigation strategy.

Gregg responded:
>>>One has to be completely accessible except that there can be a link
from an inaccessible part to an accessible version of that part if it
can be viewed independently – and then you return.  (this is in fact
what we do with Longdesc).  I would run this answer past group A
though just to be sure before I used it  (unless you are just using it
in an issue summary going to a team anyway.

Recommend:

 How about something like in 2.1.1

Situation:  For pages that have script or programmatic pop down
navigation menus when that technology is not in the baseline

1. Providing an HTML link to a place (on the same page or a separate
page) with the navigation menu in HTML

If script in baseline  - then you CAN use "Create HTML fallbacks for
Javascript menus"  OR  you can just have  js script menu with full
keyboard access

If script not in baseline – you CAN "Create HTML fallbacks for
Javascript menus".     Full keyboard access to menu does NOT satisfy
SC.

Also: Add phrase to the conformance section that allows for make up
alternatives on a separate Web Unit directly accessed from a web unit.

(longdesc and HTML fallbacks for JavaScript menus).

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

We have moved discussion of alternate versions of content to the
Conformance section of the Guidelines, and we have clarified by adding
the following conformance criterion:

4.) Alternate Versions: If the Web page does not meet all of the
success criteria for a specified level, then a mechanism to obtain an
alternate version that meets all of the success criteria can be
derived from the nonconforming content or its URI, and that mechanism
meets all success criteria for the specified level of conformance. The
alternate version does not need to be matched page for page with the
original (e.g. the alternative to a page may consist of multiple
pages). If multiple language versions are available, then conforming
versions are required for each language offered..

Note: If multiple language versions are available, then conformant
versions are required for each language offered.

----------------------------------------------------------
Comment 7:

Source: (Original comment not archived)

How to Meet Success Criterion 2.5.1
2.5.1 If an input error is detected, the error is identified and
described to the user in text. (Level 1)

There is no sufficient server side technique. Such as ASP, PHP etc...
I'm guess this is because we don't offer server side techniques on our
site. But it brings up an issue that some people may think server side
techniques are not sufficient because they are not listed. If we don't
add anything to the "How To" document I think we need to make it clear
that there are ways to meet the SC with server side programming and
they are omitted from our Sufficient techniques because we do not do
Server side exampes and not because they are not sufficient.

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

One of the original paridigms of the Web is to submit data to the
server where a response is created and returned. Thus, there really
isn't a need to identify server side techniques since this is the
standard behavior. All of the techniques except those specifically
identified as client side are implemented to some extent on the
server. The Working group feels that no additional clarification is
necessary.

----------------------------------------------------------
Comment 8:

Source: (Original comment not archived)

Why is F36 Example 2 a deprecated example.

"Failure Example 2:
This is a deprecated example that submits a form when the user selects
an option from the menu."

I think it is still an issue and it us used all the time.

We could also add to it that Blind users and users with hand tremors
can easily make a mistake on which item on the dropdown menu to choose
and they are taken to the wrong destination before they can correct
it.

Therefore the technique can also be linked from 2.5.1. I think.
Because it would also be a failure to that technique.

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

The term "deprecated" has been removed, as it is indeed a practice
never endorsed by the WCAG WG and is not actually deprecated. We did
not add the technique F36 to SC 2.5.1 because the issue is orthogonal,
but we did add introductory text to the example to indicate that
navigation to the wrong location is a frequent effect of this
practice.

----------------------------------------------------------
Comment 9:

Source: (Original comment not archived)

I recently was evaluating a corporate web site that had image text as
a title for a list of links. They had the image in the

element so Jaws would not identify it as a heading. I think we need a
sufficient technique in 1.3.1 or an example added to H42 that says
something like: "Using heading markup to identify image text that is
acting as a heading." An example would look something like this.
cities of interest

    * Barcelona
    * New York
    * Paris

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

We have included your example and have created the new failure titled,
"F64: Failure of SC 1.3.1 due to using changes in text presentation to
convey information without using the appropriate markup or text."

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