Published to the list 12 September 2000.
JW Proposals?
KHS We need to decide if plain language is applicable to what we're doing. If so, then we need to decide how many documents we need and who the audience is.
LS The Recommendation should be based on the current document and the other material should be supplementary. The "10 points" and "guide to the guidelines" is something different. One document is "the guidelines" and maybe a few others that introduce them. Think we agreed last time that we need a complete, clear recommendation.
GV When you say, "a document" in the past we have discussed that the doc may consist of a few pieces. e.g., guidelines followed by technology-specific checkpoints.
LS Yes, those would be included in it.
CMN To make a W3C Recommendation we need a doc that is a technical spec that can stand on its own. It can't rely on any document that has less standing. it can rely on another recommendation but can not rely on a Note. You must be able to say, "this is the requirement." Yes, introductory material is good. Like what EO has produced, the Quicktips. Not the spec but a reminder. They must be be written as clearly as possible, to be useful and to meet WCAG.
GV We want a document which can consist of multiple parts and all normative. It is written in straightforward language. All by itself it should define the requirements to someone skilled in the art. We might create introductory materials to help someone who is less skilled in the art.
DB What is the process? Editorial with group review or is the group going to be contributing. A group will have a harder time to write. I worry that the group can produce a document with so many voices.
GV The W3C model is that you have a WG with editors. Today the editors are staff and non-staff. They write the document and the group helps to shape it and review it.
DB I agree with this approach, sounds like most of energy will be towards creating something that is easier for people who are using it. If we are considering a change in view as priority we need to make sure people understand that. How much time will we spend on writing new checkpoints?
CMN Our primary responsibility is to make sure we have the right checkpoints. The group who make the alternative views is the EO WG. We should review their work. They rely on their work.
GV From the steering committee:
We should make the base document as easy to understand as possible. however, we need to focus on complete. If we want to make it easier to understand, editors and wordsmiths can do this. I would hate to see the whole group getting lost in making something easier to understand.
CMN We have a direct responsibility to make sure that the guidelines are easy to understand. I agree with your assessment of responsibilities.
KHS It needs to be user friendly. Things must be technically correct. That doesn't stop us from linking to the easier documents.
LG Is there a proposal for a new document? Currently we have overview, technical, etc.
GV We are talking about making this version easier to understand. Once finish let's determine the need for an easier to read version. The overview or introduction is a summary. But if we have an "intro and background" might be something we add once we're done. it would contain info we think you need to understand the rest. last time, we stuck all of that into the document. perhaps move off to an introduction (problems, issues, etc.)
LS What about the "10 points to WCAG." Doesn't say technically anything but explains the orientation and why it's here.
GV Introductory.
CMN EO is ultimately responsible for. They could use our expertise. That's way past our scope. There's a limit to how much we can do.
GV In that case, we could create an introduction that lists topics and snippets with what should go there.
WC Most of that work is almost done. Send what we have to EO? Think it will help us write the more technical in a clear way. Our charter says that EO will advise us in writing, not that they will write.
KHS We definitely need a summary.
JW Our primary responsibility is to write the technical specification. I'm happy to take our boundaries to the EO to determine whether joint work is desirable.
WC I propose that WL, KHS, and LS write a summary, send to WG for review send to EO.
WL We need to focus on WCAG 2.0.
CMN I would like to encourage those people to take some of their work to EO.
WC But it is in our charter. (EO WG charter, WCAG WG charter)
JW Then the charter is wrong.
GV Let's stay away from definitive claims. Perhaps we should take this to Judy. It is really up to her to decide. I think it is premature to summarize before we have the content.
LS Regardless, the three of us have to do the work. Which group are we doing it for? Either way, it's not detracting from the group.
WL Yes, because in this meeting alone we've spent 1/2 of the time discussing it. We need to move ahead with work on WCAG 2.0.
GV On the WCAG home page, could you gather links to the 3 intro pieces so that people can look at them? Then, once they are easy to find, we move forward with the main content. I also heard that we want a document that consists of the generic plus the technology specifics. I'll call it a "compound" document. It would be normative. The intro or an overview would not be part of the normative.
WL An intro should be normative.
CMN Think we can be agnostic for now. What we're really talking about is individuals doing their work. What we focus on in this discussion is, what will we spend our teleconference time working on. I'm hearing, "getting the technical specification right."
GV It's a good idea to stay agnostic on the intro. Perhaps then the "core technical piece" could be shorter. That may help people who say, "the doc is too long." Can be more concise since less roles.
JW CMN is right. The intro has to be a joint EO/WCAG activity. I'm happy to take up any administrative issues.
GV You're saying it needs to go to CG?
WL For example, the curriculum was not done in WCAG WG.
JW Another controversy: there will be technology-specific checklists. The question is, should they be normative or informative?
CMN Let's leave the division of the fish until we have the fish. Let's get all the info on the table then decide what table to put it on.
WL agree.
JW agree.
KHS What you are saying is that we won't come up with a technology-specific document until we have the checkpoints done.
JW No, well write the guidelines and technology-specific checkpoints, but not decide which is normative or not.
Resolved: We won't decide what pieces are normative or informative until we have all of the pieces available.
Resolved: We spend the majority of teleconference time on getting the technical specification as clear and accurate as possible, but recognize that a less-technical introduction will be written once the technical specification is finished.
MM As long as the technology-specific parts will be revisited and written in structurally "agnostic" as possible, then I'll shut up until that comes along.
WL The changes are always being made to them.
JW Let's get the technical content right and decide the other issues later.
WL Do we have 4 or 5 principles?
JW That's the sort of issue we need to spend our time on.
/* Current draft was sent by Jason 9 September 2000. */
Action: Wendy link to the HTML version of Jason't latest draft is published on the W3C and linked to prominently on the page.
JW Any other points that people would like to raise?
LS Bidirectional is a problem. Someone has asked me what they should do. What should I tell them? Two types to design page:
WC What about content negotiation?
LS They will use traffic.
JW In current draft, multiple versions might be necessary to deal with backwards compatibility.
LS The reason it is called "bidi" is that, e..g, some numbers may go one way while others go another. Those have to be tagged to give the assistive technologies a chance to make sense of it.
JW The HTML bidi elements and attributes would have to be used correctly.
LS I think Principle 3 is 2 principles mushed into one: 1. Design of ease of browsing and navigation and 2. Design for ease of comprehension.
JW They are separate issues but the solutions are similar, e.g. consistency of navigation help comprehension. If we want to divide them more sharply, it's possible.
WL That principle has 10 under it while the others have only a handful.
LS What makes the principle structure is that I have one principle in mind and then give examples. Here, I have many principles (ideas) to keep in mind as I go through the examples.
JW If we split, which guidelines go with which principle?
LS Other things to add, "use color to emphasize structure."
LG Also true of icons.
Action LS: Propose how to separate principle 3 into multiple principles.
CMN The way that JW expressed it, "ensure that every structure is reflected in presentation" captures it.
LS There should be a place that expresses this. Particularly important for people with learning disabilities. Color helps people with ADD skim a document.
WL It is covered by 3.1.
LS No. It's a precursor.
WL That's "consistent usage of specs."
CMN No. Divide it into 2.
JW 3.1 is trying to address the second part - make sure that's what in markup is in presentation. It could use elaborating to make sure it is clear it means font, color, etc.
WL The last sentence covers this.
LS My problem is not that it is not implied, my problem is that you could read through that and not do what i'm talking about.
WL That's a perpetual problem.
Action LS rewrite 3.1 to clearly express the need that color is needed to emphasize structure.
GV I am concerned about 1.1. Will "tactually" cause people to "get bent." We also talk about text and synchronizing text. The "descriptions of video" are usually not text but audio. I didn't see anything about audio equivalents.
JW That was omitted until we work out how we will deal with it. It is an interim measure.
GV In 3 we say <principle> then <note>. this is the only place where the text is easy to understand. if the text is in a database then doesn't matter. Will we break this into 2, these apply and the following don't.
CMN You don't need to make the exception case. Anything w/out a user interface is not web content. These principles apply to the user interface. where it comes from is not relevant. when presented to the user, this is what it must be.
GV Not talking about where it derived it from, but pure data being given to the user agent.
CMN Splitting hairs that don't split. XML is database content. You provide the content and style sheet.
JW Thanks for raising that issue.
JW Under section 4: it makes too many assumption about separate user interface controls. Will it become easier to derive multiple user interfaces from the source, how reflected under section 4?
LS We ought to look into XForms a bit more.
CMN In looking at user interfaces, look at WML. It has a slightly different model. The UI design is much stronger than HTML.
Action WC add the issues raised during this meeting to the issues list (as well as documenting the resolutions).
CMN Also, want to add my issue about nomenclature.
LS People with hyperactivity get distracted with motion in banners and animations.
WC In WCAG says, "avoid or allow user to stop."
ASW But that's the point.
LS Not if they can't read the rest of the site.
MM It is the case, they do want to distract you from the content.
JW This in UAAG.
CMN Yes.
WL I would like to say it's great to get back to talking about what we're supposed to be talking about.
$Date: 2000/11/08 08:27:10 $ Wendy Chisholm