JW: Success criterion 3 seems similar to those for checkpoint 3.1
GV: 3.1 says similar things should look similar. 3.2 says different things should look different
JW: Success criterion 2 starts with "if appropriate"
GV: Danytime the condition of a conditional success criteria is not clear/objective, the success criteria itself goes below the line
WC: is there another way to phrase this one?
GV: What about combining criteria 1 and 3, since they go together. Except 3 starts "where possible"
PB: Do we really mean to create a unique style, or can we depend upon the browser's default style?
GV: Maybe it should say "there is a unique style for each structural element"
PB: But not every browser is a visual browser. A non-visual browser may not provide any style.
JW: My non-visual browser applies CSS to create the speech style for every element. That kind of technology exists. #3 is tryin to take advantage of that. If you combine 1 and 3, you could say that if the style is defined by default by the user agent, this is taken care of. If it is necessary to customize, the author must take the action to do that.
PB: Consider a horizontal rule - there is a consistent way to render it in a visual browser. What does emacs-speak do
JW: It has a beep for it
PB: Then we can leave it to the default presentation of the browser
WC: But that will only work for HTML
JW: There are two circumstances where the author must provide the style
1) you are using a format that has structure elements not support
by user agents
2) you want or need to customize the presentation for some media
type to create a desired type of presentation.
The checkpoint seems like we are mostly concerned with 1).
AP: How would you go about defining a style for braille output for HTML?
JW: Use CSS
AP: What elements do you put in the style for braille
JW: Mostly margins and page layout, like centering
AP: Not specific for a structure type, but to the page?
JW: No, specific to structural elements. Braille output is similar to print in that notions of layout are relevant, but space conservation is very important. So you can control placement within the bounds of the page.
PB: About having multiple style sheets for the same page: most such sites employ server-side scripting, which requires expertise of the site maintainer. This is a step up in sophistication compared to some other techniques.
JW: The user agent should select appropriate style sheet for its media type
PB: Do any current browsers do this? (WC takes action to investigate)
JW: Can also provide XSL style sheet somewhere along the chain from server to User Agent
GV: In HTML, this success criterion is almost not necessary since it is done automatically. In other technologies, it isn't clear that it is doable.
JW: XML-based languages can do this. And in these cases, it is more important to do it. Maybe we should add a qualifier that if the document structure is in some way unusual, requiring specialized presentation, then the author should provide style. Using components of a markup language not supported by default is another reason to provide style.
WC: If you provided the appropriate structure, this checkpoint is something you can achieve, e.g., provide a different style for each element.
JW: Are we confusing whether this should be required and whether the success criteria are testable, clear, accurate, etc. We shouldn't really be discussing whether this will be required.
WC: The first criterion is testable
GV: Can we develop an alternate wording?
JW: that combines 1 and 3 "a unique style is provided"
WC: "is applied" => testable
JW: This is a requirement or constraint on the presentation produced, rather than whether it is provided by the style sheet, user agent, etc
GV: "Each structural element has a unique style."
PB: Consider addin the phrase "either by the developer or the default settings of the browser
GSW: Maybe in the techniques
GV: or add "(provided or default)"
WC: This is confusing. Whose default? author's? UA's? Let's leave it off
GV: "Each structural element has a unique style, either provided by the author or by user agent default processing."
GV: But we don't know what the user agent is?
GSW: We are supposed to make sure that the content works, independent of the user agent
GV: What if it would be defined in all the common UAs, but you use one whereit isn't
GSW: But isn't that what we are running into already?
GV: this is addressed to the page author. So "Each Structure ELement has a unique style." If author doesn't provide sytle, he has no idea what will happen?
PB: This goes back to my original question. Is the author required to provide a style for every element, even though most UAs will provide a default style
WC: In XML, they will have to
JW: Where it is a mark-up language well supported by UA, defaults are probably provided. But if you are using unusal elements or mark-up, you need to provide style
WC: Paragraphs get used for lots of purposes; we want to encourage authors to customize them further
GV: That is helpful. But are we requiring it?
WC: This checkpoint is more than just providing structure. It is emphasizing structure. This is specially needed in HTML, which has such a limited number of elements you can use
WC: In the techniques, HTML will be treated differently from XML. A heading in HTML is probably ok, but heading4 and bold text may be too easily confused.
GV: Each structural element has a unique style provided.
GV: This doesn't seem like it is going to be objective, no matter how we write it. We'll get to the point where people will have a hard time telling how different is different enough.
GV: Should we put the "variety of media" criterion with criterion 1? Does it have a caveat?
GSW: We need to decide whether criterion 3 is above the line. We shouldn't combine 1 and 3 if they are categorized differently
JW: 3 is more testable
GSW: Except for the "where possible" (Request to decide which are above the line)
GV: I've never seen a case where criterion 1 isn't satisfied. I suspect criterion 1 will always be true visually.
JW: What about Wendy's point that customization is required
WC: Ideally, text itself can transform to all devices.
LS: How would we specify to provide lots of headings?
WC: That comes from Checkpoint 1.8: Use structure. So you can't do this one unless you have provided structure appropriately.
LS: Not so sure. You can structure things well without providing as many headings as might be useful
WC: 1.8 says to use headers correctly. This says use styles to show the differences between headings
LS: More headers aid easy scanning.
JW: The provision for providing the right structure for the content is different from what we are covering with 3.2. Can we leave that issue aside for the moment?
PB: I was confusing providing structure from emphasizing the structure that is provided. I agree with you that when you provide style, you should define it for all media types. (that is, we should combine 1 and 3)
GV: If we have structure, unless 3 is above the line, then all 3 are goin to be below the line because it is not clear what it means to be unique. Wendy says the purpose is that they be differentiable. Criterion 2 won't really label everything because sometimes the label is already there. Maybe the entire checkpoint is trying to say go beyond strucutre. It is advice for how to make things more usable.
WC: So is the implication that this entire checkpoint is below the line? We suggest this for people who have trouble reading
GC: Structure isn't just for people who have trouble reading. Structure speeds up finding things. It helps people see the organization of document
WC: It helps understanding, in a variety of ways. Isn't this required for some people?
GV: Yes, but there is nothing below any line that isn't important for some people. Everyone is on a continuum. The example of the 1 in 12 wheel chair ramp excludes some people. We are using the line to divide those things which are measurable.
WC: It is testable to find whether styles are defined, and for each media type. Criterion 2 may not be testable. We need to define when things need labels.
JW: We could add an extra success criteria that says the styles are sufficiently distinct. This could be below the line and the existing ones could be above the line. Then we just need to decide whether criterion 2 could be made testable.
GV: If the success criteria are that it should have a label and a different style, then the checkpoint should say this. The current checkpoint is much broader. If we want to keep broader checkpoint, maybe we need more items below the line. Isn't video a media type?
WC: The media types are: aural, braille, embossed, handheld, print, projection, screen, tty, tv
GV: How would I create a style sheet for the Trace Home Page for television? Is this WebTV?
WC: WebTV produces guidelines for how to produce web pages for TV. handheld - Voice XML and speech synthesis, can use aural style sheets.
GV: When I think about providing one for each media type - if we include all those media type, we should put it below the line
WC: We are using the line both for testing and conformance. This sounds like a conformance thing.
GV: It can't be above the line if it can't be tested. But it can also go below the line if we don't recommend something for every site.
WC: We need to create clear rules about how we are deciding whether something is for every site.
GV: Things above the line make the site good enough, below the line optimize things. The question Wendy raises is a good one. We have been trying to get through section 3 and maybe 4 before we decide where to draw theh line, so we have lots under our belt. Let's not try to sort above and below the line on this pass. I'm worried that we won't make it through section 3 by the end of the month.
WC: Can we assign checkpoints to people to decide wether criteria are testable? So we will be better prepared.
LS: I tried to do that for 3.3
JW: I'll draft something for 3.2
AP: 3.5
GV: 3.4 has no success criteria
JW: it is such a controversial checkpoint.
WC: I'll take 3.4
PB: 4.2
LGR: 4.1
KHS: 4.3
GV: 4.4
WC: Focus on whether the success criteria is testable. If not, is there a way to redo things so it is testable. Can you recommend what tests should be done. Think about the checkpoint and whether there are more success criteria we should provide
GV: Don't worry about whether new success criteria are testable, since we want to provide as much advice as possible
JW: The are several axes we've been working towards - testability, completeness, and accuracy
AP: Don't worry about conformance.
JW: Decide whether success criterion is necessary to meet checpoint. Don't decide whether this will be required of all authors
WC: By Tuesday, try to post info for checkpoint we are likely to reach on Thursday. The more we do on the list, the more progress we can make at the meeting.