- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:28:00 -0700
- To: "Gian Sampson-Wild" <gian@tkh.com.au>
- Cc: public-comments-WCAG20@w3.org
Comment 21: Level A and AA don't apply to all web sites
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0119.html
(Issue ID: 2334)
----------------------------
Original Comment:
----------------------------
Apparently Level A and Level AA SC must be able to be applied to all web
content. Many comments that I submitted came back with "we'd love to put
that in a lower level but it doesn't apply to all web content so we can't"
(I'm paraphrasing).
I don't believe you can argue that all Level 1 and 2 SC must apply to all
web pages because there are many Level 1 and 2 SC that cannot be applied to
all web pages, such as SC 2.4.4 (A) which refers to link text - not all web
pages will have link text (ie. a one page site) or SC 3.2.2 (A) which refers
to a user interface component or SC 3.3.1 (A) which refers to an input error
(which therefore requires an input).
Proposed change: Remove the requirement that Level 1 and Level 2 SC must
apply to all web pages and reallocate SC according to importance to people
with disabilities
---------------------------------------------
Response from Working Group:
---------------------------------------------
The success criteria have been worded as properties of the content in
such a way that the statement is true when there is no corresponding
content. For example, "The purpose of each link can be determined from
the link text and its programmatically determined link context" is
true when there are no links.
Some success criteria can not evaluate to "true" for some Web pages
due to the inherent nature of the content or functionality.
We believe that every success criterion in WCAG 2.0 is important to
someone with some disability. One of the lessons of WCAG 1.0 was that
the interpretation that checkpoints at higher levels were less
important to people with disabilities meant that some disabilities
were being considered less important than other disabilities.
----------------------------------------------------------
Comment 22: LC-1129: make critical examples key terms?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0130.html
(Issue ID: 2335)
----------------------------
Original Comment:
----------------------------
Comment 102:
Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1129)
There are examples in the Intent section
Proposed Change:
All examples should be in the Examples or Failures section
----------------------------
Response from Working Group:
----------------------------
The examples in this item are not examples of the success criterion or
meeting the success criterion but rather examples of what we mean by one of
the terms in the success criterion. So these particular examples can't go
in the examples section.
----------------------------
Response from GSW:
----------------------------
Then perhaps this should be in the "key terms" section? I am concerned that
people will skip over the "intent" section and miss the important definition
information provided by these examples.
---------------------------------------------
Response from Working Group:
---------------------------------------------
We have added some examples to the definition of "change of context":
"Submitting a form, opening a new window, or moving focus to a
different component are examples of changes of context"
----------------------------------------------------------
Comment 23: LC-1069: programmatically determined
Source: http://http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0107.html
(Issue ID: 2336)
----------------------------
Original Comment:
----------------------------
Comment 46:
Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1069)
Stylesheets: It could be argued that the sequence of content can always be
programmatically determined- otherwise it could not be presented to the user
in that particular sequence. Because 1.3.3 maps to checkpoint 6.1, it is
obvious that what is meant by the WCAG2 SC is that if style sheets are used
to manipulate the layout of text, then the layout without style sheets must
present a meaningful alternative. However it can be argued that simply
because a user agent (ie browser) can interpret the style sheet to present
information in a certain way, that it is automatically programmatically
determinable.
Proposed Change:
Clarify the SC 1.3.3
----------------------------
Response from Working Group:
----------------------------
Please note that the the definition of programmatically determined
specifically covers support by assistive technologies: "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".
CSS can be used to position items visually on a page. While the position is
of course programatically determined, the reading order on the basis of CSS
positioning is not, because CSS lacks layout concepts such as "previous" or
"next" that would define, unambiguously, the proper reading order of a
graphical layout. In theory, advanced heuristics might be able to
extrapolate this information, but such approaches are not supported by
current tools so this is not a sufficient technique at this time. Therefore,
this success criterion does have relevance and it is recommended to follow
the sufficient techniques provided.
----------------------------
Response from GSW:
----------------------------
If this is the case then I believe that the term "programmatically
determined" should be replaced with something like "supported by AT". The
term "programmatically determined" indicates that information can be
determined programmatically which is not what it appears the Working Group
means at this point.
---------------------------------------------
Response from Working Group:
---------------------------------------------
The term does mean supported by AT. But it also means supported by the
accessibility features in user agents. So we cannot change it to only
'supported by AT'.
----------------------------------------------------------
Comment 24: LC-1064: validity
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0109.html
(Issue ID: 2337)
----------------------------
Original Comment:
----------------------------
Comment 41:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1064)
4.1: There should be (preferably at Level 1) a requirement for content to
validate
Proposed Change:
Create a Level 1 SC requiring validation
----------------------------
Response from Working Group:
----------------------------
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 number one technique listed for conforming
to SC 4.1.1.
----------------------------
Response from GSW:
----------------------------
The points you raise here could be applied to numerous SC within WCAG2. For
instance it is possible to provide a site with images that do not have any
ALT attributes (a violation of Guideline 1.1.1) and not present any
accessibility barriers - for instance if the images were all spacer gifs.
It is also possible to enhance accessibility in some situations by violating
any number of SC - for instance when providing videos to people with
cognitive disabilities to convey information provided in the text (this does
not therefore need a text equivalent but it doesn't need to be marked up
with captions and audio descriptions). There is an exception in WCAG2 for
this latter example as there could be for validity. I see nothing wrong with
saying "produce valid documents except where additional accessibility
features force invalid code".
As for the Working Group working within its charter - there are also many
situations where you could argue that SC do not *entirely* relate to
accessibility. Error prevention would be one example. Even alt attributes do
not relate entirely to accessibility due to their use as a tool tip in
several major browsers.
---------------------------------------------
Response from Working Group:
---------------------------------------------
The Working Group does not agree that its stance on validity is
inconsistent with the treatment of other Success Criteria. Success
Criterion 1.1.1 makes specific provisions for spacer images with the
"Decoration, Formatting, Invisible" point, and a site using only
spacer images would conform to WCAG as long as the images were marked
so they could be ignored by AT. The Working Group has also been
careful to avoid creating success criteria that it might be necessary
to violate to enhance accessibility. The Working Group also has been
careful to remain within its charter. The example about error
correction does benefit more than just users with disabilities, but
the Working Group has determined that the impact of errors on people
with disabilities is disproportionately larger than on people without
disabilities, and therefore is within the WCAG mandate to include. In
the case of validity, however, the Working Group has not been able to
make a parallel determination, and therefore has determined that a
validity requirement, beyond the very specific subset provided, is in
fact completely beyond the scope of the WG.
----------------------------------------------------------
Comment 25: LC-1066: Images for markup and SVG
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0110.html
(Issue ID: 2338)
Status: VERIFIED PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------
Comment 43:
Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1066)
Images for markup: Seeing as this WCAG1 checkpoint does not map to a
particular SC, does this mean that WCAG2 allows images to be used instead of
markup, for example, images of text, instead of CSS-manipulated text? Or
images for bullets instead of marked up bulleted lists?
Proposed Change:
Clarify the mapping of 3.1.
----------------------------
Response from Working Group:
----------------------------
The mapping has been removed from the WCAG document itself and will now be
included in the WCAG 1.0 to WCAG 2.0 transition materials. This will make it
easier to update the mapping as new techniques are developed.
The working group will work in coordination with the EOWG WCAG 2.0 Materials
Support Task Force in the creation of transition materials and will consider
these comments when the mapping is updated.
To answer your question, WCAG 2.0 does not prohibit the use of images of
text provided that they have text alternatives. There is, however, an
advisory technique that advises against the use of images of text in order
to acheive a desired visual effect. Success criterion 1.3.1 lists the use of
,
and
for lists as a sufficient technique. Other techniques could be
used, but text alternatives would have to make the information and
relationships conveyed through this use of images clear.
----------------------------
Response from GSW:
----------------------------
What about SVG?
---------------------------------------------
Response from Working Group:
---------------------------------------------
If SVG is accessibility supported, it allows for more accessible
solutions in many of these situations. We welcome contributions of SVG
techniques.
----------------------------------------------------------
Comment 26: LC-1063: testing 4.1.1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0112.html
(Issue ID: 2339)
----------------------------
Original Comment:
----------------------------
Comment 40:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1063)
4.1.1: How is this to be tested?
Proposed Change:
Provide information
----------------------------
Response from Working Group:
----------------------------
To make this requirement easier to understand, we have reworded SC 4.1.1 to
clarify that it must be possible to parse content without the need for user
agent repair. The revised SC reads as follows:
4.1.1 Content implemented using markup languages has elements with complete
start and end tags, except as allowed by their specifications, and are
nested according to their specifications. (Level A)
Note: Start and end tags that are missing a critical character in their
formation, such as a closing angle bracket or a mismatched attribute value
quote are not complete.
Information about how to test this criterion is available in Understanding
4.1.1.
----------------------------
Response from GSW:
----------------------------
My question is more about *how* this will be tested - not *what* to test. Is
there a tool out there that can test this (without testing validity). How
does the WG intend people to test this? How will the WG test this during the
implementation review?
---------------------------------------------
Response from Working Group:
---------------------------------------------
Validation tools can be used to test this success criterion since
these requirements are a subset of validity. Full validity is not
required though. Only those components listed in the SC. Using a
validator has the added benefit of making authors aware of all of
their validity violations and encouraging them to address as many as
possible. It is also possible to test this by manual inspection of the
code. While that method is painstaking and unlikely to be used often,
it meets the definition of testability.
It would also be possible to develop a simpler tool that checked for
just these violations *in HTML pages*. However, the working group is
not aware of any such targeted tools at this time. *For XHTML and
other XML vocabularies, any conforming XML parser can be used to check
this.
----------------------------------------------------------
Comment 27: LC-1060: clarify 3.2.1 and 2.2.5
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0114.html
(Issue ID: 2340)
----------------------------
Original Comment:
----------------------------
Comment 38:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1060)
3.2.1 & 2.2.5: From my reading, 3.2.1 outlaws changes of context when a
component receives focus, but 2.2 allows changes in content for no reason
(only outlawing at L3)
Proposed Change:
Rewrite SC 3.2.1 and 2.2.5
----------------------------
Response from Working Group:
----------------------------
While it is possible that the result of a time limit expiration may be a
change in context or content, success criterion 2.2.1 and 3.2.1 (both at
level A) work together to ensure that both unexpected changes in context as
the result of a component receving focus (3.2.1) and changes in content
resulting from a time-out (2.2.1) will not occur unexpectedly. While
exceptions to success criterion 2.2.1 for real-time events and activities
where timing is essential exist, guideline 2.2 does not allow changes in
content for no reason.
----------------------------
Response from GSW:
----------------------------
I interpreted this SC differently from the stated intention above so perhaps
the WG should consider clarifying some of the SC to avoid such confusion
---------------------------------------------
Response from Working Group:
---------------------------------------------
Guideline 2.2 does not speak to the issue of changes of content. It
sets requirements for processes that occur after a timeout, which may
or may not involve a change of content. 3.2.1 puts specific limits on
changes of context when an object receives focus. There may be
situations in which both of these are applicable and conforming
content must meet the requirements of both. There may be other
situations, however, in which only one is applicable.
In order to clarify this issue we have added the following to the
understanding document:
"Note: This provision acts to ensure that changes in content or
context as a result of a time-out will not occur unexpectedly,
preventing users from completing tasks. While exceptions to success
criterion 2.2.1 where timing is essential exist, guideline 2.2 in
general limits changes in content for no reason. This provisions
should be considered in conjunction with provision 3.2.1 which puts
limits on changes of content or context as a result of user action."
----------------------------------------------------------
Comment 28: LC-1059: SC 3.1.4 should be Level A
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0115.html
(Issue ID: 2341)
----------------------------
Original Comment:
----------------------------
Comment 37:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1059)
3.1.4: If information is provided in an abbreviated form without expansion,
then the content is essentially inaccessible to people that cannot interpret
the abbreviation. People who use screen readers and people with cognitive
disabilities often have difficulties interpreting abbreviations.
Proposed Change:
There should be a Level 1 version of this SC which requires that important
abbreviated information is marked up, or expanded the first time it is used
in a page
----------------------------
Response from Working Group:
----------------------------
As outlined by the different situations in SC 3.1.4, providing the expansion
for the first use of an abbreviation is only a sufficient technique when the
abbreviation only has one expansion on that web page, e.g., Dr. is only used
as an abbreviation for doctor or for drive, but not for both. Otherwise,
providing the expansion on the first use will be more confusing for users
with cognitive disabilities.
----------------------------
Response from GSW:
----------------------------
My comment pertains not to the SC itself but the level it is situated at. I
believe this SC needs to be at Level A
---------------------------------------------
Response from Working Group:
---------------------------------------------
Many fields include acronyms among their jargon, and these would have
the same difficulties discussed in our response to your comment on
3.1.3. A computer science paper with links on all the abbreviations
would be very difficult to read. The working group feels that this is
the appropriate level for this success criterion because it can't be
applied to this type of technical content, and is therefore not
appropriate for all types of sites.
For these reasons, the group feels that is should remain at level AAA.
It should be noted that acronyms were AAA in WCAG 1.0 as well.
----------------------------------------------------------
Comment 29: LC-1057: GL 3.3 needs Level A SC
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0116.html
(Issue ID: 2342)
----------------------------
Original Comment:
----------------------------
Comment 35:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1057)
2.5: There should be a Level 1 SC which requires error prevention
techniques, such as providing instructions at the beginning of a form
Proposed Change:
Create a new SC. I am happy to help with this
----------------------------
Response from Working Group:
----------------------------
In addition to success criteria 2.5.3 and 2.5.4 in the April 2006 draft, we
have created two new success criteria intended to help users avoid errors:
1. A Level AA success criterion "Labels or instructions are provided when
content requires user input". 2. A Level AAA success criterion that is
similar to the level AA (was
2.5.3) success criterion except there are no exceptions. "For forms that
require the user to submit information, at least one of the following is
true:
1. Reversible: Transactions are reversible.
2. Checked: Submitted data is checked for input errors before going on to
the next step in the process.
3. Confirmed: A mechanism is available for reviewing, confirming, and
correcting information before finalizing the transaction."
----------------------------
Response from GSW:
----------------------------
I still believe there needs to be a SC at Level 1.
---------------------------------------------
Response from Working Group:
---------------------------------------------
We have moved SC 3.3.4 from AA to A.
----------------------------------------------------------
Comment 30: LC-1056: SC 2.4.8 should be Level A
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0117.html
(Issue ID: 2343)
----------------------------
Original Comment:
----------------------------
Comment 34:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1056)
2.4.4 & 2.4.8: 2.4.8 should move to Level 1 and replace 2.4.4. People who
use screen readers often navigate through a page by tabbing from link to
link and therefore can determine the content on the page. Allowing for link
text to not describe the target of the link means that these users will find
it difficult to navigate.
Proposed Change:
Move to Level 1 and delete 2.4.4
----------------------------
Response from Working Group:
----------------------------
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.
----------------------------
Response from GSW:
----------------------------
I don't believe it is the WG's responsibility to determine usability issues.
This issue you cite could be avoided by a different layout or design and
should not be used as a reason why such an important requirement is
relegated to the highest level.
---------------------------------------------
Response from Working Group:
---------------------------------------------
The working group recognizes that the link list mechanism provided by
user agents and assistive technology will provide best results when SC
2.4.8 is satisfied.
While the working group encourages authors to make link text as
descriptive as possible out of context, we do not feel that this
success criterion can be satisfied for all Web pages. For Example:
- a page has book titles followed by PDF, HTML, DOC.
- Article name (long) followed by a sentence and the link "more"
- GOOGLE search where each entry has text plus the following links
[translate this page] HTML and [CACHED] and [SIMILAR PAGES]
- toolbar with menus with an arrow icon - the link says "open".
Having full links makes the page very cluttered, harder cognitively to
find things when the same long (sometimes multi-line) text is
repeated with one word different, and is very long to listen to for
those not adept at auditory skipping (or where unique information is
back end loaded)
These issues were considered carefully for a long time, the working
group feels that having 2.4.4 at Level A and this issue addressed at
Level AAA strikes the right balance.
While user agent and assistive technology support for finding the link
context is poorer than we would like, we have checked that there is at
least one case of support for each of the types of link context we
have listed as sufficient techniques. So a user who has tabbed to a
link can ask for those pieces of context without leaving the link.
We hope that if authors satisfy SC 2.4.4 and make link context
programmatically determinable, user agent developers will find a way
to let users access the context when needed, such as when the link
list is created.
The first techniques listed in 2.4.4 are:
"G91: Providing link text that describes the purpose of a link
H30: Providing link text that describes the purpose of a link for
anchor elements (HTML)
----------------------------------------------------------
Comment 31: LC-1054: change level - most web pages are part of a set
of web pages
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0123.html
(Issue ID: 2344)
----------------------------
Original Comment:
----------------------------
Comment 33:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1054)
2.4.7: This should be at Level 1. Determining the current location is
sometimes very difficult for both people who use screen readers and people
with cognitive disabilities
Proposed Change:
Move to Level 1
----------------------------
Response from Working Group:
----------------------------
This success criterion is at level AAA because not all web pages are part of
a set of web pages to which this success criterion can be applied. The
working group agrees that when it does apply, it is very important for
people with these disabilities.
----------------------------
Response from GSW:
----------------------------
I think the WD should represent the most common situation and the most
common situation is that a web page is part of a set of web pages. Please
also see my comment on applicability [[Recorded at
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=2334]]
---------------------------------------------
Response from Working Group:
---------------------------------------------
This is positioned at Level AAA because it can not always be applied
to all types of Web content. Many Websites are Web rather than
Linear in nature. that is, they are not a progression of pages but a
cluster of pages that are all interlinked. Sites (or sets of pages)
like this are very hard to discuss in terms of "position". A complex
visual map showing all the links between the pages can be constructed
but is incomprehensible to people with cognitive disabilities and
extraordinarily hard or impossible to describe in words. In fact you
have to view it interactively to be able to see it visually. Because
such sites and sets of web pages do not lend them selves to mapping
this is in Level AAA.
----------------------------------------------------------
Comment 32: LC-1049: Level of 3.2.3 vs 2.3.2
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0124.html
(Issue ID: 2345)
----------------------------
Original Comment:
----------------------------
Comment 29:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1049)
2.3.2: This should be L2 or there should be a L2 equivalent
Proposed Change:
Create L2 equivalent
----------------------------
Response from Working Group:
----------------------------
Because of the limitations that SC 3.2.3 places on presentation, the working
group feels that level AAA is appropriate. Not all Guidelines have success
criteria at every level.
----------------------------
Response from GSW:
----------------------------
Interesting response seeing as SC 3.2.3 is at Level AA. Perhaps its limits
on presentation was not so constrained?
---------------------------------------------
Response from Working Group:
---------------------------------------------
We appologize. There was a typo in our response. We typed #3.2.3
instead of 2.3.2. It was a response to your comment about 2.3.2 (Three
Flashes). Please consider it a response to issue LC-1049 which was
your comment about 2.3.2 (Three Flashes)
----------------------------------------------------------
Comment 33: LC-1062: SC 4.1.2 too difficult to understand
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0129.html
(Issue ID: 2346)
----------------------------
Original Comment:
----------------------------
omment 1:
Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1062)
4.1.2: What is the "name" or the "role"? What does it mean "values can be
set by the user"?
Proposed Change:
Rewrite SC 4.1.2
----------------------------
Response from Working Group:
----------------------------
The terms "name" "role" and "programmatically set" are each defined in the
glossary. How to Meet SC 4.1.2 describes the intent of this success
criterion and provides techniques about how to meet it. With regard to your
suggestion to rewrite 4.1.2, without more information about the problems you
see with this provision or specific suggestions for how to rewrite this
criterion, we are unsure how to address your comment.
----------------------------------------------------------
----------------------------
Response from GSW:
----------------------------
My concern is that this SC is so full of jargon (and terms that require
glossary entries) that it does not make sense. I still have trouble
determining what this SC is meant to achieve and I have worked on this SC
when I was on the WG. I can only get a sense of what this SC aims to achieve
by reading the techniques section. I think it needs to be rewritten and, if
necessary, it needs to be broken up and moved to other areas.
---------------------------------------------
Response from Working Group:
---------------------------------------------
This success criterion addresses requirements on authors who are using
programming technologies to create user interface components, and can
be expected to understand the terms. It is expressed in technology
neutral language so that it is applicable across different scripting
technologies and across different environments that support different
accessibility APIs. To accomplish this, it uses technical terminology
to describe those requirements.
While we have defined the technical terms in the glossary, we
recognize that this is still a difficult success criterion to
understand for people not familiar with programming concepts.
----------------------------------------------------------
Comment 34: LC-1130: include examples of failures
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0134.html
(Issue ID: 2347)
----------------------------
Original Comment:
----------------------------
omment 103:
Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1130)
Needs more examples
----------------------------
Response from Working Group:
----------------------------
This success criterion requires that you not do something. We don't provide
examples of things not to do because they can be misunderstood as examples
of how to conform. We tried to think of positive examples of thing to do
that didn't violate the provision but that was pretty much anything. We have
provided one. If you can think of another positive example (not an example
of a failure) we would be happy to include it as well.
----------------------------
Response from GSW:
----------------------------
Wouldn't "common failures" be an example of things one should not do? That
seems to be a perfect place for these kind of examples and have been used
throughout the document
---------------------------------------------
Response from Working Group:
---------------------------------------------
Common Failures are a particular class of Technique which are clearly
identified as Failures. Currently, there are 2 common failures for
3.2.1
F52: Failure of SC 3.2.1 due to opening a new window as soon as a new
page is loaded without prior warning
F55: Failure of SC 2.1.1 and 3.2.1 due to using script to remove focus
when focus is received
If you feel there should be other common failures, please feel free to
submit them.
----------------------------------------------------------
Comment 35: LC-1091: Techniques are script heavy
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0098.html
(Issue ID: 2348)
----------------------------
Original Comment:
----------------------------
Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1091)
Script: The techniques and examples are very script heavy. It appears, to a
casual reader, that the W3C is advocating scripting above other
technologies, such as PDF, XHTML or CSS.
Proposed Change:
Ensure that techniques and examples are evenly spread over a variety of
technologies
----------------------------
Response from Working Group:
----------------------------
The examples have to match the technologies. The scripting examples are only
used where we are trying to demonstrate dynamic content. Scripting is the
most common method for this. If you have other examples you think could be
included, please submit them. We are always looking for additional good
examples.
----------------------------
Response from GSW:
----------------------------
I am not a Member of the Working Group. If I was I would be happy to write
such techniques. I believe that these types techniques are a direct result
of the people involved in the Working Group and therefore it is inherently
biased towards these types of technologies
---------------------------------------------
Response from Working Group:
---------------------------------------------
There is no need to be a Working Group member to submit techniques. We
are openly inviting the web community to submit techniques that they
think would sufficiently meet various Success Criteria. We are also
open to contributions of advisory techniques. This process will also
continue after the WCAG is released.
Received on Sunday, 4 November 2007 04:28:12 UTC