Hewlett-Packard Web Accessibility Team Review of WCAG 2.0

Hello WCAG working group:

Thanks for this opportunity to again comment on WCAG 2.0.  I was happy
to see that many of my comments from last time had been addressed.  Here
are my comments on the 30 June 2005 draft.

VALID CONTENT:
I support the inclusion of HTML validity as priority 1.  I agree that
HTML validation is too often ignored by page developers.  I do not agree
with the statement that "it is too difficult to validate code".  If an
HTML page is that difficult to correct, it ought to be rewritten!  Most
pages only contain a few validation errors which could easily be fixed
if the developer took the time to validate them.  Stating that some
validation errors are ok is copping out -- delivering the message that
conformance to HTML syntax criteria is not important.  If some of the
syntax rules are not important, maybe we should change the syntax rules
to include only what is important.

2 OR 3 LEVELS:
Having two levels instead of three would simplify things for people who
would otherwise be overwhelmed by the volume of the guidelines. Give
people the most important considerations, and don't distract them with
the lower priority ones.  
As for removing the level 3 items, I would advocate keeping this
knowledge somewhere that people can still see it if they are interested.
I would not just throw it away.
What about having another document in the document set, that contains
what we currently know as the level 3 items, and calling it something
else, like "more stuff you can do to be more accessible if you want"?
GUIDELINE 1.2:
I would advocate keeping the transcript requirement at level 1 and
moving the caption requirement to level 2.  Often it is beyond
budget/schedule/skillset/feasibility to provide captions, but a
transcript is readily available.  It would be good to encourage people
to satisfy level 1 rather than give up entirely.
Likewise, I would move audio descriptions to level 2.

GUIDELINE 2.1:
Please provide examples of functionality that can be described in a
sentence, and examples of functionality that can not be described in a
sentence.  I.e.,  you state that this success criterion applies to
functionality  "where the functionality or its outcome can be described
in a sentence".  I don't understand why you include that clause.  Is
there a reason for it? If so, show me examples of things that fall
inside and things that fall outside of that spec.  If there is no reason
for having that clause, (if such examples can not be provided) then
please delete it.

GUIDELINE 2.4:
Please provide informative guidelines on how to satisfy the Level 1
success criterion.  It's not clear to me how programs should determine
navigational elements.  Should a program be able distinguish the
navigational controls/menus on a page from just links that are embedded
in the content?

GUIDELINE 3.2
Same comment as for guideline 2.4 -- It's not clear how a change of
context would be programmatically determined.

This page
http://www.w3.org/TR/2005/WD-WCAG20-GENERAL-20050630/guideline1.2.html
Gives me an XML error and can not be displayed in IE.

------------------------------------
Melinda Stelzer
Program Manager
HP Web Technical Standards
melinda@hp.com
562-856-0408

Received on Wednesday, 20 July 2005 10:46:24 UTC