

FW: WCAG minutes 11 May 2000

From: Dick Brown <dickb@microsoft.com>
Date: Wed, 17 May 2000 16:44:40 -0700
Message-ID: <7D6F5C23B8944046BC8D1DDED0ED15E01D817F@red-pt-02.redmond.corp.microsoft.com>
To: w3c-wai-gl@w3.org
Sorry for the delay, but here are the minutes for the WCAG meeting of 11 May
2000. The other three folks who attended: please correct and amplify as

11 May 2000 WCAG WG telecon
Marti McCuller
Gregg Vanderheiden
Jason White 
Dick Brown

GV: (General statements about ways to reorganize the guidelines). But if we
completely restructure the way we think about everything, you run the risk
of putting out a set of guidelines that looks so different from what we
turned out last time that everyone says, "Huh? - how are we ever going to
comply if you keep redefining truth?" so we need to be careful as to how we
proceed. I am feeling we shouldn't be trying to develop it all over again
even if that may be optimum. But now like many companies we need to live
with our legacy.
JW: I think we need to avoid that (complete restructuring) as much as
GV: If we generalize it too much we will get a lot of backlash. We would
have created a nice academic document. The guidelines will have nothing
concrete. If you only have a checklist of what you should achieve, you can
never check it off. If we make the guidelines very generic and functional,
not technology specific, and we don't include what is sufficient to satisfy
this, it will (generate) somewhat of a backlash. The solution may be to list
the generic (guidelines) and then list checkpoints by technology.
JW: There's another way of doing it. That is to make it not by technology
but by types of features that occur in markup and style languages, without
necessarily drawing too heavily on particularly markup and style languages.
MM: When people look at the guidelines now, they say, "Could you say that
again in English?"
DB: I don't think it's a problem with not being in (plain) English. The real
need is to be able to sort differently.
GV: For those who can handle the language and really understand Web
technology, it isn't a problem. The problem is, they are being used by grade
school teachers, (etc.).
GV: So this is a good point to mention some of the things we've been talking
about. For instance, here are the basic guidelines, and there are only about
10. But then if you do a more complicated site, here are some of the things
you need to do, and it has a number of "if" statements. Then if you are
using advanced technologies (scripts, etc.), here are things to know.
GV: The other thing is having a sheet with top priority items, then a sheet
with Pri 2, then Pri 3.

GV: The problem we are having is that if we don't (produce more simple,
clearer guidelines), someone else will. (Listed others doing different
versions of the guidelines.)
JW: (If there is) any checklist that is an aid to interpretation of the
guidelines document and would not be a normative part but an informative aid
to the guidelines itself, then it would still be the guidelines themselves
that would be the definitive version (for judging compliance).
JW: We need to pay even more attention to exactness in the next version of
the guidelines.
JW: We're starting to see how MM formats and graphics formats... can support
accessibility. What the requirements are for these kind of formats to allow
the creation of accessible documents. To that extent we have some material
from which to generalize that isn't necessarily tied to sections on specific
formats but nonetheless captures the accessibility requirements for
particular kinds of content. I think it's increasingly possible to
generalize across the content or technology employed without being directly
dependent on the current features of any makeup language, style language,
etc. You could express checkpoints which would be applicable to a range of
technologies. We should see how far we can take that idea as we reformulate
the guidelines.
JW: I put out a few examples of (rewritten) checkpoints a few weeks ago on
the list, but it didn't get much reaction.
GV: One of the things we're seeing increasingly in the working group, we are
in areas where it takes a lot of thinking. A lot of people are trying to
handle the GL list when they have a few minutes. People are going to drop
off in their ability to respond to difficult questions. (Conference call)
discussions may be a little easier because people tend to speak up.
DB: Not sure we can do both simpler version and updated version.
GV: I think we have to both, with emphasis on the latter. But (the former)
shouldn't take too much horsepower from the group, other than reviewing it.
JW: I agree with Gregg, we need to (focus on) new technologies and a more
generic approach.
JW: It's been suggested that the Authoring Tool guidelines are a good
example of a (generic approach).
(missed some comments here)
JW: We're working internally to see how to move the requirements document
forward. It probably will undergo review by other working groups, and the
issues that have been raised will be addressed before it is published.
Anyone who has comments on the review document should offer them soon.
JW. Two areas where we need techniques: Math and document object model.
That's an issue that needs to be held until we have more people on hand.
Received on Wednesday, 17 May 2000 19:45:35 GMT
