Your comments on WCAG 2.0 Public Working Draft of May, 2007

Dear Sandra Vassallo,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

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 May-October 2007 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

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: Guideline does not mention the need for equivalent
alternatives (only SC).
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0266.html
(Issue ID: 2096)
----------------------------
Original Comment:
----------------------------

As stated by the Guideline, the primary benefit in providing text
alternatives for any non-text content is that it can be changed into
other forms people need such as large print, braille, speech, symbols
or simpler language. However, unless the alternative conveys the same
information it may be of little use.

Courts and Government policy makers will most likely use the W3C
normative guidelines as their benchmark for determinations of
accessibility conformance and since the Success Criterion 1.1.1
(Non-text Content) already has as a checkpoint that "All non-text
content has a text alternative that presents equivalent information
...", it would be beneficial and consistent to include equivalence in
the actual Guideline.

Proposed Change:
Edit Guideline 1.1 to read "Provide equivalent text alternatives for
any non-text content so that it can be changed into other forms people
need such as large print, braille, speech, symbols or simpler
language"

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

We did have equivalent in there at one point. But not all of the text
alternatives are equivalent. In some cases it is impossible for the
text alternative to be equivalent. There are a number of text
alternatives that label content. Thus, the guideline was changed to
match this situation. The different points under SC 1.1.1 explain the
different situations in which equivalent text alternatives are
required vs when a label is deemed sufficient.

----------------------------------------------------------
Comment 2: Add definition of testability to Guidelines (Introduction & Glossary)
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0269.html
(Issue ID: 2099)
----------------------------
Original Comment:
----------------------------

There needs to be a clear definition of testability in the
Introduction and Glossary of the Guidelines so that it is understood
that this refers to both machine and human testable measures.

Testability is a core premise of the new WCAG 2.0, which I understand
to embrace both machine and/or human testability, although this is not
clearly documented in the normative guidelines. The human testable
aspect of this definition is critical to certain guidelines being
effectively implemented e.g. testing for equivalent text alternatives
to non-text content. My concern is that many developers will see
testability as a purely automated validation and when this is passed
for presence of alt text it will be considered sufficient even if were
not considered equivalent by human testers.



Proposed Change:
Include the definitions for testable (currently provided in the
"Requirements for WCAG 2.0 Checklists and Techniques" document at
www.w3.org/TR/2003/WD-wcag2-tech-req-20030207/#defs) in the normative
Guidelines Glossary and mention in the Introduction that testability
includes both machine and human testable criteria. This second point
could be achieved by editing the second paragraph in the Introduction:

"Rather than specifying what technologies to use, WCAG 2.0 lays out
general guidelines for using technologies along with specific machine
and human testable success criteria for guiding and evaluating the use
of the technologies."

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

We have added your language to the introduction.  We have not defined
testability since we are using it in the normal English language sense
of the word.   We do discuss its meaning however in the Conformance
section of the guidelines.

----------------------------------------------------------
Comment 3: Skip links are not required to be visible (G1)
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0270.html
(Issue ID: 2100)
----------------------------
Original Comment:
----------------------------

The techniques document currently includes appropriate rationale i.e.
"visible links are necessary for those navigating with a keyboard
including switch users, those using techniques that generate keyboard
strokes slowly, screen magnification software users, screen reader
users working with sighted colleagues, keyboard only users and those
navigating using voice recognition software". However the preceding
sentence "when possible, a visible link is preferred over a hidden
link" seems to contradict the importance of this.

Proposed Change:

Change "when possible ..." to read "skip links are required to be
visible, not hidden, at least on keyboard focus."

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

We have updated the sufficient techniques related to skip navigation
links to include a requirement that the links either be always visible
or visible when they have keyboard focus. We have also removed the
sentence, "When possible, a visible link is preferred over a hidden
link."

----------------------------------------------------------
Comment 4: Stronger statement about accessibility for people with
cognitive disability
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0271.html
(Issue ID: 2101)
Status: VERIFIED ACCEPTED
----------------------------
Original Comment:
----------------------------

In their current form there are still some important areas of web
accessibility for people with cognitive, language, and learning
disability that are not covered by the WCAG 2.0 Guidelines and due to
testability are unlikely to be accepted.

With this in mind a stronger statement about the importance of web
accessibility for this audience and the need for developers to
consider issues affecting these users would be worthwhile.

The first part of this issue has already been taken up in the recent
draft, which states:

"Although some of the accessibility issues of people with cognitive,
language, and learning disabilities are addressed by WCAG 2.0, either
directly or through assistive technologies, the WCAG 2.0 guidelines do
not address many areas of need for people with these disabilities.
There is a need for more research and development in this important
area." (WCAG 2.0 Introduction)

In addition a statement that encourages developers to follow current
best practice for this group as part of meeting their accessibility
obligations would help raise awareness and provide support for any
companion documents/checklists that may be developed by authoritative
agencies in the future.

Proposed Change:

Add the following recommendation to the end of the existing paragraph
in the WCAG 2.0 Guidelines:

"... There is a need for more research and development in this
important area and developers should seek relevant expert advice about
current best practice to ensure that web content is accessible, as far
as possible, to this community."

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

The Working Group hoped that the inclusion of the sentence "There is a
need for more research and development in this important area." would
encourage support in the research community for additional work in
these areas.  At the request of several reviewers, we have removed it.

We added the sentence based on comments submitted:

Authors are encouraged to consider the full range of techniques,
including the advisory techniques, as well as to seek relevant advice
about current best practice to ensure that Web content is accessible,
as far as possible, to this community. Metadata may assist users in
finding content most suitable for their needs.


In context it reads:

All of these layers of guidance (guidelines, success criteria, and
sufficient and advisory techniques) work together to provide guidance
on how to make content more accessible. Authors are encouraged to view
and apply all layers that they are able to, including the advisory
techniques, in order to best address the needs of the widest possible
range of users.

Note that even content that conforms at the highest level (AAA) will
not be accessible to individuals with all types, degrees, or
combinations of disability particularly in the cognitive language and
learning areas. Authors are encouraged to consider the full range of
techniques, including the advisory techniques, as well as to seek
relevant advice about current best practice to ensure that Web content
is accessible, as far as possible, to this community. Metadata may
assist users in finding content most suitable for their needs.

----------------------------------------------------------
Comment 5: Clarification on Conformance Requirements for Alternative Content
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0280.html
(Issue ID: 2110)
----------------------------
Original Comment:
----------------------------

The option to accept an alternative accessible page has merit but is
also a significant weakness and I am nervous that this may be used by
some websites as a way to legitimately avoid any efforts involved in
making the primary content accessible. The legacy of "text only" links
as the accessibility solution to HTML 3.2 is only just being redressed
and WCAG 2.0 seems to open the possibility for this to start all over
again with a proliferation of "alternate" pages. This approach treats
people with disability as a separate audience, rather than
acknowledging them as part of the diversity in every audience (i.e.
children with disability, job seekers with disability, seniors with
disability, employer with disability).

In its current form this requirement appears to make it acceptable for
software developers to release and re-release versions of their
product with no priority or time frame for including accessibility but
to still be used on accessible websites and have the status of
conforming to the level of the accessible alternate page.

In a commercial world there are many competing demands for time and
resources with the result that accessibility is often seen as a lower
priority. Once it is acceptable for developers to publish alternate
content pages then championing mainstream accessibility becomes
harder, especially when this approach is endorsed by an international
body with the standing of the W3C. As such, I suspect accessibility
considerations will have less chance of competing with other important
business requirements.

Similarly, once alternate pages are published there is little
incentive in the Guidelines for developers to make the main pages
accessible in the future and in practice (unless they are drawn from
single sourced content) alternate pages are infrequently, if ever,
updated. For example, there is no requirement (I could see) to make
the main web page accessible if it becomes possible to do this with
the software at a later date or for people to make it accessible if it
is possible but harder to implement using the software accessibility
properties. Currently "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" is acceptable.

Getting to the accessible content in an accessible way from an
inaccessible page is also an unresolved issue at present (as
documented in the WCAG 2.0 Editorial Note) and I'm wondering why the
focus is not on universal design with progressive enhancement for
inaccessible formats, starting with the accessible document as the
main/default page.

Note: I have not had time to fully explore all the WCAG 2.0
documentation in the time available for comments, so please let me
know if this concern is already addressed. However, from my reading so
far it seems to be rather a big issue that is not yet satisfactorily
resolved – in that websites can claim conformance in principle while
not conforming in spirit to the Guidelines.



Proposed Change:
This needs more thought than I've had time to give it at present, but
possible changes might include:

* a statement to the effect that if it is possible for the main
content to be made accessible then an alternate page is not acceptable

* making the most accessible page the main/default page with links to
or progressive enhancement of inaccessible content

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

We have added a note to say "Alternate versions may be provided to
accommodate different technology environments or user groups. Each
version should be as conformant as possible. One version must be fully
conformant in order to meet conformance requirement 1."

----------------------------------------------------------
Comment 6: Text resizing - What Level
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0281.html
(Issue ID: 2111)
----------------------------
Original Comment:
----------------------------

The ability to resize text can be critical to accessibility for people
with print disabilities such as degenerative eye sight and
reading/learning difficulty but this does not seem to be adequately
covered in the Guidelines.

1. SC 1.4.4 Resize Text is a Level AA requirement (rather than Level A)

2. Text as an image appears to be acceptable, yet images are not
resizable by many browsers and where image ‘zoom’ is a feature of
the browser this can create other accessibility problems such as
broken page formats, horizontal scroll bars and pixelation of the
text/image. Turning images off to view the alt text is not a practical
solution, since many people do not know how to do this and once set
this preference applies to all images not just text images. It becomes
increasingly difficult when text based images are used for navigation
elements, such as an image map.

3. Resizing of text based form content and form controls also does not
seem to be mentioned and textual content in non-text based form
controls also needs to be resizable by the user. For example: using
the browser resizing options in forms is problematic when the text
resizes but not the radio button.

Proposed Change:
1. Move SC 1.4.4 to Level A

2. Text as an image should not be acceptable unless Success Criterion
are applied that would address the needs of people with print
disability

3. Include Success Criterion for resizing of text based and non-text
based form controls

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

RE # 1. Move SC 1.4.4 to Level A

This provision may not be implementable with some technologies
directly but the same effect could be achieved with assistive
technologies.   Because of these factors the Working Group feels that
his provision is better put at Level AA.  The working group examined
the issue of images of text carefully and felt that they should be
allowed,.

The group feels that the majority of images of text used on the web
these day can be zoomed up to 200% and down to 50% without pixelation
being a significant barrier. For zooming above that AT have smoothing
algorithms. The group also feels that there are sufficient resources
in the operating system and with external AT devices that contrast
issues can be handled at level AA. However, we have made a note in the
understanding document describing some of the problems with images of
text such as contrast and pixelation, and we encourage text. And we
have added a note to 1.4.3.

For 1.4.3: Note: Images of text do not scale as well as text because
they tend to pixelate. It is also harder to change foreground and
background contrast and color combinations for images of text, which
is necessary for some users. Therefore, we suggest using text wherever
possible, and when not, consider supplying an image of higher
resolution.

For 1.4.4: Note: Images of text do not scale as well as text because
they tend to pixelate, and therefore we suggest using text wherever
possible. It is also harder to change foreground and background
contrast and color combinations for images of text, which are
necessary for some users.

RE #3 Include Success Criterion for resizing of text based and
non-text based form controls

We think this should be a User Agent guideline, and just an
advisory/repair  technique in WCAG. If text is big enough to be
useful, it will be so big that designers won't want to use it. If some
elements scale and others don't, the layout is likely to get messed
up.  Whether that's a barrier or not depends on whether content or
functionality is lost, but it's much eaiser to get this right when
everything scales such as a user agent zoom, commercial AT, or
operating system magnification. However we have added a sufficient
technique for 1.4.4: "Specifying the size of objects in terms of the
font size"

By the time WCAG reaches recommendation, we expect Zoom features in
browsers will become more and more used among people who need moderate
amounts of zoom. We realize that this is not perfect, but we think it
is the best compromise given the alternatives.

Received on Sunday, 4 November 2007 05:10:45 UTC