Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

Dear Michael Stenitzer,

Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
has reviewed all comments received on the December draft. Before we
proceed to implementation, we would like to know whether we have
understood your comments correctly and whether you are satisfied with
our resolutions.

Please review our resolutions for the following comments, and reply to
us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
you accept them or to discuss additional concerns you have with our
response. Note that this list is publicly archived.

Please see below for the text of comments that you submitted and our
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 WCAG 2.0 Editor's
Draft of 10 March 2008 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to
3.3.2 of the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-comments-wcag20@w3.org. Formal objections will be reviewed
during the candidate recommendation transition meeting with the W3C
Director, unless we can come to agreement with you on a resolution in
advance of the meeting.

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.


Regards,

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: GL 2.2: Refering to "users" vs. "users with disabilities"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0062.html
(Issue ID: 2440)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

It seems to me, that the guidelines are generally referring to "users"
and in a few other cases to "users with disabilities".

Proposed Change:
I would propose to change this to "users".

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

We have have changed "users with disabilities" to "users" in 2.2 and 2.4.

----------------------------------------------------------
Comment 2: GL 2.4: Refering to "users" vs. "users with disabilities"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0063.html
(Issue ID: 2441)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

It seems to me, that the guidelines are generally referring to "users"
and in a few other cases to "users with disabilities".

Proposed Change:
I would propose to change this to "users".

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

We have have changed "users with disabilities" to "users" in 2.2 and 2.4.



----------------------------------------------------------
Comment 3: Cross reference for SC of different conformance level
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0064.html
(Issue ID: 2442)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Please provide referrers (eg. in the form of cross references) for
different conformance levels of the same topic.

eg: Audio Description in SC 1.2.2. (Level A), SC 1.2.4 (Level AA) and
SC 1.2.6 (Level AAA).

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

We are adding cross references between related success criteria in the
Understanding WCAG 2.0 Document.

In the guidelines themselves they are only a short distance apart and
have the very similar or the same short name (differing only by the
parenthetical in most cases).  We decided to not add "see xxx" notes
to requirements that are close to each other in the guidelines because
it adds to the complexity of the document, and seemed less important
when things are right next to each other.

----------------------------------------------------------
Comment 4: 200% seems too ambitious
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0065.html
(Issue ID: 2443)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

200% seems too ambitious for Level AA.

Note: a quick check of accessible Austrian and German websites showed
that only a small share would pass this SC.

It also seems inconsistent to require text to be scalable to a certain
extent without taking into account the base level (original size of
text). Otherwise it would be of advantage for websites with very small
text-sizes.

This note also applies to SC 1.4.8. (last bullet)

Proposed Change:
We would propose to differentiate between Level AA (150%) and Level AAA (200%).

It could be possible to refer to the standard text size of the user
agent (reference level: 100% of the default text size of the user
agent). (This has to be discussed further).

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

Success Criterion 1.4.4 requires that the web technology is being used
in a way that permits some text resizing without the use of assistive
technology. 200% was chosen as the lowest magnification provided by
older screen magnifiers; hence users who need magnification up to that
point would need to rely on the user agent.

SC 1.4.4. can be satisfied by zoom functionality, which magnifies
everything on that page, or by text resize functionality, which
increases the size of the text and may cause the page to be laid out
differently. Using a small or large default font size should not make
this success criterion any more or less difficult to satisfy.

We are surprised by your statement that only a small share of Austrian
and German websites would pass this SC, since any HTML website that
uses relative measures should pass.

SC 1.4.8 can be more difficult to meet, since it requires that the
resizing be supported without requiring horizontal scrolling. In this
case, the default text size may affect how difficult it is to meet
this success criterion. There are some types of content for which it
may not be possible to meet this SC. This is the reason it is included
at level AAA.

----------------------------------------------------------
Comment 5: paragraph spacing is larger than line spacing
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0066.html
(Issue ID: 2444)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

If line spacing is 1.5 and paragraph spacing is 1.51 this SC is met,
but this setting certainly does not improve the readability or visual
presentation.

Proposed Change:
So either you require a considerable larger paragraph spacing (eg.
half the text size larger than the line spacing, ie. 2.0 times the
text size) or you write "at least the line spacing" to be clear.

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

The Success Criterion already requires that the paragraph spacing be
more than the line spacing. So, we changed it slightly to say:

"line spacing (leading) is at least space-and-a-half within
paragraphs, and paragraph spacing is at least 1.5 times larger than
the line spacing."

----------------------------------------------------------
Comment 6: When is a change of content a change of context
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0067.html
(Issue ID: 2445)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Provide additional examples for a "change of context". This is a very
abstract concept and it might not be clear when a change of content
within a web page is a change of context.

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

We have updated the list to the following:

Example: Opening a new window, moving focus to a different component,
going to a new page (including anything that would look to a user as
if they had moved to a new page) or significantly re-arranging the
content of a page are examples of changes of context.

----------------------------------------------------------
Comment 7: scaling of line-height and containers-heights
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0068.html
(Issue ID: 2446)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Additional failures:

If text is resized and line-height or container-heights do not scale
in the same way, text may be covered or truncated.

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

That situation is covered by the phrase "without loss of content or
functionality."

We also have a failure of 1.4.4 that specifically covers this:

F69: Failure of Success Criterion 1.4.4 when resizing visually
rendered text up to 200 percent causes the text, image or controls to
be clipped, truncated or obscured

----------------------------------------------------------
Comment 8: Making links visually distinct
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0069.html
(Issue ID: 2447)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

"Making links visually distinct": this does not seem to be required
anywhere else. Making links visually distinct "foremost in blocks of
text" is an important precondition for making hyperlinks usable.

Proposed Change:
Make this a sufficient technique: links visually distinct in blocks of text.

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

That is true.  We have covered most of the key aspects of this
elsewhere but wanted to add this advisory technique to remind people
to do all that they could, even beyond the other guidelines.

Of course, if the links are invisible to everyone for some reason,
then it is not required that they be visible to people with
disabilities.

However if the links ARE visible to others, the color provision
(1.4.1) and the contrast provisions (1.4.3 and 1.4.6) require that
they be visible to those with disabilities.

----------------------------------------------------------
Comment 9: Example "A help dialog ..."
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0070.html
(Issue ID: 2448)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

"A help dialog ...": the description of this example is not clear.

Proposed Change:
Improve the description of the problem.

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

This was meant to say that moving to a control caused a dialog window
to open that grabbed focus away from the window with the control. This
was not clear so we have changed this to read

Example of a Failure: A help dialog

When a field receives focus, a help dialog window describing the field
and providing options opens. As a keyboard user tabs through the Web
page, the dialog opens moving the keyboard focus away from the control
every time the user attempts to tab past the field.

----------------------------------------------------------
Comment 10: lists for accessibility supported technologies
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0071.html
(Issue ID: 2449)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

What will be the expected process after publishing WCAG 2.0 as a
(candidate) recommendation? Do we have to wait for the availability of
lists for accessibility supported technologies? What is the
recommended approach for web developers until there are such lists of
trustworthy and/or official institutions available? Are there any
known organisations that are already preparing such lists?

I see the risk that many institutions will ignore the requirement #5
of a conformance claim, until such lists will be published together
with the guidelines or by a governmental body.

Proposed Change:
Please elaborate the expected process in the WCAG 2.0 FAQs (or somewhere else).

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

The working group recognizes that the need for information on which
technologies are 'accessibility-supported' is important to use of the
guidelines.

Such data can only come from testing different versions of user
agents and assistive technology and recording whether the features of
the technology are supported. We expect that this information may
need to be compiled from multiple sources. WAI will be working with
others to establish an approach for collecting information on the
accessibility support of various technologies by different user
agents and assistive technologies.

WCAG 2.0 is still in development. We expect that during Candidate
Recommendation period we will have some initial information on
accessibility supported technologies, to demonstrate how this
approach will work once WCAG 2.0 becomes a W3C Recommendation.

The Candidate Recommendation process itself requires that there be
examples that demonstrate conformance. So there will certainly be some
information about accessibility supported technologies in order to get
out of the candidate recommendation stage for WCAG 2.0.

----------------------------------------------------------
Comment 11: HTML Version of Understanding WCAG with semantic classes and IDs
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0073.html
(Issue ID: 2451)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Please provide semantic classes and IDs as in the quick reference to
allow automatic formatting selection mechanisms to work with
Understanding WCAG 2.0 like in the quick-reference.

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

This is an interesting idea and we fully expect a variety of materials
and ideas to emerge to help educate people about WCAG 2.0 and make the
supporting documents easier to use. However, it is beyond the scope of
the working group to develop some of these resources at this time.

Once the Guidelines are completed, we will be turning our attention
toward developing techniques and will be collaborating with Education
and Outreach to develop additional instructional materials. We would
be happy to hear more about your ideas for customizing the
Understanding document for consideration in a future version.

----------------------------------------------------------
Comment 12: Information on current location conformance level change
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0074.html
(Issue ID: 2452)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

We think the conformance level of this Success Criterioin is  too low,
because it is a almost standard to have location information on
websites, for example bread crumbs, and for users with screen readers
it would be a lot easier to know the current location.

Proposed Change:
Change Level from "AAA" to "AA"

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

There is a wide variety of content on the Web. Some are navigation
pages and breadcrumbs are common there.  Other content is copies of
documents - and breadcrumbs cannot be added to these. In fact, many
documents cannot be altered to include position information.   Also,
there are many paths that may be taken to any point. If the person
lands on a page via search, it is not clear how one would say where
they were in the site if there were many paths to this page.

Since this cannot be applied to all pages, it is at level AAA.

----------------------------------------------------------
Comment 13: Process for accessibility-supported technologies
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0132.html
(Issue ID: 2579)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

> dear editors,
>
> The Austrian association "accessible media" has the following question
> about the ongoing process for a WCAG 2.0 recommendation.
>
> What will be the expected process after publishing WCAG 2.0 as a
> (candidate) recommendation? Do we have to wait for the availability of
> lists for accessibility supported technologies? What approach will you
> recommended for web developers until there are such lists of trustworthy
> and/or official institutions available? Are there any known
> organisations that are already preparing such lists?
>
> We see the risk that many institutions will ignore the requirement #5 of
> a conformance claim, until such lists will be published together with
> the guidelines or by a governmental body.
>
> Please elaborate the expected process in the WCAG 2.0 FAQs (or somewhere
> else).
>
> best regards
> michael stenitzer

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

The working group recognizes that the need for information on which
technologies are 'accessibility-supported' is important to use of the
guidelines.

Such data can only come from testing different versions of user
agents and assistive technology and recording whether the features of
the technology are supported. We expect that this information may
need to be compiled from multiple sources. WAI will be working with
others to establish an approach for collecting information on the
accessibility support of various technologies by different user
agents and assistive technologies.

WCAG 2.0 is still in development. We expect that during Candidate
Recommendation period we will have some initial information on
accessibility supported technologies, to demonstrate how this
approach will work once WCAG 2.0 becomes a W3C Recommendation.

The Candidate Recommendation process itself requires that there be
examples that demonstrate conformance. So there will certainly be some
information about accessibility supported technologies in order to get
out of the candidate recommendation stage for WCAG 2.0.

In the interim, testing the technologies and techniques used on a site
with AT could be used.  Although this is always a good idea it is
burdensome so most people will want to use lists when they become
available.  If you are doing work in this area, particularly around
media, please contribute any information that you have about
accessibility support for media technologies. Organizations can create
their own lists of accessibility supported content technologies if
public lists are not available. This should be done in good faith with
appropriate testing.

Received on Tuesday, 11 March 2008 00:22:29 UTC