12 October 2000 WCAG WG telecon

Summary of action items and resolutions



Consolidating checkpoints 2.3-2.5

CMN Someone made a point that there are 2 requirements:

  1. have in markup the distinctions that are in the content - semantic objects are marked up as being different
  2. reflect those differences in style.

We should make it clear that "reflecting using style" alone is not enough. Not sure how explicit we need to be.

WC Those are separate checkpoints?

CMN definitely 2 checkpoints.

WC 3.1 and 3.2 are related to your point 2.

CMN 3.2 related to everything greater than 2.2.

WC So combine style aspect of 3.2 w/style of 2.3, 2.4, and 2.5

JW What's the proposal?

CMN Roughly: merge 2.3, 2.4, 2.5 and 3.2 into something that becomes 2 checkpoints:

WC Think 3.2 handles 2nd point. Who disagrees with this proposal?

WL Is there circularity?

JW Who disagrees? other alternative? write up and then vote?

WL Would like to see a concrete proposal.

ASW Also prefer that approach.

KB, CMN, GR agree.

JW In my e-mail I tried to explain the important elements in 2.3-2.5 and suggest that those elements be present in however it evolves.

Action JW: propose rewording of two checkpoints that combines ideas from 2.3-2.5 and 3.2.

6.4 and 6.1

JW 6.4 should be written as the second sentence as 6.1.

CMN sounds good.

Action JW: draft a checkpoint that combines 6.1 and 6.4.

Server-side proposal

JW If the content provider is creating the UI then it will fall under guideline 5, with the rest of the site it would fall under guideline w/navigation mechanisms. It would have to have accessible markup (guideline 2). Is there a separate requirement, if so where should it fit? If the UA provides the interface it becomes a UA issue. Do people think this case should be addressed specially? If so, where does it belong?

KHS It needs to be there otherwise people won't address it from the Web end, especially if not picked up on user end. I thought they were proposing 5.5.

CS In some sense covered by existing guidelines. Different than general navigation (nav bars, etc). Would probably put it with navigation, but don't think we discussed where it would go. This could be done w/client or server scripting. If you select one view you should be able to switch back.

KHS make that a note.

KB This is important other case. In effect you are not navigating something you are switching preferences. This may also apply to the case where if you change local settings, the UA should have a look at. Has anyone changed screen resolution in Windows? Pops up a dialog: if ok, hit ok. if don't it will revert back. It's easy to set something to a mode where you can't use. For example, switching between Flash and HTML versions: provide an escape button.

JW Anyone want to draft something to put it under guideline 4?

KHS Do we have a guideline for user preferences. Could Guideline 5 be design UI and preferences for device indie.

CS Except one preference could be to choose the device.

KB Sometimes we will find that x can go there, or y here, or z a special case of b. Ultimately, when we divide them up we are making an arbitrary distinction. We do this to help interpretation.

WC How link to UAAG? Try to do something like ATAG with relative priorities?

KB Can't push it all to UAAG: 1. circularity 2. You are designing a crude interface with Web pages. There is a place for UI discussions in our checkpoints that are separate from UA.

CS Dangerous to point people to UA. Thinking of "customization." If link to, developer will read "user agent! that's not what I do!" Preference settings occur in what we have defined as content.

JW CS, you have drafted the text, interested in writing explanation and propose where it should go?

Action: CS propose checkpoint for server-side generation.

JW We will work on the issues list and put some to the mailing list. Anything else people would like to discuss urgently before we conclude?


KB I would like to see in our agenda for next time "this is what we've done." i.e., the draft of cynthia's text. I'm concerned with actual productivity. For a while we have been making slow progress. We have not focused on specific goals.

JW Chairs are not in position to say, "this issue will be resolved at this meeting." Important on dynamic of the discussion. We can say we will discuss issues but can not say we will resolve. The customary practice of the group is to: discuss an issue on the list, then the next meeting we can discuss. If disagreement on list, then can tell it will be contentious. If none, it's likely there is agreement. If there are procedural changes that people should modify, then please mention on the list, or privately with chairs/staff contact. Process is not a static phenomenon.

Status of draft

WL What's the draft status?

JW We have one that was published 28 September. Not too many changes at the meeting. We have proposed that the changes we discussed today will be sent to the list. After next week, then we can prepare a new draft. Probably new draft after next week. Keep working on techniques as well. Should we decide if there is anyone who would like to work on other techniques? Take existing techniques and earlier draft of guidelines that had techniques and write up a checklist? Or rather propose HTML techniques to the mailing list.

WC Issue w/priorities. How inherit?

CMN Propose that we inherit the highest and clearly state what we're doing.

WC Who disagrees?


KB Should include "this is what they were" (as part of the mapping). Otherwise, do not add them in. We aren't at a state where anyone can use the document yet. We might give wrong impression.

JW Priorities should not be attached to checkpoints in next draft. Who really thinks priorities should be included in the next draft?

WL Possibility that some don't think it makes much difference.

WC KB makes a good point. Leaning that way. They are in the checkpoint map. We can deal with that later.

JW Agrees.

KB Additional suggestion: want to see that the draft lists after each checkpoint, "for each checkpoint, WCAG 1.0 checkpoint #'s (with links) and priority listing there". An inline reference. In addition to the checklist matrix. That would help people look at a proposed checkpoint.

WC AU produced new drafts every week. How do people feel about that?

WL, CS, KHS ok if the editor can handle.

KB Ok, unless major restructuring. Because then between versions have to refer to things as, "6.5 formally that was 5.4"

WL Not opposed with proposed text being dropped in.

GR Easier to grasp in context.

DB How do you mark what is new? under contention?

JW Regarding my action items on 2.3-2.5, 6.1 and 6.4, I'll work with WC to incorporate into the draft. Then we'll vote next week.

KB Like to see incremental changes, as long as have identifier thing.

Resolved: more incremental drafts a good thing. OK to put items in that do not have consensus.In future drafts, we will mark new text as "proposed" until consensus reached and then "new" for a couple drafts after that.

JW We'll have a draft next week, some more open issues, and changes to the draft.

WL This is a lot further along than you think it is. Lots of big changes in a short time.

JW Thanks everyone.

$Date: 2000/11/08 08:27:11 $ Wendy Chisholm