- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:43:12 -0700
- To: "Roger Hudson" <rhudson@usability.com.au>
- Cc: public-comments-WCAG20@w3.org
Dear Roger Hudson ,
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/20060514003512.9B70F66368@dolph.w3.org
(Issue ID: LC-470)
Item Number: Make text content readable and understandable.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Guideline 3.1 is concerned with the need to make text readable and
understandable. In general WCAG 2.0 contains very few provisions for
improving the accessibility of web content for people with cognitive
disabilities or learning difficulties. There is the level 3 SC 3.1.5,
which is concerned with the reading level of text, however it is a
fallacy to assume all cognitive disabilities somehow relate to a
persons ability to read.
WCAG 1.0 contained the Priority 1 Checkpoint 14.1 (Use the Clearest
and simplest language appropriate for a site's content). It also
contained the Priority 2 Checkpoint 12.3 (Divide large blocks of
information into more manageable groups where natural and
appropriate). Combined these two checkpoints communicated the
desirability of preparing content that could be accessed by people
with a range of cognitive and intellectual abilities and suggestions
for how this could be achieved. Unfortunately, WCAG 2.0 does not
appear to contain a similar commitment or guidance to these issues.
Proposed Change:
Guideline 3.1 should contain two new Level 2 success criteria, which read:
1. "When web units contain text, the clearest and simplest language
appropriate for the users of the content is used and large blocks of
information are presented using appropriate headings and subheading."
2. "When forms are presented, the controls in similar areas of a form
should be grouped together and appropriately identified."
----------------------------
Response from Working Group:
----------------------------
The working group was unable to come up with a testable equivalent of
WCAG1 14.1. However, we have added an advisory technique to guideline
3.1 and SC 3.1.5 that reads, "Using the clearest and simplest language
appropriate for the content."
We have also added a new Success Criterion to GL 3.1, "Pages are
organized into sub-sections with titles", to address some of the
properties covered by Checkpoint 12.3.
We have added language to the Introduction to highlight the fact that
WCAG 2 only addresses some of the needs of people with cognitive,
learning, and language disabilities, and calls out the need for more
research in this area. WAI is exploring ways in which to support and
encourage work in this important area.
We have added some best practices for cognitive, learning, and
language disabilities as advisory techniques. We have not been able to
propose many additional success criteria that meet WCAG's testability
requirements.
----------------------------------------------------------
Comment 2:
Source: http://www.w3.org/mid/20060514003246.859D166368@dolph.w3.org
(Issue ID: LC-472)
Item Number: Success Criterion 4.1.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The "Understanding WCAG 2.0" comments relating to SC 4.1.1 indicate
poorly coded content may not be correctly rendered by assistive
technologies. This accurate comment was presumably one of the guiding
principles behind the WCAG 1.0 Checkpoint 3.2, "Create documents that
validate to published formal grammars."
Although there is a view WCAG 2.0 needs to be technologically neutral,
I believe we should be mindful of the fact that most web pages today
use (x)html and this is likely to continue to be the case for the
foreseeable future. Over the years a suite of recognised standards
(html, css, mathml, etc) have emerged. Many assistive technologies
(and other devices) use these standards, and associated document type
declarations, and an increasing number of developers know that it is
desirable to produce code that complies with them.
It seems to me, the weasel words used in SC 4.1.1 are a tortured and
misguided attempt to avoid saying websites should use valid code. Why?
Surely, the W3C is one organization that should be wholeheartedly
committed to the notion of promoting clearly defined standards.
Instead, we seem to have abandoned the guideline that required the use
of valid code in favour of, what? I was interested to notice that the
"Understanding WCAG 2.0" Techniques for this SC contain three
techniques, but details are only provided for the one that relates to
"Validating web units". The last suggested technique is, "Fully
conforming to specification". No details at all appear to be provided
about what these specifications are, or who will determine them.
Proposed Change:
I believe SC 4.1.1 should remain a level 1 SC but should be rewritten
to read, "Web Units or authored components validate to formal grammars
published by the W3C."
----------------------------
Response from Working Group:
----------------------------
We have modified the success criterion to clarify that content can be
parsed successfully using the rules of the specification for the
technology in use.
The working group looked at this topic carefully over an extended
period of time and concluded that requiring strict adherence to all
aspects of specifications does not necessarily result in an increase
in accessibility. For example, it is possible to create invalid pages
that present no accessibility barriers. It is also possible in certain
situations to enhance accessibility through the use of markup that is
not part of the specification.
The working group must work within its charter and only include things
that directly affected accessibility. Some aspects of "use
technologies according to specification" and validity do relate to
accessibility. However, others do not. So requiring validity would
take us beyond our charter. We do recommend it though and it is our #1
technique listed for conforming to SC 4.1.1.
----------------------------------------------------------
Comment 3:
Source: http://www.w3.org/mid/20060514003018.1F43766368@dolph.w3.org
(Issue ID: LC-473)
Item Number: Success Criterion 2.4.4
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Although the wording of SC 2.4.4 is convoluted, it is presumably a
replacement for WCAG 1.0, Checkpoint 13.1 "Clearly identify the target
of each link [Priority 2]". However 13.1 also required the link text
to meaningful enough to make sense when read out of context, either on
their own or as a sequence of links, and this does not appear to be
the case with SC 2.4.4.
In my experience, many screen reader users extensively use the
screen-reader facility that enables them to obtain a list of links on
a page. This is often the preferred technique when looking for
information on a site or undertaking a task, and in virtually all
situations it is only effective when the link text indicates the link
destination. While I believe it is possible with some screen readers
to select an option that provides context from the surrounding text I
have never seen this done. However, many times I have seen screen
reader users become frustrated with links that contain only the words
"more", "next" or "click here".
I believe it is very important for link text to provide a clear
indication of the link destination. Also, the link text should make
sense without the need to rely on surrounding contextual information
or a title attribute within the link element.
Proposed Change:
I believe 2.4.4 should remain a level 2 SC, but should be rewritten to
read, "The target or destination of each link should be clearly
indicated by the link text."
----------------------------
Response from Working Group:
----------------------------
WCAG 1.0, Checkpoint 13.1 is the equivalent of SC 2.4.8, since SC
2.4.4 permits the use of programmatically determined context. SC 2.4.8
is at level AAA because of the potential usability problems introduced
by requiring that the link text alone be sufficient. For instance, in
a table of links, repeating the table header information in each cell
makes the table much more difficult to use.
The basic requirement that assistive technology be able to determine
the purpose of the link is covered by SC 2.4.4. This success criterion
has been moved to level A.
----------------------------------------------------------
Comment 4:
Source: http://www.w3.org/mid/20060514002813.03B0766368@dolph.w3.org
(Issue ID: LC-474)
Item Number: Success Criterion 1.4.3
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The spread of the requirement to have sufficient difference between
foreground and background colours over two Success Criterion is an
effective way of recognising the fact that the higher the contrast
ratio the more likely the information will be accessible to a greater
number of people with impaired colour vision.
However, I believe both the SC relating to this issue should be increased.
Proposed Change:
Make SC 1.4.3 a Level 2 Success Criteria
----------------------------
Response from Working Group:
----------------------------
The working group discussed this topic for a long time and after much
discussion decided that SC 1.4.3 (formerly 1.4.1) should be at level
AA and SC 1.4.5 (formerly 1.4.3) should be at level AAA. It was felt
that all of the information in the text would already be available
through the alternate texts (short alternate text and long
description) if needed and that restricting text contrast for the
default presentaion to this extent was more restrictive than desired
for a level A success criterion.
----------------------------------------------------------
Comment 5:
Source: http://www.w3.org/mid/20060514002713.3AC8F66368@dolph.w3.org
(Issue ID: LC-475)
Item Number: Success Criterion 1.4.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Many people have difficulties differentiating between the foreground
(text) and background colours used on websites. Also, as people get
older their ability to perceive colours and differentiate between
colours seems to diminish.
I believe that this is a significant accessibility issue and so should
be required if a site is to achieve a minimum level of accessibility.
Proposed Change:
Make 1.4.1 a Level 1 Success Criteria
----------------------------
Response from Working Group:
----------------------------
The working group discussed this topic for a long time and after much
discussion decided that SC 1.4.3 (formerly 1.4.1) should be at level
AA and SC 1.4.4 (formerly 1.4.3) should be at level AAA. It was felt
that all of the information in the text would already be available
through the alternate texts (short alternate text and long
description) if needed and that restricting text contrast for the
default presentation to this extent was more restrictive than desired
for a level A success criterion.
----------------------------------------------------------
Comment 6:
Source: http://www.w3.org/mid/20060514002602.3B8DE66368@dolph.w3.org
(Issue ID: LC-476)
Item Number: Success Criterion 1.3.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
It appears that SC 1.3.1 encompasses many separate guidelines that
were specified in WCAG 1.0, including the requirement to associate
data table cells with the appropriate row and column headings and
requirements relating to the labelling and grouping of form controls.
I presume part of the reason for combining such a diverse range of
accessibility needs in single success criteria is the desire to have
criteria that are "technology-independent".
In my experience, a lage proportion of the problems assistive
technology users now experience when using web sites result from the
sites failing comply with the WCAG 1.0 guidelines that are now
nominally covered by SC 1.3.1. Nearly all web content is currently
presented using (x)html and this is likely to continue to be the case
for the foreseeable future. However WCAG 2.0, which is the normative
document, provides web developers with no practical guidance or clues
in how to avoid these problems.
The link "How to meet 1.3.1" leads to information in the
"Understanding WCAG 2.0" document, which describes techniques for
addressing the criterion. The "Understanding" document contains links
to eleven HTML techniques, which are presented in yet another
document, "Techniques for WCAG 2.0".
Frankly, I don't imagine many developers when faced with the prospect
of preparing a data table will bother to troll through three documents
in order to see why it is important to associate data cells with row
and column headers in a non-visual way. On a related point, why
don’t the "Understanding WCAG 2.0" HTML Techniques include the need
to use TH for tables with single levels of row and column headers?
I am concerned that the failure to provide guidance in relation to
crucial html issues in the WCAG 2.0 document will lead to a decline in
awareness on the part of developers regarding their importance and
this will contribute to a fall in the overall accessibility of
websites and the web as a whole.
I believe the Working Group should get over their hang up with
developing some sort of technology neutral standard and recognise that
the way to bring the greatest accessibility gains to the greatest
proportion of web users is by providing practical advice in how to
improve the accessibility of (x)html sites.
Proposed Change:
In my view, WCAG 2.0 Guideline 1.3 should include success criteria for
the specific issues that are addressed in the following WCAG 1.0
Checkpoints: 3.1, 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4.
Since this is unlikely to happen, I would like to urge the Working
Group to consider providing HTML example for each of the issues
covered by the checkpoints above in the core WCAG 2.0 document so that
SC 1.3.1 is able to provide the majority of web developers with a
clear indication of how to meet this criterion.
----------------------------
Response from Working Group:
----------------------------
If the normative guidelines include the HTML-specific success
criteria, then tables, forms, headings, etc. could only conform to
WCAG 2.0 if they are implemented in HTML. Tables, forms, headings,
etc. implemented in any other technology, such as PDF, could not
conform to WCAG 2.0. It is expected that many HTML developers will
simply go directly to the HTML Techniques instead of starting with the
guidelines document.
With regard to your specific recommendations on addressing WCAG 1.0
checkpoints 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4, these checkpoints are
addressed in the following WCAG 2.0 techniques:
- 3.5; H42: Using h1-h6 to identify headings
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H42
- 3.6; H48: Using ol, ul and dl for lists
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H48
- 5.1; H51: Using table markup to present tabular
informationhttp://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H51
5.2; H43: Using id and headers attributes to associate data cells with
header cells in data tables
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H43
AND H63: Using the scope attribute to associate header cells and data
cells in data tables
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H63
- 5.5; H73: Using the summary attribute of the table element to give
an overview of data tables
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H73
- 12.4; H44: Using label elements to associate text labels with form
controls http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H44
With regard to the comment about why the Understanding WCAG 2.0 HTML
Techniques don't include the need to use TH for tables with single
levels of row and column headers, this requirement is covered in
technique H51: Using table markup to present tabular information
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H51
----------------------------------------------------------
Comment 7:
Source: http://www.w3.org/mid/20060511042111.96C5766368@dolph.w3.org
(Issue ID: LC-526)
Item Number: (none selected)
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Currently the introduction identifies cognitive limitations as one of
the disabilities that WCAG 2 addresses. Unlike WCAG 1.0, WCAG 2 gives
only scant recognition to the needs of people with disabilities.
Proposed Change:
Either improve WCAG 2.0 or remove the suggestion that the needs of
people with cognitive limitations (or difficulties) will be met.
----------------------------
Response from Working Group:
----------------------------
We have added language to the Introduction, the Conformance section,
and the Quick Reference to highlight the fact that WCAG 2 only
addresses some of the needs of people with cognitive, learning, and
language disabilities, and to call out the need for more research in
this area. WAI is exploring ways in which to support and encourage
work in this important area.
We have added some best practices for cognitive, learning, and
language disabilities as advisory techniques, and we have proposed 3
new success criteria in this area.
----------------------------------------------------------
Comment 8:
Source: http://www.w3.org/mid/20060511042214.EB6E966368@dolph.w3.org
(Issue ID: LC-527)
Item Number: (none selected)
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
The language used in the Last Call version of WCAG 2 is considerably
more readable and understandable than that used in the previous draft.
However, the desire for technological neutrality means that WCAG 2
provides very little practical guidance in how to improve the
accessibility of websites. The supporting documents do contain
specific examples and techniques, but in reality most site developers
are very busy and not particularly interested in accessibility and so
there is little chance of them searching out this information.
For example, I wonder how many people are likely to realise the need
to use header elements appropriately is covered by 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."
Proposed Change:
Since at this time most people use HTML, it would be useful to include
specific HTML-related example of how to implement the guidelines in
the core document. With reference to the example above, include the
following (which is out of WCAG 1) “User header elements to convey
document structure. For example, in HTML, use H2 to indicate a
subsection of H1.
----------------------------
Response from Working Group:
----------------------------
In an effort to make it clear what is normative and what is
informative, we have kept all examples out of the guidelines
themselves. We expect many texts to be developed that would do a
better job of teaching the guidelines. We have had to focus our
efforts on creating a clean and concise version of the guidelines.
We have tried to put links to "how to meet" next to each guideline to
make it easier without putting all the informative information
directly into the guidelines.
We'd also like to bring your attention to the draft "WCAG 2.0 Quick
Reference" document. The WCAG 2.0 Quick Reference is a summary of all
WCAG 2.0 requirements (success criteria) and techniques sufficient to
meet them. http://www.w3.org/WAI/WCAG20/quickref/
----------------------------------------------------------
Comment 9:
Source: http://www.w3.org/mid/20060511042318.D27C866368@dolph.w3.org
(Issue ID: LC-528)
Item Number: Important New Terms Used in WCAG 2.0
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The number of guidelines that use the term "programmatically
determined" concerns me. At best the glossary definition of
"programmatically determined" is perfunctory and the term looks to me
like an example of "weasel words". A simple change to the meaning of
"programmatically determined" could have a profound impact on the
meaning of some important guidelines. How and who will be responsible
for redefining words?
Proposed Change:
Avoid wherever possible the use of specialist terms that have the
potential to qualify or distort the meaning of guidelines.
Provide a clear, unambiguous and understandable definition for all
specialist terms.
----------------------------
Response from Working Group:
----------------------------
Terms like "programmatically determined" are defined in the glossary,
which is normative. The definitions cannot be changed without
submitting updated drafts to W3C process, which requires review by the
WCAG WG, the general public and the W3C.
Much effort was put into the definition of programmatically
determined. We have examined it again and tried to make it easier to
understand by adding some examples to the definition. The current
definition, at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#programmaticallydetermineddef
, is :
programmatically determined
determined by software from author-supplied data provided in a way
that different user agents, including assistive technologies, can
extract and present this information to users in different modalities
Example: Determined in a mark-up language from elements and
attributes that are accessed directly by commonly available assistive
technology.
Example: Determined from technology-specific data structures in a
non-mark-up language and exposed to assistive technology via an
accessibility API that is supported by commonly available assitive
technology.
----------------------------------------------------------
Comment 10:
Source: http://www.w3.org/mid/20060511042657.D3AED66368@dolph.w3.org
(Issue ID: LC-529)
Item Number: Conformance levels and the baseline
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
I feel the proposed system of Success Criteria is potentially
confusing and misleading. The document states the proposed grouping of
success criteria differs in important ways to the approach taken with
WCAG 1.0 since in WCAG 1.0 each checkpoint was assigned a "priority"
according to its impact on accessibility. While I had some concerns of
the allocation of specific levels of priority to checkpoints in WCAG
1.0, I felt the overall priority approach was effective since it was
easy to understand and provided clear guidance to website owners and
developers
To me the use of phrases like "achieve a minimum level of
accessibility" for Level 1 SC and "achieve an enhanced level of
accessibility" for Level 2 SC do in effect communicate levels of
impact on accessibility. As such they do not seem to be much different
to the old "priority" approach.
In practice, web developers and regulatory organizations used the WCAG
1.0 Priority levels as a measure for determining levels of
accessibility, and they are likely to continue to do so with WCAG 2.0.
On a related point, the Note, "For each success criterion, ..." is
clumsily written. I am not sure what this note is intended to
communicate, but I presume it is not supposed to suggest the Working
Group will be the body that will determine whether a success criterion
has been met. Also, if it is possible to meet a success criterion
without passing the tests for all the suggested techniques, or for
that matter any of the suggested techniques, then surely some people
will wonder why they should consider the suggested techniques at all.
Proposed Change:
Following the principle of "when it is not broke don't fix it", I
suggest the Working Group consider retaining the "priority" approach,
while of course making any necessary adjustments to the priority
levels of some criteria.
The note referred to earlier should be either re-written or removed.
----------------------------
Response from Working Group:
----------------------------
Regarding your first point: The Levels in WCAG 2.0 differ from WCAG
1.0 as described. They were changed because it was determined that
the description of the "priority levels" in WCAG 1.0 were inaccurate -
so we could not use them in WCAG 2.0. The levels in WCAG 2.0 can
however be seen as a type of priority or importance rating - and we
expect that people will use them in that manner.
Regarding the note: The WCAG Working Group does decide what it feels
are sufficient techniques for meeting the success criterion. We do not
assert that they are necessarily the only techniques - and hence we
state that explicitly. Thus authors are not required to use only
these techniques. They are useful to authors however, in that authors
can be more sure that the techniques do meet the success criteria and
they have an easier time justifying this to any third parties.
----------------------------------------------------------
Comment 11:
Source: http://www.w3.org/mid/20060511043058.23EE666368@dolph.w3.org
(Issue ID: LC-530)
Item Number: Technology assumptions and the
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
The introduction of the “baseline†could result in some web
content providers believing that it is acceptable to provide content
that will be inaccessible to some people with disabilities. It appears
that under WCAG 2.0, a site developer or some higher authority (eg
Government regulator) can set a baseline using W3C and non-W3C
technologies so long as there are “assumed†accessible user agents
that support them.
WCAG 2.0 allows develops to "assume" a technology will be supported
and provides no guidance on what this assumption should be based on.
In addition, there is no definition of what constitutes an "accessible
user agent". Are the early versions of PDF and Flash plug-ins
accessible user agents? Or, only more recent versions? And, who
decides whether a current or future user agent is accessible or not?
The guidelines provide examples of assistive technologies, but there
appears to be no requirement for a nominated baseline technology to be
supported by a significant proportion of assistive technologies that
are in current use.
With WCAG 2.0 it appears that it will be up to the person with a
disability to obtain (purchase) the technology, which the site
proprietor deems appropriate, in order to access a site, rather than
the responsibility of the site proprietor to ensure their content is
accessible to users of a wide range of assistive technologies. Such a
requirement is unreasonable, especially given the high unemployment
rate among people with disabilities, and it is also not in accord with
"beneficial" approaches to disability such as those adopted in
disability discrimination legislation. Such approaches recognise that
everyone has a responsibility to make society more universally
accessible.
Finally, I am concerned the introduction of the proposed "baseline"
concept will place a greater burden on organizations who are
responsible for promoting and ensuring best practice in the area of
website accessibility, in many different countries.
Proposed Change:
In my view the whole baseline concept needs to be revisited. However,
since this is unlikely I would like to suggest the Working Group
considers the following.
1. Avoid the use of the words "assume" and "assumed". If they are
used, provide a clear indication of what can and cannot be assumed.
2. Define what is meant by an accessible user agent (as distinct from
a user agent).
3. Include a requirement for all technologies used on a site to be
supported by a wide range of assistive devices that are at least one
generation older than the version in current release. (Clearly there
will be a need to indicate what is a "wide range" and the number is
likely to be different for different technologies - eg for screen
readers perhaps it might be four programs whereas for magnifiers it
might just be two.)
----------------------------
Response from Working Group:
----------------------------
The conformance section of WCAG2 has been completely rewritten. The
term "baseline" has been replaced by "accessibility-supported Web
technologies". The issue of what it means to be an
accessibility-supported Web technology is addressed in the section "
Accessibility Support of Web Technologies", at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
----------------------------------------------------------
Comment 12:
Source: http://www.w3.org/mid/20060520063503.753F166368@dolph.w3.org
(Issue ID: LC-562)
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Guideline 2.4 is concerned with providing mechanisms to help users
find content, orientate themselves within it and navigate through it.
Nearly all text-based information on the web is currently presented
using (x)html, and WCAG 1.0 required the appropriate use of header
elements to convey the structure of these documents. That is, the H1
header element should be used for the main heading of the page.
Subsequent headers (H2, H3 etc) should be used to identify and present
different sections and sub-sections of content on the page.
Many users of assistive technologies rely on appropriate header
elements to skim through information and easily locate the different
sections of a page. The Last Call draft puts the requirement to use
headers appropriately under SC 1.3.1. I am concerned that if there is
no specific SC relating to this issue, we will increasingly see a
range of different CSS classes being used to identify (and control the
presentation of) headings or heaven forbid, a return to the font
element. Such a situation will greatly compromise the ability of
screen reader users to find content and navigate through documents.
Proposed Change:
Given the importance of well-structured headers for screen reader
users, I believe Guideline 2.4 should contain an additional Level 1
Success Criteria that reads, "Each heading and subheading is presented
using appropriate header elements that reflect the structure of the
document and can be reliably interpreted by users agents including
assistive technologies."
----------------------------
Response from Working Group:
----------------------------
Appropriate use of headers is covered under SC 1.3.1. In particular,
"Failure of SC 1.3.1 and 1.3.4 due to using CSS to create variations
in presentation of text that conveys information without also using
the appropriate markup or text" prohibit CSS classes or font usage
without appropriate heading markup. However, because of the importance
of headings to navigation, we have added discussion to How To Meet
2.4, drawing attention to SC 1.3.1 and the role of headings in
navigation.
----------------------------------------------------------
Comment 13:
Source: http://www.w3.org/mid/20060520063621.C870766368@dolph.w3.org
(Issue ID: LC-563)
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 2.4 is concerned with providing mechanisms to help users
find content and orientate themselves and navigate through it.
However, I am concerned that there does not appear to be a success
criteria relating to the need to title frames whereas WCAG 1.0 had a
Priority 1 issue relating to this.
Although the use of frames has diminished and modern screen readers
are much better at handling frames, a significant number of sites
still contain frames. Many people, who depend on screen readers,
continue to use older version of their technologies, often for
financial reasons, and have problems orientating themselves in framed
sites and navigating through these sites.
Proposed Change:
I suggest Guideline 2.4 should contain a new Level 2 Success Criteria
that reads, \"When a web unit contains frame elements, each frame has
an appropriate title to facilitate frame identification and
navigation.\"
----------------------------
Response from Working Group:
----------------------------
We have included a sufficient technique about providing titles for
frames to Success Criterion 4.1.2 titled "Using the title attribute of
the frame element."
----------------------------------------------------------
Comment 14:
Source: http://www.w3.org/mid/20060520063728.5698766368@dolph.w3.org
(Issue ID: LC-564)
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 1.4 is concerned with making it easy to distinguish
foreground information from the background. Many people with impaired
vision, including a significant proportion of the older population,
often find it hard to read the default text size. The use of absolute
values for font sizes can make it very difficult for people with
impaired vision to increase the size of the text on the screen.
Sometime these people have the knowledge and opportunity to change the
default computer settings but this is often not the case.
Proposed Change:
I suggest Guideline 1.4 should contain a new level 2 Success Criteria
that requires the use of relative rather than absolute values to
control the size of all text including headings.
----------------------------
Response from Working Group:
----------------------------
Although resizing is primarily a user agent function, we have added
new success criteria to address the author's responsibility for
supporting text resizing:
Level AA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality.
Level AAA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality and in a way that does not require the user
to scroll horizontally.
----------------------------------------------------------
Comment 15:
Source: http://www.w3.org/mid/20060520063904.DF86A66368@dolph.w3.org
(Issue ID: LC-565)
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 4.1 is concerned with ensuring compatibility with current
and future user agents including assistive technologies. However,
within WCAG 2.0 there does not appear to be any requirement to avoid
the use of deprecated W3C technologies. Also there is no explicit
indication that layout tables should not use structural markup for the
purpose of visual formatting. It appears that many of the issues
relating to the use of tables are intended to be covered by SC 1.3.1,
however the HTML techniques relating to this SC in the \"Understanding
WCAG 2.0\" document make no reference to the inappropriate use of
table markup.
Proposed Change:
I suggest Guideline 4.1 contain a Level 1 Success Criteria which
reads, \"When a table is used for layout, it does not use structural
markup for the purpose of visual formatting.\"
I suggest Guideline 4.1 contain a Level 2 Success Criteria which
reads, \"Deprecated features of W3C technologies are not used.\"
----------------------------
Response from Working Group:
----------------------------
The Working Group agrees that misuse of layout tables should be a
failure. However 1.3.1 is the proper place for this and this is
covered by two HTML failures under 1.3.1 titled "Failure of SC 1.3.1
due to using th elements, caption elements, or non-empty summary
attributes in layout tables" and "Failure of SC 1.3.1 due to using
structural markup in a way that does not represent relationships in
the content".
RE Deprecated W3C technologies: [The Working Group assumes this
refers to deprecated features rather than deprecated technologies.]
Not all deprecated features are accessibility issues or problems for
assistive technologies. A blanket prohibition is therefore not felt
to be appropriate. If we receive information about any such issues
that we don't already know about, we will create failure techniques
for them."
----------------------------------------------------------
Comment 16:
Source: http://www.w3.org/mid/20060520064123.761C766368@dolph.w3.org
(Issue ID: LC-566)
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Guideline 4.2 relates to the need to ensure content is accessible or
provide an accessible alternative. I am concerned that overall, WCAG
2.0 does not sufficiently recognise the needs of people with cognitive
disabilities or limitations and this guideline in particular does not
appear to specifically address these needs.
In my country (and I imagine in most others) people with cognitive
disabilities and learning disorders represent the largest proportion
of the population with disabilities. In its current state, WCAG 2.0
could leave a site developer, who is keen to improve the accessibility
of a site for people with cognitive disabilities, with the incorrect
impression that all they need to do is ensure the content is at an
appropriate reading level.
WCAG 2.0 should not avoid addressing the needs of people with
cognitive disabilities with the vague excuse that it is not
immediately possible because today\'s technologies and user agents do
not adequately support content negotiation.
Proposed Change:
I strongly urge the Working Group to provide more comprehensive
guidance in how to improve the accessibility of web sites for people
with cognitive disabilities and learning disorders in WCAG 2.0.
I suggest Guideline 4.2 (and the associated documents) should specify
different ways of improving the accessibility of content for people
with cognitive disabilities and learning disorders. Also, the
Guideline should clearly indicate appropriate ways of providing
accessible alternative content.
----------------------------
Response from Working Group:
----------------------------
The former Guideline 4.2 (which has been incorporated into the
Conformance section) permits multiple versions of content, so that
specialized presentations for people with cognitive, learning, and
language disabilities can be provided.
We have added language to the Introduction, the Conformance section,
and the Quick Reference to highlight the fact that WCAG 2 only
addresses some of the needs of people with cognitive, learning, and
language disabilities, and to call out the need for more research in
this area. WAI is exploring ways in which to support and encourage
work in this important area.
We have added some best practices for cognitive, learning, and
language disabilities as advisory techniques, and we have proposed 3
new success criteria in this area.
----------------------------------------------------------
Comment 17:
Source: http://www.w3.org/mid/20060520064335.1D93366368@dolph.w3.org
(Issue ID: LC-567)
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Success Criteria 2.4.1 is a Level 1 criteria concerned with provide
mechanisms that will allow users to by pass blocks of content that are
repeated on different web pages, eg navigation menus. The HTML
techniques relating to this SC in the Understanding WCAG 2.0 document
include the use of skip links, but there does not appear to be a
requirement to make the skip links visible.
Skip links allow the user to bypass sections of the page. However,
skip links that are not visible offer no benefit to sighted users of
the web who rely on switching devices.
A user who is dependent on a switching device, such as a pressure
switch in a headrest or a \'suck –puff\' straw, often has to
physically activate the device many times as they tab though many
navigation links on their way to the page content. The inclusion of a
visible \"skip to content\" link at the top of the page would allow
them to jump directly to the content.
Proposed Change:
I suggest the Working Group explicitly require skip links to be
present and to be visible.
----------------------------
Response from Working Group:
----------------------------
This issue has been discussed by the working group many times.
Providing skip links that are visible is one instance that satisfies
SC 2.4.1 (A mechanism is available to bypass blocks of content that
are repeated on multiple web pages), but is not required. Providing
visible skip navigation links was considered a difficult requirement
for all content at Level A because of the potential for visual clutter
making content harder to understand. However, the Working Group
recognizes the importance of visible skip navigation for switch users,
those using techniques that generate keyboard strokes slowly and
others, and have changed the Example 2 in G1 to reflect this. A note
has been added which says "NOTE: When possible, a visible link is
preferred over a hidden link. 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 collegues,
keyboard only users and those navigating using voice recognition
software."
----------------------------------------------------------
Comment 18:
Source: http://www.w3.org/mid/20060520064521.0DD9866368@dolph.w3.org
(Issue ID: LC-568)
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 2.5 states, \"Help users avoid mistakes and make it easy to
correct mistakes that do occur.\" The Level 1 and Level 2 Success
Criteria for this Guideline all appear to be concerned helping people
recover from mistakes. The only SC that relates to avoiding mistakes
in the first place is a Level 3 criterion.
Proposed Change:
I suggest the Working Group consider including more information on how
mistakes can be avoided. At the least, Success Criteria 2.5.4 should
be a Level 2 criterion.
----------------------------
Response from Working Group:
----------------------------
We have created a Level AA success criterion intended to help users
avoid errors: "Labels or instructions are provided when content
requires user input".
----------------------------------------------------------
Comment 19:
Source: http://www.w3.org/mid/20060520064731.BE55E66368@dolph.w3.org
(Issue ID: LC-569)
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
I have two main concerns with 3.1.5:
First, the nominated Success Criterion is Level 3, which suggests that
it is only necessary to \"achieve additional accessibility
enhancements\" and does not need to apply to all Web resources
(without any indication of the resources it should apply to).
Second, 3.1.5 concentrates solely on a persons reading ability, which
is only one of the factors that can influence how well different
people with cognitive disabilities or learning difficulties are able
to understand a document. For example, what about people who can read
well but have considerable difficulty negotiating a complex text-type
or comprehending what is written? Or, the additional burden fully
justified text and the use of long line lengths can place on many
people with reading difficulties?
Proposed Change:
I suggest SC 3.1.5 be a Level 2 criterion at the minimum.
----------------------------
Response from Working Group:
----------------------------
The working group agrees that writing as clearly and simply as
possible is highly desirable, but could not find a way to test whether
this had been achieved.
The description of conformance levels in WCAG 2 has been rewritten to
clarify the levels ( see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ) :
The word "levels" does not mean that some success criteria are more
important than others. Each success criterion in WCAG 2.0 is essential
to some users, and the levels build upon each other. However, even
content that conforms at AAA (triple-A) may not be fully accessible to
every person with a disability.
*In general, Level A success criteria achieve accessibility by
supporting assistive technology while putting the fewest possible
limits on presentation. Thus people with a wide range of disabilities
using a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are able
to access content in different ways. In other words, Level A success
criteria support the ability of both mainstream and specialized user
agents to adapt content to formats that meet their users' needs.
* The success criteria in Level AA provide additional support for
assistive technology. At the same time, they also support direct
access to content by the many people who use conventional user agents
without assistive technology. In general, Level AA success criteria
place more limits on visual presentation and other aspects of content
than the success criteria in Level A.
*Level AAA success criteria increase both direct access and access
through assistive technology. They place tighter limits on both
presentation and content.
Because of the tighter limits that this success criterion places on
content, we feel it is appropriate at level AAA.
We have added new success criteria addressing scalability of text:
Level AA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality.
Level AAA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality and in a way that does not require the user
to scroll horizontally.
In addition, we have added advisory techniques to improve the
legibility of text:
- Avoiding justified text
- Providing sufficient inter-line and inter-column spacing
Received on Thursday, 17 May 2007 23:43:37 UTC