minutes from 17 January

In attendance:

WC:  Wendy Chisolm
PB:  Paul Bowman
AP:  Anushka Perkins
JW:  Jason White
GV:  Gregg Vanderheiden
LGR: Loretta Guarino Reid
GSW: Gian Sampson-Wild
LS:  Lisa Seeman
KHS: Katie Haritos-Shea

Action items:

WC: Investigate whether current user agents select style sheets based on 
media type
Assignments for preparing checkpoints:
	3.2 - JW
	3.3 - LS
	3.4 - WC
	4.1 - LGR
	4.2 - PB
	4.3 - KHS
	4.4 - GV

Discussion of Success Criteria

Checkpoint 3.2
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.

Received on Thursday, 17 January 2002 19:27:34 UTC