Minutes from 7 Sept. 2000 telecon

http://www.w3.org/WAI/GL/2000/09/07-minutes.html

07 September 2000 WCAG WG telecon

Summary of action items and resolutions
·       Action: WC add to open issues list: do we need to add specific 
language to guidelines that say that metadata is text equivalent for 
non-text equivalent.
·       Action: everyone take a stab at suggesting simpler language

Participants
·       Jason White
·       William Loughborough
·       Wendy Chisholm
·       Lisa Seeman
·       Marshall Jansen
·       Loretta Guarino Reid
·       Katie Haritos-Shea
·       Cynthia Shelley
·       Andi Snow-Weaver
·       Dick Brown
·       Kynn Bartlett
·       Gregg Vanderheiden

Agenda
·       Principle 1
·       Principle 2
·       Principle 3
·       Principle 4
·       Others

Principle 1 - explicitly mention metadata?
[From the agenda: Does guideline 1.1 need to be clarified specifically to 
include metadata? Can it too easily be misconstrued as excluding it, given 
the historical usage surrounding the term "text equivalent" in WCAG 1.0? 
Current wording: "1.1 Provide a textual equivalent for every non-text 
(auditory or graphical) component or multimedia presentation." Do you favor 
Andi's suggested restatement of the guidelines under Principle 1...]
JW Is metadata explicitly included or excluded?
WL Is metadata different from text?
JW There have been previous discussions w/SVG where you could provide 
metadata not in itself be a paragraph of text or a textual presentation but 
it would specify the relationships.
WL There is metadata that is not text?
JW Yes, text but it has more than text in it. Is there metadata not in a 
markup language not represented textually? CAn be but not the point. It can 
specify relationships between elements as well as text or embedded within 
an image file and not in the markup language. My concern is we need to make 
it clear as to what counts as a text equivalent.
WL I don't think you can make it clear. I don't think it's a problem.
JW Other reactions?
CS What is the problem?
JW Interpreting the guideline.
WL Vote to put on back burner.
Action: WC add to open issues list: do we need to add specific language to 
guidelines that say that metadata is text equivalent for non-text equivalent.
WL At this time will not add specific language to guidelines that say that 
metadata is text equivalent for non-text equivalent.

Principle 1 - andi's rewrite
WC Should consider other suggestions that have come in, such as those from 
Al and William. I also sent some just before the meeting.
GV Characteristics or principles. Principle would be, "Do this or don't do 
this." rather than a characteristic, "it has this."
JW WC raised things that characterized requirements in relation to outreach 
and the role they should play in the framework. Andi had proposed 
reformulation of the guidelines under 1 and William had written a draft 
introduction to accompany principle 2. Both are trying to make the text 
comprehensible.
KHS My action item was to have different people look at this. Web person, 
marketing, or management. When those folks come to the page they need, 
"policy makers go here." Something that can be printed out and in 
generalized terms. Web masters need something more specific and you don't 
have to get so broad. Almost separating into principles, guidelines, and 
checkpoints.
LS I made a piece of software once that required same info at different 
levels. Even if you went to the wrong place, you would end up where you 
should be.
KHS From a manager, I heard "having a link is great, except when you go to 
print it out." Lots of people will print and then look at. I went to search 
engines and w3c was link on most of those sites, but they were to the WAI 
or W3C, it needs to open up on our page not the main W3C site. University 
of Ohio linked right to WCAG 1.0.
JW The WAI website is not under our control that needs to be discussed with 
EO. The question we are trying to decide is what kind of materials and 
explanations should be provided in the text of the guidelines (the 
normative document) we are responsible to publish.
WL Before we get too deep in explanatory materials, I want to get back to 
something Gregg said in our first meeting. It's the source for all of that. 
It's not something that you read casually.
GV Yes, that was the original intent. But events have overtaken us. People 
say you must follow these guidelines they don't say you must follow the 
book that interprets them. What we're finding is that people are using the 
guidelines and trying to fix their web page. Some go to the techniques 
document. Also, people who bounce off of them because they are too complex 
make up their own list. They throw away those that they don't understand, 
rewrite to be less accurate, and never look at ours again.
CS Isn't that the same thing w/all of the W3C specs? A lot of people run a 
validation tool and never look at the spec.
GV But people are being legally held. We don't want to end up with a 
proliferation of standards. Einstein quote: "Everything should be as simple 
as possible but no simpler."
CS It seems there is a lot of overlap between HTML specs and our docs.
GV But many in our audience never look at the HTML spec.
LS Once you've understood the principles you understand the checkpoints.
JW But those who can read HTML spec can read our doc.
KB But, people will be expected to read WCAG but not expected to read HTML 
spec.
CS By taking exactness out of guidelines making less usable by those who 
can read specs.
WC Still want something like XML in 10 points. In March, we agreed on a 
short overview, a guidelines document, technology-specific tests, etc. 
We're still talking about those things discussion hasn't changed.
GV Overview won't help those who don't read technology specs. The card is 
wonderful but it is nothing more than simplifying what is in the guidelines.
LS PEople don't use it since they don't know how to implement it.
GV It does get used but, we need something more thorough.
DB People think "that's all I have to do." It's too simplified.
GV Yet extremely powerful to decrease fear.
CS It's better than doing nothing.
WL The arcane, holy grail should be there and we should work on it. We 
don't have to concern ourselves with what we've written as long as we can 
understand then we can tell them what it means.
GV Can't do that if that's the only one that people will conform to.
CS There are a lot of people who need the arcane knowledge.
GV That's fine, that's the technical reference manual behind the guidelines.
JW No, the technical reference is what is needed.
GV Currently the techniques document is informative.
JW The Guidelines are the reference, the only thing that is cited. 
Techniques is explanatory and examples.
GV I said technical reference not normative or informative.
JW The guidelines are the precise accurate specification.
KB Precise and accurate does not negate making it easy to understand. I 
realize that we have differing opinions on our core audience, but this is 
part of our problem. In the real world, the core audience is numerically 
larger and looking at more than the more technical audience. People don't 
say, "refer to Kynn's site." they say, "look at WCAG." As long as they do, 
they will be reading this specification. We need to make it readable and 
not just say they can read a translated version or they are not really 
supposed to read the technical version.
JW Can anyone propose a rewrite which would achieve that? Is it possible?
KB I don't see the dichotomy. I think simpler language will make it easier 
to express what is meant.
WL If there is a proposal that does that, we can deal with it. So far I 
have not seen that.
GV We are more in agreement than we think. What we need is something 
technically accurate. If we can do that simply that would be better than 
arcane terms. The conflict is that some people believe we will sacrifice 
accuracy for simplicity.
KHS Perhaps we don't worry about the length of the document as long as 
people can find what they need. It doesn't have to be short, it has to be 
extremely understandable. It shouldn't have to be read from beginning to end.
GV Judy and the steering committee have said that if we want to have a long 
document, we also need to create the short version.
KHS You have different audiences. That makes sense. The definitive 
reference needs all of the information.
LS The terminology can avoid the problem, "I have my checkpoint list." 
instead of calling it a summary, "introduction to..." Then they know they 
haven't got every detail.
JW Summary of issues and progress. We have a large measure of agreement. An 
introduction to the concepts is something I've been thinking about. Much of 
the difficulty is a conceptual one. Certain ideas, like textual equivalent, 
semantics, etc., need explanation. WL proposed a explanation of distinction 
of structure and semantics. It could be used in an introduction. We could 
write an explanatory text that is reasonably short that explain underyling 
concepts. The the guidelines provide the technical detail. 
Technology-specific components are in checklists. This is one possible 
format. WC proposed something that we haven't had a chance to read. We can 
then progress and avoid dealing in abstract but looking at concrete proposals.
KHS We don't have to reinvent the wheel. The fact sheet, getting started, etc.
WL Those don't cover the specific concepts.
WC /* reads from characteristics and principles */
GV Good that we take several stabs at what the high level principles should 
be. We have goals and principles. Principle: separate structure and 
presentation. Goal is to ... Let's put goals up front followed by 
principles. Might be easier to sell.
JW One of the great features of the 1.0 guidelines, are the rationales 
provided for the guidelines. There are other items on the agenda related to 
the principles we've been working on.
KHS I like them Wendy. The one thing that summarizes them is "removing 
barriers to information."
GV That is the essence. That is what accessible means. What does that tell 
you? Accessible web content is removed barriers.
KHS It is redundant.
GV "easy to navigate" are characteristics. These are the ones that will 
help us. If you design it accessibility it will be easy to navigate does 
not tell you how to do it. But it lays out the results.
WL Everyone has to take a knife and stick it in if we're going to slay Caesar.
KB Do we have specific feedback from people using the 1.0 version. I have 
not seen a summary of what's wrong.
WL We had a huge thread about how long it was.
WC Have gone through archives of IG and wai to find patterns of questions. 
Many myths exist. Lots of questions about HTML specifics.
LS I could guinea pig it on the class I am teaching.
CS really interesting data. But, don't want to go far in the direction of 
beginners. I think most people will know HTML. We have to be aware that 
most of audience is technical.
WL We are probably unaware that people that many people will take one look 
and not comment.
GV We are dealing with technology, we can't make it non-technical. Those 
who want to simplify need to make suggestions.
LS We have 2 pieces of homework: rewrite less technically without losing 
anything and come up with principles.
GV Those are related. Principles in understandable language will make 
everything else that follows.

The old Principle 3
JW I had an action item to try to rework the document. I ran into some 
problems in doing that. Those are the underlying basis of some of the 
issues on our agenda today. One of my action items was to determine what in 
principle 3 needed to be reintroduced.
/* scribed missed some discussion */
JW Not sure how to reformulate a general principle to cover. The original 
principle 3 failed to cover: if you design a markup language, you need to 
write one or more style sheets to convert it to something that the UA can 
process. If we can talk about PDF, there is a similar requirement regarding 
character encoding. We have problem relating coding in which info is 
expressed in what the UA can process.
LS A filter?
KHS A communication device.
JW Can take many forms. I could write an auditory style sheet in a new 
language. In PDF the mechanisms are there.
LS A filter. When people work on various markup language can write filter 
to change from one to another.
KHS Doesn't that fit under principle 5 - compensate for older technologies.
LG Is there complete information and where it comes from? Do things need to 
be provided to UAs that are more dynamic today?
JW That's the problem, it didn't arise with HTML but with the newer 
technologies. It's always existed with font encodings but that's a 
different matter.
LG When I think of XML and definitions that need to be provided for each use.
WC Assuming that including guidelines for new languages. Kynn has suggested 
that we keep them separate.
CS How do we apply more general guidelines to emerging guidelines. 
Therefore, perhaps a third prong. Like, sever-rendering. In WCAG 1.0 there 
are techniques that I have used that I believe are accessible that do not 
conform to WCAG. Since WCAG 1.0 is HTML specific. That's a third thing, 
people who are creating new technologies, people using new technologies, 
people using accepted technologies.
JW I read an announcement somewhere that there are graphical tools to allow 
people to create their own markup language w/out knowing XML syntax. With 
XHTML and related technologies, it will be easy to introduce new elements 
and meanings. Therefore difference between content creator and language 
creator will blur. What I'm talking about can apply to people not even 
writing own languages. But, if you are using an encoding of some sort and a 
probability that the software at the other end will process it, it will 
need infrastructure.
WC Don't see how that differs from device independence (principle 4).
CS For language creators, need to be able to support alt-text.
JW Question not of device independence but of software.
LS Add an extra bullet, "when writing a new language, do x y z" under each 
guideline. Then people see as a recurring theme.
KHS OR move to principle 6.
ASW There is an XML Accessibility draft.
WC Incorporating those into the technology-specifics. Refer to current 
draft for 1.1.
LS If we promote XML accessibility now, then when people start making XML 
Protocols, they'll be more likely to do it on the right foot. Most people 
are beginning to look into XML.
MJ I disagree, many people despise XML and XHTML it's just more to learn 
and HTML provides all that they need.
LS They might not want it, but know that is moving towards.
CS Depends on how you define web developer.
WL There are still more COBOL programmers than C programmers.
MJ HTML won't go away.
KHS As long as XML is coming, cover it.
LS I'm not saying we shouldn't make the situation better with HTML, but 
there will be a segment moving to XML and we have an opportunity to 
position ourselves to do things right the first time without having to put 
out fires.
JW Good discussion but no resolution on the question I was raising.
Action: everyone take a stab at suggesting simpler language.

$Date: 2000/09/07 21:43:31 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Thursday, 7 September 2000 17:44:48 UTC