W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2004

CONFORMANCE - SUMMARY OF BUGS WITH RECOMMENDATIONS

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Sat, 30 Oct 2004 21:47:56 -0500
To: <w3c-wai-gl@w3.org>
Message-ID: <auto-000147854409@spamarrest.com>
 

Here's my deliverable from the face to face. 

 

We each took on certain guidelines for general topics. 

 

I received the conformance group of twenty issues. This is a processing of
those issues. 

 

I will cite each one in brief along with a link where the full document can
be found. I will then either add a comment and recommendations as to how to
handle it. 

 

In a post that will follow - I will paste the conformance section with these
edits made for review.

 

Gregg

 

 

------------------

 


326 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=326>   Explicit
Rationale for Success Criteria Classification


 

Summary: The title summarizes it fairly well. This is basically saying we
should document why we should put things at various levels.

 

Comment: This is part of a larger question or suggestion that we create a
new document titled something like "WCAG 2.0 Development Notes". This
document would parallel the structure of WCAG and provide notes as to the
rationale of the use of specific words and terms, the placement of elements
at various levels, etc. This would take some effort but would be immensely
instructive to anyone joining the process later on as well as anyone wanting
to understand the document. I also believe it might eliminate some questions
during our review process and/or make suggestions more on target and usable.
I think this could also be true of comments on our list. It would
undoubtedly invite some new ones but also cause the comments to be more
directed towards accurate solutions.

a

Recommendation: 

1)       that we create a document  TITLED  "WCAG 2.0 Working Group Notes
and Rationale"

2)       include a sentence in the guidelines that says "The Working Group
believes that provisions at all 3 levels are important or essential for some
people.  Thus the old descriptions of "impossible to access" for Level A,
"difficult to access" for Level AA, and "somewhat difficult" for Level AAA
are no longer used.  Instead we define the three levels as above."

3)       CLOSE this item as well as related items. 

 

 

------------------

 


368 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368>   Differences
Between Priorities and Type Levels, A, AA.


 

Summary: This is a series of comments mostly dealing with a request to
explain why we have some core and extended guidelines. These comments are
overcome by events. The rest had to do with a  request that we not abandon
the A, AA, AAA, or that we directly map our results into them in some
fashion. 

 

Comment: The core and extended discussions are overcome by events. The
mapping of items to A, AA, etc. is already being looked at. But there is not
going to be a one to one because that is not possible.

 

Recommendation: 

1)       Add a paragraph which reads 
" The Working Group believes that provisions at all 3 levels are important
or essential for some people.  Thus the old descriptions of "impossible to
access" for Level A, "difficult to access" for Level AA, and "somewhat
difficult" for Level AAA are no longer used.  Instead we define the three
levels as above."

2)        

3)       Recommend that we open a new bug item titled "Cumulative
Conformance Policy, Description, and Labeling comments "and that we just
list items that we should keep in mind which are not specific
recommendations that have to do with any particular parts of our current
wording. For example, from this checklist I would pull the following
concepts. 

-          Make it clear what the relationship between the new levels and
the old A, AA, AAA are [368]

-          It is helpful to have as much agreement between the old WCAG 1
levels and the new WCAG 2 levels [368]

-          In naming the levels (A, AA, AAA or whatever you use) think about
cross-cultural and cross language as well as screen reader readability.
[368]\

-          Consider not using A,AA and AAA so that people don't
automatically map them when they are different[368]

We might title the document "Cumulative Conformance Policy, Description, and
Labeling comments". 

2) Then close this bug. 

 

------------------

 


396 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=396>   "Plus"
Conformance Claims


 

Summary: This is a discussion of whether or not we should allow any
conformance claims other than Level 1, Level 2, Level 3. That is, would we
allow people to claim Level 2 Plus. 

 

Comment: Given our current direction including scoping, etc. it looks like
we will have something much richer than this. We have yet to determine
however how one would report or what levels of claims we would allow.

 

Recommendation: 

1.	That we leave this as an open issue 
2.	add a bullet to our conformance list which reads:

*    We need to consider carefully whether or not we should have any "2+" or
"AA+" types of conformance claims. 

 

------------------


397 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=397>   Scope of
Performance Claims 


 

Summary: Suggestion was that any scope claims in Metadata be done in URI
identification.

 

Comment: This appears to be a good idea, as much as we are able to. However,
a scope claim may talk about all of the archives and that may not be a
single URI, maybe that's a range of URIs. However, even in this case, it is
better to use a URI than a vague descriptor such as "all archives" or
"except for the archives" since it is not clear what that would constitute. 

 

Recommendation: That we say that we agree that a URI or URI based
identifications be used wherever possible in scope statements made in
Metadata. 

 

(1)     That we add a section titled: Scoping of Conformance Claims"  and
that we add the following paragraph under that title
" Conformance claims can be scoped to pertain to only some parts of a
website.  All conformance claims however must be directed to a URI or a
range of URIs.    Scoping to exclude a particular type of content (e.g.
images or scripts) from a site is not allowed since it would allow exclusion
of individual success criteria.   Scoping by URI to exclude sections of a
site is allowed by making claims for just some parts of a site."

(2)     That we add a bullet to our collection that says 

*    Scope statements made in Metadata should use URIs or should be based on
URIs (e.g., range or collection of URIs) wherever possible

(3)      We close this bug. 

 

------------------

 


452 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=452>   Conformance
and Exclusions (Scoping) 


 

Summary: This is more discussion regarding the question about whether there
should be a plus or not capability in conformance claims. 

 

Recommendation: 

(1)     That we collapse 452 into 396 since it deals with the same topic and
is essentially a continuation on the same argument. 

(2)     396 remain open.

(3)     That 452 be closed

 

 

------------------

 


476 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=476> 


Summary: He suggests that we add a conformance disclaimer and that we move
"sites that conform to WCAG 1.0" out of the conformance section and rename
it using a term such as "transition". He also makes a comment core+.
However, this latter point is OBE or should be added to 396. 


Recommendation: 

(1)     That we cut the last paragraph from this and paste it into 396 which
deals with the core+ type discussion. 

(2)     That we leave section regarding WCAG 1.0 in the conformance section

(3)     That we change the phrase "that want to shift towards WCAG 2.0 will
want." to "sites that currently conform to WCAG 1.0 that want to transition
to WCAG 2.2 over time may want . to capitalize on past accessibility
efforts"  

(4)     That we send a memo to Olivier Thereaux asking him what he means by
"adding a conformance disclaimer" 

(5)     That we close this bug. 

 

 

------------------


548 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=548>   Explain
Transition Between Normative Content of WCAG


 

Summary: This bug has two major comments in it. One of them is a better
description of the differences between WCAG 1.0 and 2.0, including the
differences in the number of checkpoints etc.

 

The second one had to do with providing a better distinction between the
normative and non-normative parts of the guidelines so that people can tell
what is required and what is informative. 

 

Recommendation:

(1)     That we change the category of this bug from conformance to a new
category called "WCAG 1.0 to 2.0 Mapping"

(2)     That we continue our practice of having all normative information
treated very different visually with mark up and with text labels with that
which is informative. 

(3)     That we add a bullet to our conformance list which states: 

*    All normative information is treated differently visually, in mark-up
and in text (labels) from information which is informative and that
informative information not be intermixed with normative except if it is
very clear that it is informative. 

(4)     That we close this bug. 

 

------------------


552 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552>  Other
comments re: conformance from EOWG


 

Summary:  Several points made

-          it is useful to have intermediate conformance (e.g. +)   [552
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> ]

-          Not realistic to have complex conformance statements (e.g.
metadata on point by point) [552
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> ]

-          If point by point then provide a model and make that optional
[552 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> ]

Recommendation: 

 

(1)     Add these to list

(2)     Close this bug. 

 

------------------


837 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=837>   Normative
vs. informative checklists and techniques


 

Full Comment:   Techniques documents will be consulted by Web developers
more than WCAG 2.0 itself. Therefore, and because the German regulation is
likely to adopt them in some form, they should be W3C recommendations rather
than informal documents. Furthermore, if the techniques documents are
informal only, a Web designer would have the choice between applying a
specific technique proposed by the techniques document, or to come up with
their own solution based on their interpretation of the WCAG 2.0 document.
This would impose a test problem and interoperability problem with AT.

 

Comment: 

   We have decided to not make techniques normative for many reasons.  The
checklists are tentatively not normative - and we hope we can keep them
non-normative so that they can adjust with changing technologies and
strategies.  However with the new BASELINE assumptions, maybe this is less
important???    

Recommendation: 

 

(1)     Discuss and see if we want to change decision on checklists based on
new BASELINE approach.

(2)     Otherwise close this item and send comment to author.

(3)     Keep a point on list that says

-          Some still interested in normative checklist at least  [837
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=837> ]

 

------------------


845 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=845>  Use of logos


 

Summary:  have separate logos for each level - with link to description of
level

 

Comment:   Agree

 

Recommendation: 

 

(1)     Add item to listing to remind us

-          [845 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=845> ]
have separate logos for each level - with link to description of level. 

 

------------------


965 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=965>  Conformance
metadata


 

Comment in full:  It is important to communicate the level of accessibility
attained by a site in the most effective way possible, and preferably in
machine-readable format so that an external user agent can automatically
determine accessibility. For this reason, we strongly support the use of
metadata to supply information about the conformance level of a site. The
Editorial Note in this section does highlight a difficulty with insisting on
metadata, but we would recommend, at the very least, a site statement
explaining the extent of conformance to WAI checkpoints, over and above the
Core/Core+/Extended labels.

 

Comment:   We haven't decided how to handle this yet. 

 

Recommendation: 

 

(1)     Add a bullet

*    965 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=965>
Conformance information in machine readable form would be useful

(2)     Leave open. 

 

------------------


979 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=979>   Statements
of the scope of conformance can be misinterpreted


 

Bug in full:  Having a statement such as "all checkpoints are met except on
the webcam at." is not ideal because such statements can be ambiguous and
open to misinterpretation, particularly if they are "cropped" by some form
of user agent that generates summary information. Also, a search engine, for
example, might interpret such a sentence as meaning that the site has a
fully accessible webcam, whereas in fact the opposite is true. A better
method would be to supply a site map providing accessibility information
about each section of the site[Bug 955
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=955> ]

 

Comment:   This speaks to having machine readable conformance. Also suggests
a method with site map - but not clear how that would not result in similar
'cropped' or 'bag of words' searching problems as cited above.

 

Recommendation: 

 

(1)     Send note back to RNID asking them how site map would avoid the
problem.  - also telling them that we recognize the problem and are
considering machine readable techniques for conformance claims - though we
don't feel we can require them.

(2)     Close this item since  

 

------------------


1000 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1000>   AAA vs
Triple-A on purpose?


 

Bug in full:  There was some confusion as to whether the slight difference
in naming convention between conformance claims in WCAG 2.0 vs. 1.0 was
purposeful:
conformance at level AAA vs. Conformance Level "Triple-A"

 

Comment:   Change was made to make it easier for screen readers.  We have
gone back to AAA for now

 

Recommendation: 

 

(1)     Send comment back.    "Change was made to make it easier for screen
readers.  We have gone back to AAA for now "

(2)     Close this bug. 

 

------------------


1001 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1001>  Conformance
declarations are not useful


 

Summary:   

(1)     What is purpose of claim?  For user?  Should it be machine readable?


(2)     Experience has shown claims to often be less than honest 

(3)     Icon on front page doesn't necessarily say much about pages
throughout site.

(4)     Don't see icon as necessary

 

Comment:   This was more comment than specific problem with guidelines.  No
suggested changes were made. We are looking at machine readable.  We already
say conformance should be URI based. 

 

Recommendation: 

 

(1)     Close this Bug.. 

 

------------------


1076 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1076>  Conformance
claims should be per page URI, not per single...


 

Bug in full: This section needs to describe how conformance claims can be
made for sites that aggregate content from other sources. Web sites do not
have a single URI that identifies all of the site, rather pages are
identified by URI and not all pages can be referenced by a unique URI.

 

Comment:   Suggest we add our latest idea regarding aggregate conformance
and see how it is reviewed. 

 

Recommendation: 

 

(1)     That we add a paragraph based on a variant of John's submission that
says :
" The conformance level for a delivered unit that contains other authored
units is equal to the lowest conformance level claimed for the delivered
unit content and any of the authored units it contains - including claims of
aggregated units.. 

(2)     Close this item - since we already have comment that claims are URI
or Range of URIs based. 

 

------------------


1143 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1143>  WCAG 2.0
and tables for layout


Summary:   this has to do with tables as layout   == and a suggestion for
4.1 L1 SC1

 

Comment: 

 

Recommendation: 

 

(1)     Re-categorize this bug to 4.1. 

 

------------------


1163 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1163>
Definition of L2 SC in Conformance section is difficult


Summary:   Definition of L2 SC in Conformance section is difficult.  It is
too abstract and vague to understand and translate into Japanese.  We are
afraid English people also feel this difficulty

 

Comment:   L2 SC in conformance is made up of phrases that are hard to
decipher.  Suggest rewording. 

 

Recommendation: 

 

(1)     . reword  L2 SC in conformance to read:

"Level 2 success criteria: 

  1)  Increase accessibility through one or both of the following:

*    further facilitating the ability of user agents to provide accessible
content additional facilitation of user agent based accessibility

*    recommends content and/or presentation that provides direct
accessibility without requiring users or their user agents to do anything
different from users without disabilities  "

 

------------------


1174 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1174>  Conformance
to WCAG1 level A doesn't guarantee WCAG2 level 1


 

Bug in full:  We are concerned that there is not a direct correspondence
between the WCAG 1.0 priorities and WCAG 2.0 levels, so that conformance to
priority 1 does not 
guarantee conformance to level A, etc.For example, WCAG 2.0 Guideline 1.1
maps into WCAG 1.0 Checkpoints 1.1, 1.2, 1.5, 6.2, 9.1, and 12.1. Five of
the checkpoints are priority 1, but one (1.5) is priority 3. Thus a website
compliant to WCAG 1.0 Priority 1 and 2 is not necessarily compliant to WCAG
2.0 Level A, creating a situation where a site has gone from being compliant
with WCAG 1.0 Priority 2 to being non-compliant with the lowest level A of
WCAG 2.0.

 

Comment:   This is true.   WCAG 2.0 is not the same as 1.0.     We recommend
that people be allowed to use 1.0 for content that was already compliant to
1.0 and where major update to material is not done.    A statement to this
effect is already in the guidelines

 

Recommendation: 

 

(1)      Send a note back similar to the COMMENT above

(2)     Close this item. 

 

------------------


1176 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1176>  Concerned
about recommended policy of mixing WCAG1 and WC.


 

Bug in full: The document advises the use of a conformance statement which
would state that materials created before a certain date conform to WCAG 1.0
and those created 
subsequently conform to WCAG 2.0.  We are concerned as to what this will
mean for the average user and what happens to pages whose content changes
but whose structure remains the same? For example, an organization may
update some information on a page, such as a street address, but the rest of
the page remains the same. Thus, the last 
updated date would be after the date, but the page might still only be
compliant to WCAG 1.0 Priority 1 & 2, and not WCAG 2.0 Level A.

 

Comment:   Yes - we discussed this but did not fix it.

 

Recommendation: 

 

(1)     .   we add the following sentence to the end of the WCAG 1.0
paragraph.
" If a delivered unit is modified in a significant way then the full
delivered unit should be brought up to WCAG 2.0"

(2)     Provide feedback

(3)     CLOSE this bug.

 

------------------


1177 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1177>  New
conformance terminology is confusing


 

Bug in full:  We recommend revisiting the change in terminology since the
WCAG 
1.0 "priorities" are more familiar and understandable for developers than
the "levels" now being used in version 2.0.

 

Comment:    Unfortunately - they were easier to understand but were
inaccurate.   Items in AAA were also critical to some users.   So we cannot
go back to those definitions, even though they did sound good and were
easier to say.

 

Recommendation: 

 

(1)      Provide feedback

(2)     Close this bug.

 


 


------------------


1223 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1223>  Issue
Summary for Conformance Issues  


 

Bug in full:   

 

Comment:    This was an action item from F2F to create a summary of items
that we just need to keep in mind - so we can close bugs that don't
recommend things and keep them all in a single list to make it easier to
keep the "advice" in mind as we proceed.

 

Recommendation: 

 

(1)     We do this.   

(2)     We rename this bug Cumulative Conformance Policy, Description, and
Labeling comments"

(3)     Here is the list so far.  The bug numbers / links make it easy to go
back to bugs if more detail is desired. 


Cumulative Conformance Policy, Description, and Labeling comments". 


 

1.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368]
Make it clear what the relationship between the new levels and the old A,
AA, AAA are. 

2.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368] [
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1000> 1000] It is
helpful to have as much agreement between the old WCAG 1 levels and the new
WCAG 2 levels   

3.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368] In
naming the levels (A, AA, AAA or whatever you use) think about
cross-cultural and cross language as well as screen reader readability. 

4.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1174> 1174 ]
Important to relate WCAG 1.0 to 2.0 

5.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=368> 368]
Consider not using A,AA and AAA so that people don't automatically map them
when they are different. 

6.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=396> 396]
That we consider whether or not we should have any "2+" or "AA+" types of
conformance claims  

7.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=397> 397]
Scope statements made in Metadata should use URIs or should be based on URIs
(e.g., range or collection of URIs) wherever possible. 

8.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=548> 548]
All normative information is treated differently visually, in mark-up and in
text (labels) from information which is informative and that informative
information not be intermixed with normative except if it is very clear that
it is informative. 

9.       [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] it
is useful to have intermediate conformance (e.g. +) 

10.   [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] Not
realistic to have complex conformance statements (e.g. metadata on point by
point) 

11.   [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] If
point by point then provide a model and make that optional  

12.   [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=837> 837] Some
still interested in normative checklist at least  (techniques also)

13.   [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=845> 845] have
separate logos for each level - with link to description of level. 

14.   [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=965> 965] [
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1001> 1001] Conformance
information in machine readable form would be useful

15.   [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=552> 552] Not
realistic to have complex conformance statements (e.g. metadata on point by
point) 

16.   [ <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=979> 979] [
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1163> 1163] [
<http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1177> 1177]  Be sure
conformance levels are easy to understand and translate

 

 

 


Gregg

------------------------

Gregg C Vanderheiden Ph.D. 
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848  
For a list of our list discussions http://trace.wisc.edu/lists/

 <http://trace.wisc.edu:8080/mailman/listinfo/>  

 

 
Received on Sunday, 31 October 2004 02:48:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:32 GMT