[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.
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.
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/11/08 08:27:10 $ Wendy Chisholm