Re: GL 4.2 Issues Summary

Thank you for this Andi............:-)


-----Original Message-----
From: Andi Snow-Weaver <andisnow@us.ibm.com>
Sent: Oct 7, 2005 9:15 AM
To: public-wcag-teamc@w3.org
Subject: GL 4.2 Issues Summary



Since we are getting behind and Gregg is not happy, I thought I would try
to summarize the GL 4.2 issues before our next meeting. Hopefully, we can
go quicker this way. I'll try to do GL 1.3 too this weekend.

I won't be able to attend the call Monday as I am traveling. Unfortunately,
I can't do Tuesday or Wednesday either so go ahead without me.

426 [1]

I think this one is overcome by events. GL 4.2 has been totally rewritten.
The comments related to 4.2 in the list posting proposal don't apply to 4.2
anymore. We should not be addressing "process" in the guidelines. That's
something EO can do.

822 [2] and 1418 [6]

This is my issue. My concern is that subjective interpretations of
"Accessibility conventions of the markup or programming language (API's or
specific markup) are used." might lead to more implicit requirements. For
example, access keys which is not required at all by GL 2.1 and the lang
attribute on words which should only be rquired at level 2 per GL 3.1.
Haven't we provided enough specific success criteria in Level 1 of this
checkpoint so that we don't need this one anymore? I recommend deleting
this success criterion or moving it to Level 3.

971 [3]

The benefits section has become outdated now that GL 4.2 has been
rewritten. The second section doesn't apply at all because we no longer
have a success criterion about documenting the technologies you use. And
the issue of people not being able to afford to upgrade their AT is not
appropriate for this guideline. That is a baseline consideration but not a
benefit of GL 4.2. This checkpoint is really about compatibility with
assistive technology for the most part. In the spirit of "it's easier to be
critical than creative", here's a first pass. Comments please.

Providing accessible user interfaces or equivalent alternatives ensures
compatibility with assistive technology used by users with disabilities
such as screen readers, screen magnifiers, and speech recognition software.
Allowing users a keyboard method of exiting non-accessible content ensures
that usres with disabilities will not get trapped in content that is not
perceivable or operable by them. And ensuring that users can avoid
flickering or flashing content that might induce seizures is a critical
safety consideration even in non-conforming content.

972 [4] and 1536 [7]

Says we shouldn't encourage separate sites for accessibility. I think WCAG
2.0 itself will help discourage separate sites because it is technology
neutral. Technology owners will be encouraged to enable their technologies
for accessibility reducing the need for separate sites. Greg Gay suggests
rewording the success criteria to "If content cannot be authored to meet
all level 1 success criteria, then an alternate form is provided that does
meet all level 1 success criteria." But "cannot be authored to meet" is
more diffecult to determine than "does not meet". Also, there may be cases
where it makes more business sense to provide a separate site. For example,
for an existing inaccessible site, a separate accessible site might be
provided as a stop gap measure until the site is redesigned for
accessibility.

1050 [5]

Pass. This one is about the wording of the principle itself. Not about GL
4.2.

1537 [8]

Questions whether it is possible to determine the role, state, and value of
HTML elements. I think it is when they are used as they were intended to
be. The issue for HTML is when HTML elements such as <div> are repurposed
using JavaScript, CSS, DHTML, etc. to create interactive GUI-like
applications. This is exactly why Rich developed the standards for
assigning a "role" to XHTML elements like <div>. I recommend closing this
issue.

1713 [9]

Not applicable if my proposal above (issue 971) for rewriting the benefits
section is accepted.

1714 [10]

Says there should be a level 2 requirement on the use of relative measures.
Joe Clark objects. I believe the issue is the specification of the use of
relative measures. This is a technique, not an outcome. The outcome we want
is for users to be able to enlarge the fonts if they need to. We could
propose a new Level 2 success criteria that requires text to be resizable
without specifying how this is done. Authors would then be free to use
relative sizes, provide alternative views themselves through different
style sheets, or invent some other way. Here's a proposal that describes
the outcome without specifying how it is done. I have one question though.
Is this the right place for this or should it go under 1.3? It's about
perceivability isn't it? Again, feel free to be critical.

The user can increase the size of text content.

[1] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=426
[2] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=822
[3] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=971
[4] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=972
[5] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1050
[6] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1418
[7] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1536
[8] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1537

Andi
andisnow@us.ibm.com
IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo

Received on Friday, 7 October 2005 14:15:57 UTC