WC I'm behind on the list, what is the gist of the comments that Sean made?
WL Use of classes.
JW Use of markup is 2.3.
WL You have to identify that you are using style elements as pseudo elements for structure. e.g., use "sale" as class in style sheet, the only way to get the semantics out of it is to look at css.
JW That is an issue, but it comes under 2.3. Using markup correctly. 3.2 is using presentation properly.
WL Yes, 2.3 is related. There is an easy interpretation that 3.2 should say, "when using styles" it should further delineate that styles that are used must be revealed as being structural.
WC Suggesting a specific tie back to 2.3?
WL Yes.
WC Will depend on how 2 (all of it) gets reworded. I see a lot of overlap.
JW They are parallel but different.
WL This is design for comprehension, that's why you're doing it here. It reemphasizes that one. 2.3 is great. Color, styles, and graphics: perhaps find something that is general. Those apply so specifically to visual tricks, we might think of what this is in general.
JW Appropriate styles for the medium, then include examples for different mediums. Then there would be a link to 2.2 which discusses styles for the particular medium. 3.2 would specify in greater detail what is required.
WL In addition, 3.1 style is used in a different context. Doesn't have anything to do with style sheets, but rather "style" in artistic sense.
Action WC: make sure the word "style" is used consistently.
Action WC: Add examples to 3.2
DB 3.2 is more or less new? It is a requirement or an alternative?
WL We haven't put priorities on it yet. Likely in the priority 2 or 3 neighborhood.
JW Reasonably controversial, but facilitates comprehension. Certain amount of criticism of 1.0 that it did not adequately emphasize the high quality of presentation. This checkpoint tries to address that in a more explicit way.
DB style here means markup style, right.
WL Yes.
DB In 2.3 we're talking about markup. so this is a repeat?
JW Markup is not style.
DB Why not say style sheet?
JW Doesn't have to be a style sheet. SVG doesn't necessarily use style sheets. PDF doesn't use style sheets. Both use styling as well as structure. Requirement is independent of how it is implemented.
WL Headers are designed by academics. Browser took those and arbitrarily assigned style characteristics to them. We're saying "add decoration to the structure so that people can better see it."
JW Default rendering might be enough, but might not. In which case they will want to add other presentational elements to enable effective communication. Issues? or may we move on.
WL Instead of "use color, etc." make more general. e.g., "Emphasize logical structure of the content." and put rest in examples.
DB Still concerned about specifics. I don't understand "graphics." How do you use those for the structure of the document.
WL In addition to having default header element, that you put a picture next to the H1.
DB I think that is unrealistic. People look at that as visual clutter. It adds to the download time.
WL The question is whether that something that gives you choices and still has a priority, the priority is that you make the choice not pick one thing that you have to do.
DB We're now starting to say that you need to use a graphic to communicate the info in different ways.
JW I don't think that's present in the checkpoint.
DB With the example of graphics, how is it not.
JW Graphics present info or content, they don't necessarily present the structure. Do we have a checkpoint to use graphics to convey meaning?
WL WHat about using "or" rather than "and." "Emphasize logical structure of the content." then right under, it says, "if the default presentation of the structural element is not adequate to the task of the audience then the introduction graphics, colors, sounds, etc. to emphasize structure is recommended."
DB Gives people more of a choice.
JW Provide appropriate styles or presentations to emphasize the structure of the content, then there could be examples and explanation of how to do it. No requirements that any approach be taken. Default presentation could satisfy.
WL What we're trying to nudge authors to do is to be aware of default renderings, and it if is adequate for their purpose.
JW recognizing there are some that do not have default renderings.
WL True, but the user agent may have a default rendering.
JW Yes, in HTML, but not in an arbitrary XML language. Therefore, rewrite this so that it depends on default rendering.
WC Good to incorporate but not apply to every case.
Action WC: rewrite 3.2 to take into account suggestions from today's call.
WL The way JW wrote it made sense to me.
JW I had some private comments saying that they liked the rewrite.
4.3 Give users control of mechanisms that can interfere with their ability to navigate, or which require content to be read or responded to within a limited period of time.
WC concerns about the wording. Would like to simplify or to divide into 2.
DB agree. Have major concerns with what it means.
JW Gets rid of until user agent clause.
DB But it is not clear. We don't say which user agent to use as a base line.
JW If the user agents support it then the author doesn't have to. We're discussing "baseline capabilities" on the list. It provides guidance.
DB I disagree, unless we know that user agents are supporting it then we are requiring authors to do it.
CS We used to say authors should not use automatic refresh. Now we say, you can but you have to be ware.
DB If I'm a content developer, how do i know to author in a way that gives user ability.
CS Today, no one supports it.
DB We're trying to soften it in the note. If the user agent does it, you don't have to worry about it. But if someone does it next year we're not going to say only design for this browser.
WL We're clearly moving the "until user agent" to a different level. Question of whether it should be anywhere is not arguable. At some point, we have to say we no longer support Mosaic.
DB That's fine. I understand that this is an issue we have to deal with elsewhere.
/* discussion about UAAG requirements for stopping refresh */
CS There are 3 ways to satisfy the checkpoint:
Today, only 1 and 3 are possible, and at some point in the future #2 is hopeful or likely.
WL It's still important enough to write as a thing to do.
WC "Give users control of timed mechanisms that may interfere with navigation, comprehension, or interaction...?."
JW One checkpoint or 2?
WC I do think we can combine them, but "timed mechanism" is too jargony.
JW There are aspects that are not "timed" however.
WC Timed mechanisms and extreme changes in context.
WL I'm still troubled by guideline 6 itself. That's why I'm trying to get everything out of it. "capabilities of user agents" bothers me. 6 seems parallel to others.
CS 6.2 is a special case of timed mechanisms.
WC Boil down 4.3, 6.2, and 6.3 to timed mechanisms and extreme changes in context?
JW blinking has a bit different rationale.
CS Then 6.1 be part of 5, device independence.
WL Yes. The "user" is a device could gain credence.
CS Netscape 3 and a cell phone are both devices.
JW Very strange definition.
WL When we talk about device independence.
JW Guidelines 2, 3 and 4 are output and 5 is input.
CS We may run into that confusion more and more. There is emerging jargon in industry that device is browser, PDA, etc.
JW Or a cell phone.
CS From an author's perspective, a crummy browser and a cell phone browser are similar creatures. Many think of those as writing for device independence.
WL I have less objection to guideline 5 than 6. As I understand JW, forcing 6 into 4 and 5 has to do with notion of device.
JW And the importance of compatibility with software that includes user agents, and assistive technologies.
WL How do you reconcile "capabilities of user agents" with getting rid of "until user agents."
JW Somebody who developed content which they believed would not be compatible with UA's and would fail to satisfy under that guideline, that the UUA detail of determining if something is implemented in a UA is in the technique. but someone who carries it through inappropriately has to fail to conform to something. what they would fail to conform to is under 6.
DB I think 6.1 is part of the larger issue. It is very broad. I don't understand it. It seems to say the same thing.
WL DB and I are agreeing. The newer technologies being turned off means ... not supported, seems to be very broad. CSS2 is essentially not supported. CSS1 is barely supported. X* is essentially not supported. At some point they will be somewhat supported. This is the "until" department. We will have to supply a when. "Now" this is a requirement b/c we passed the "when."
DB WHat is "newer" versus "older." I don't think 6.1 should be a checkpoint or come across in broader concept.
JW What would people fail to conform to if they didn't take it into account. I'm thinking of mapping between 1.0 and 2.0.
DB "newer technology" does that mean features of a browser, or something that we can't imagine now?
CS Flash? TAbles? at one point, tables were a new technology.
JW Obviously relative to what is implemented in the field. That's the kind of relativity that comes here. We need a more detailed discussion.
WL In a certain sense, we have decided that guideline 6 requires quite a bit more discussion than what we have time for today.
/* agreement */
JW Part of that discussion will end up in the techniques for each of the specific points. This is based on a checkpoint from WCAG 1.0.
WL One improvement might be to leave something out. It needs to be clear when one has conformed to the checkpoint. The idea of "newer" is too vague.
JW There has to be a checkpoint somewhere that one would fail if they did not act appropriately in the area.
WC Guideline 6 from 1.0 is where this checkpoint comes from. Stating a fact that in 1.0 we had a checkpoint that said scripts need to degrade gracefully, that is only represented by checkpoint 6.1 in 2.0. Nowhere else in 2.0 are applets and other programmatic objects covered. Therefore, we can't get rid of it, but it is the wording of a guideline in 1.0 that covered several checkpoint. Perhaps a way to make it less encompassing.
CS We're talking about graceful degradation. Can't we define it immediately afterwards? with examples?
WC Yes, like text equivalent and auditory description.
JW 6.1 is the only place where this requirement from 1.0 is mapped into 2.0. We need to add some criteria.
CS Graceful degradation is something people usually learn in month 9.
WC Then reword it as 1.1, use graceful degradation?
WL If you rewrite 6.1, then incumbent on that is a rewrite of guideline 6.
JW What you should take into account when deciding which technologies to use. There is a proposal that could fall into guideline 6, as a clarification.
WL If something is already written out, and it gets included in the next couple of weeks we can discuss it.
JW If WC working on 6, then incorporate that. Can that fit logically under the rewrite. Referred to in the agenda for this meeting. CMN has been talking about it for a while.
Action WC: Rewrite 6 to incorporate today's discussion.
Action WC: See if place for CMN/JW proposal about deciding which technologies to use. Perhaps as clarification to 6.
WL To get into queue for potential agendas or issues list, i want to deal with the notion of having checkpoints or guidelines dealing with indexing. The first phase is to implement a claim of conformance statement. It is part of accessibility process that the who, when and affirmation of conformance is included.
CS RDF stuff?
WL How it gets implemented is not as important as that there be indexing.
CS Related, encrypted certificates that say "this is certified to be safe." May be interesting to look at a certification for conformance. Don't know how realistic.
JW CMN has written a program that lets you make a checkpoint by checkpoint claim.
WC CS is talking about a certification body.
CS Or that the claim is digitally signed and unforgeable.
WC Don't know about certifying sites, but some are trying to certify people as developers.
JW Came up in a conference yesterday. There is skepticism. 3rd parties should be allowed to make assertions about content or developers. Then to verify the assertion you could look up trusted parties of your choice. If they confirm the assertion you could have more confidence in the assertion.
CS Even just adding a digital signature would help.
WC Related idea, ER is discussing a checkpoint that requires testing. Recently, I've been working on a checklist that includes the checkpoint as well as the automatic and manual checks.
JW Both manual and automatic checks are important. Would it be good to include it under each technique.
WL My intention to do that in my x-checker. At the end of each checkpoint I link to the appropriate techniques, guidelines, and a few cases to tools.
WC See that the in the technique-specifics for 2.0 we have checklists and within the checklists have tests. Algorithms for humans, and where possible tools can then automate.
ASW That's how the IBM checklists already are. We get feedback that people want one place to get tests. They don't like the format. They have to go through each checkpoint to figure out how to plan their tests. One place for knowing what tools to use.
WL There are lots of skeleton keys to the guidelines available. What i've implemented in x-checker. The checkpoint has a link at the end of it to each technique documents, to the specific point in the technique document. It is an easy way to get to the specific section.
Resolved: on the agenda for future meetings/open issues:
Resolved: No meeting next week.
Resolved: New draft next week.
$Date: 2000/11/16 22:53:12 $ Wendy Chisholm