General Issues - Proposals to close

 


482 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=482>     WCAG 1.0
checkpoints 6.1, 6.3, 6.5 and 11.4 should be included in WCAG 2.0 and make
them core.


Old note about  [read without style sheet, use when script etc turned off,
dynamic content is accessible or provide alternative, if you can make main
page accessible then alternate.]

CLOSE with -   this is met with our current draft.

 


1175 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1175>  Level of
language is too abstract 

The guidelines are written in an academic (university-level) style. We still
found the guidelines difficult reading. [AWG]
Jargonesque terms such as "programmatically determined," "chosen baseline,"
and my favorite cringer, "delivery unit" stand out not as bastions of
clarity, but rather as arcane, obscure, and unfamiliar.

CLOSE with -   Most of this has now been eliminated.  Please review our
latest and make any suggestions for other words we can use

 


1222 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1222>
language-specific success criteria and checklist items 

There is a need for a criterion or criteria that address language-specific
issues.  For example, in Japanese some characters that look the same mean
different things in different context. Therefore, in a checklist, if someone
is writing Web content in Japanese they could have specific items to follow.

CLOSE with -   We don't have language specific techniques - but we have
included techniques that will allow language specific issues to be covered.
These include specific SC through advisory techniques.  

 

In a recent dialog with our Japanese representatives we were told that our
new guidelines now provided content for all of the issues they had wanted
included. 

 


1585 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1585>  include
best practices for user testing 

The document would be made even more useful if it could provide some advice
on best practices and recommendations for accessibility testing
methodologies with users, relating to the conformance criteria.

CLOSE with -  user testing is not a requirement of the guidelines.  It is an
excellent idea - but content that conforms to the guidelines will be
unusable to some.  And content that is usable to many may not pass the
guidelines due to issues for others.   Thus this type of best practice isn't
appropriate for the guidelines themselves.  Thus this is closed as a
guidelines issue.  But it is transferred to those creating supplementary
materials to consider since it is a good best practice. 

 


1591 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1591>
Programmatically determinable 

I suggest gathering into one place the 15 success criteria specifically
about making things programmatically determinable (identifiable, operable,
etc.). They are currently scattered throughout the document under Guidelines
1.3, 1.4, 2.4, 3.1, 3.2, and 4.2, and I think this makes it very difficult
for the reader to understand what they cover and how they relate to each
other...ideally complementing each other (with minimal overlap) to provide
all the capabilities needed by assistive technology. My first thought was to
move them all into a separate, new principle such as "Programmatically
expose structure, content, and functionality", but I realize that all the
success criteria relating to markup really fall into this category.     

CLOSE with -   This would not be a good method for organizing the doc and we
are avoiding alternate views of this type in the formal doc.  Members of the
group when looking at the glossary however routinely pull these together to
look at them.  We have no plans on publishing any of this interim work
product.  But it would be an interesting paper for someone interested in
publishing such an analysis. 

 

 


1755 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1755>  Editorial
comments for Nov 2005 draft 


This is a big long list of typos reported by many reviewers.  

CLOSE with -   Thanks.  Fixed.

 


1756 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1756>  Make
"principles"/"guidelines"/"success criteria" termino... 

Consider whether or not to substitute
"guidelines"/"checkpoints"/"provisions", respectively, for
"principles"/"guidelines"/"success criteria", in line with the precedent
established by UAAG 1.0. While the suggested terminology would be more
consistent with that used in other W3C/WAI guidelines, there may be some
advantage in using new terminology ("principles" and "success criteria") in
WCAG 2.0 if the roles of these concepts are considered sufficiently unique
that confusion can best be avoided by using terms different from those 
appearing in related guidelines.

CLOSE with -  WCAG 2.0 is structured differently and the old terms do not
fit well.  the guidelines for example can't be checkpoints. The SC would be
the closest to checkpoints and they are where provisions were in WCAG 1.0.
Also - using different terminology will help avoid confusion.  We also used
a different numbering scheme to help here.

 


1788 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1788>  Using WCAG
document should be normative 

The document states (correctly, IMHO) that it is essential, yet that it
will be developed as a Note - i.e. a non-normative document. It is
inappropriate to produce a Recommendation whose implementation relies on a
non-normative document, so it should be developed as part of the documents
which form the WCAG 2.0 Recommendation.

CLOSE with -  Assuming that this means Understanding WCAG 2.0 - it is very
common for a standard to have support document that are non-normative.
This is an interesting question and one we explored carefully. You do not
need Understanding WCAG 2.0 to use the guidelines - The guidelines set all
the criteria.  This was explored carefully with W3C leadership and found to
be the correct approach for these docs. 

 


1809 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1809>  Guidelines
must be clear and understandable without suppo... 

It is critical that to the utmost degree, the Success Criteria are able to
stand on their own, are clear, concise, easy to use, and speak to a wide
audience.  To the extent they can do these things, and to the extent they
exemplify with crystal clarity the current state of knowledge in forming the
basis of accessible design, to that extent they will continue to drive the
development of the new standards..   
(it then goes on to explain why - but does not make any specific
recommendations - in this issue report.  (These paragraphs were in fact part
of a preamble that was followed by many specific recommendation - all of
which we logged as separate issues.

CLOSE with -  This is a preamble to other issues that are handled
separately.  No specific recommendations are included here.  We are
endeavoring to make the guidelines doc as understandable in itself as we can
while maintaining accuracy and testability. 


1810 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1810>  Testability
should not compromise requirements 

While it is clearly desirable to have guidelines that can be tested, the
desire for testability should not 
come at the price of avoiding things that are difficult to test.  <snip>

CLOSE with -  The working group has determined that all of the success
criteria need to be testable for a number of reasons.  This is restrictive
but necessary.  We include advisory techniques that for those things that
are good practice but not testable. 


1814 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1814>  Does WCAG2
satisfy SC 3.1.5? 

Does the Working Group believe the 23 November 2005 Draft of the WCAG 2.0
conforms to Guideline 3.1.5? If not, I hope the "Understanding WCAG 2.0"
document is not considered adequate 'supplemental content'.

CLOSE with - A Daisy Book version of WCAG 2.0 is planned.  John Slatin has
already agreed to do this. 


1817 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1817>  Sign
language version should be provided for more than mu... 


 DUPLICATE OF 1818


1818 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1818>  Sign
language version should be provided for more than mu... 

We believe deaf people's accessibility problems are more complex than for
multimedia.  We believe you could do better. We suggest that you make a
criterion that says that web sites shall offer basic information about the
organization/website and information of central social interest in sign 
language interpreted versions on the website (national sign language). This
makes websites accessible to severely hearing-impaired or deaf people.

CLOSE with -  The guidelines require that all information be available in
text form.  This allows direct access by people who are deaf and who can
read.  In addition, in the future when text to sign language interpretation
is possible, it allows access to all information via assistive technology in
the same manner as people who are blind do.


1821 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1821>  responses
to "Understanding WCAG 2.0" issue 


WE POSED THE QUESTION : what do you think about Understanding WCAG 2.0.

ANSWERS

-          too long.   Access to all peoples is not achieved.  Esp 4.2.1  {
for reference - 4.2.1  If content does not meet all Level 1 success
criteria, then an alternate version is available from the same URI that does
meet all Level 1 success criteria.}

-          add a section on how to use the document

-          TOC is very long and not helpful.  Users want to jump straight to
techniques. 

-          Rename Situations to Techniques

CLOSE with -  The document is being broken up into individual pieces to make
it easier to get to content.  The introduction section will be expanded to
discuss sections and how to use.  The TOC is long because of the length of
the document and the number of success criteria.    Do not see how to avoid
this.  Any specific recommendations?   Cannot rename situations to technique
because we use the term techniques for the techniques. 


1822 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1822>  Provide
easy-to-read information for website navigation a... 

Offer basic information about the organization/website and information of
central social interest in easy- to-read versions on the website. This makes
websites accessible to people with a developmental disability or incipient
dementia. If you do not pay attention to people with developmental
disability (mentally retardation) we have to add this when we refer to WCAG
in our accessibility guidelines, which you can find under
http://www.tillganglig.se/start.asp?sida=1450

CLOSE with -  Success criterion 2.4.3
<http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060224/Overview.h
tml#navigation-mechanisms-mult-loc>  requires multiple ways to navigate and
3.1.5
<http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060224/Overview.h
tml#meaning-supplements>  requires that language be simple or supplemented.
We also have additional advisory techniques that are listed under each. 


1843 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1843>  address
relation between internationalization and accessi...              

It might be useful to (a) state the relation between accessibility and
internationalization somewhere in the specification, or (b) have several
examples of overlap between the two areas. If you decide for (b), we would
propose examples - and help with their creation - for the following
guidelines:  1.1, 2.1, 2.4

CLOSE with -  We currently only have benefits for people with disabilities.
We are considering adding a section on "side benefits" but there is no
decision on this yet. If we do we will include internationalization
benefits.    Examples would be always welcome if they relate to disability.
if we do the side benefits sections - they would also be useful in writing
that section.  


1853 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1853>  remove
confusing terms from success criteria 

The success criteria are accurately worded, but their understandability
leaves much to be desired.  In particular, the following terms are extremely
confusing and should be removed from the language used to define success
criteria:  authored unit, delivery unit, programmatically determined, analog
time-dependent input.

CLOSE with -   Please look at our current wording and definitions.
Delivery unit is gone. Authored unit is in one location and definition
improved. Other terms we could not change (tried very hard to change but
couldn't).  We have tried to define more clearly. 

 




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/lists/

The Player for my DSS sound file is at  <http://tinyurl.com/dho6b>
http://tinyurl.com/dho6b 

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