Minutes from 20 july WCAG telecon

Here's what I got down today. I know I missed some discussion (of which
there was plenty), but I hope I got most. Please send corrections, etc. And
I'm assuming Wendy can post to the site.
 
Dick Brown
 
 
 
20 July 2000 WCAG WG Telecon
 
Summary of action items and resolutions
 
In progress:
Action Marshall: send e-mail to DB re: how MSN creates pages for mobile
devices. DB has forwarded to MSN Mobile team and is awaiting response.
Action KHS and WC take screen shots for CSS doc.  KHS sent screen shots to
WC.
 
Resolved:
Send techniques document out ASAP.
 
Participants
Katie Haritos-Shea
Charles McCathieNevile
Jason White
Dick Brown
Andi Snow-Weaver
Marti McCuller 
Marshall Jansen
William Loughborough
Marja-Riitta Koivunen
Gregg Vanderheiden
Regrets
Gregory Rosmaita
Wendy Chisholm
 
Agenda
Action items (brief review).
Guidelines: further discussion of the draft that was submitted last week. It
needs to be developed and improved. Concrete proposals are welcome. Is this
the direction in which the guidelines should be moving?
Techniques document: review by interest group and status of changes approved
during last week's meeting.
Any additional issues or concerns which are raised on the mailing list prior
to the meeting.
 
JW: Let's change agenda to discuss techniques first.
 
Consensus to send techniques doc ASAP.
 
JW: Will ask Danielle about whether it is still an issue. (DB: In taking
minutes I didn't get what the issue is.)
 
ASW: Is it our intent to prioritize and guidelines level or checkpoint
level?
 
JW: Largely still an open question. I suspect solution lies in concretizing
and improving general principles and guidelines first.
 
JW: At the checkpoint level it's technology-specific.
 
CMN: I'd like to suggest we use guideline-checkpoint mapping we use in WCAG
1, rather than what we call in WCAG 2, principles.
 
JW: I should explain that my choice of terminology was based upon some
confusion which has surrounded the term checkpoint in the past 6 months or
so. That there's been a tendency to speak in terms of technology-specific
checkpoints. I thought to reserve checkpoint for tech-specific, and use
principles and guidelines for higher-level. I think there's a real
terminological problem here.
 
WL: The idea is that there are going to be two levels of non-tech sp stuff,
one of which is either called principles or guidelines, the other called
guidelines or checkpoints. There would be a third level above all of those
(which is now) called principles. We will work on the third level no matter
what we call it.
 
JW: We can leave that (the terminology) as an issue for subsequent
discussions. 
 
JW: There's been discussion on the list about the principles and guidelines.
 
BL: I want to re-propose that the language of the principles is included
somewhere where that can be dealt with without having to look at anything
else.
 
KHS: People were talking about the White House Site. There is a table there
that is just that kind of stuff.
 
JW: One issue is that the exact number of these top-level requirements and
their substance is partly a matter of convenience, because it would be quite
possible to reduce it down to one or two, but that would lose its
explanatory value. But we don't want to have too many of them.
 
WL: But that they ultimately will have subheadings, etc. need not concern us
at this time. The important thing is to make sure the general points
encompass everything we want.
 
KHS: It's useful to have four things you can count on your fingers. They do
have to be put broadly.
 
JW: Use a very small number of new terms precisely, terms that would be
defined in the document.
 
JW: To move to the concrete: We've had some debate about #1, regarding
modality independence. Some healthy discussion on the list.
 
WL: I'll put mine up: There's four. I dropped two and tersified all of them:
 
From WL mail to list:
Separate content and structure from presentation; capture semantics with
markup.
Permit user modifications of default presentations.
Design user interfaces for device independence.
Assure content availability across sensory modalities.
 
MM: Each one of them should be followed by a paragraph of explanation.
 
JW: #2 doesn't mandate that the author provide a default presentation.
 
DB: There may not be a default presentation 2 years from now.
 
JW: Need to pay attention to one or more of the ways a UA could present it.
Provide some kind of style sheet, whatever, the markup language requires so
it can be presented
 
WL: The distinction between the author and whoever puts up a Web site is
going to be blurred. The idea of a default presentation is very close to
nonexistent.
 
DB: In the ideal XML world, there would be a big stream of data going to
devices that present it per user desires.
 
JW: (For the foreseeable future) There will be an attempt by the creator of
the information to present the data in one or more sensory modalities.
 
MJ: Big sites make it look like marketing wants it, then there's small site
owners who use FrontPage or DreamWeaver are going to make it look good on
their computer and there won't be a big data stream.
 
WL: No, but 90 percent of the Web development may.
 
MM: We also have the situation of the govt who has the idea that forms must
look exactly like they are supposed to and aren't going to give that up.
 
CMN: They already have to deal with the fact that doesn't work in the real
world.
 
WL: Currently a PR war between two US presidential candidates about having
made their sites accessible.
 
JW: Content needs to be provided in a format that can be rendered by user
agents. Or, provider of the content also has to provide the infrastructure
(style sheets, etc.) that allow presentations to be constructed at the
client end.
 
WL: What if I say "if any" after default.
 
CMN: I think we're talking about author-supplied (data). Needs to be subject
to user override.
 
JW: I suggested changing default presentations to default presentations.
 
JW: Is it appropriate to just suggest data with some markup and require user
agent (to format, etc.).
 
CMN: Instances where you don't need to supply along with your content any
rendering information. (DB: not sure if I minuted this correctly.)
 
Consensus: "Permit user modifications of author-supplied presentations, if
any."
 
JW: Then the text would have to explain the circumstance under which author
would have to supply presentations or it wouldn't be presented at the other
end.
 
JW: We seem to have agreed on modality independence.
 
WL: There is a 4th domain: navigation. It's not the structure of the content
or the presentation. Navigation is a separate concept.
 
JW: (In the draft I wrote) I actually put navigation and comprehension
together.
 
WL: The reason I dropped comprehension, simplify, etc... I think that's too
general.
 
(GV joined)
 
WL: Were discussing navigation be added to the triumvirate of content,
structure and presentation.
 
WL: Navigation can be completely separate and imposed, like a site map.
 
MM: Probably be more so with Web phones and Palm pilots and such.
 
GV: Some of these things are orthogonal, not parallel. The way you structure
a document is how you navigate it, in some respects.
 
WL. One of the things I mean is that there are bits put into Web sites, that
are navigational entities, that are unrelated semantically to the content.
 
MRK: So the site navigation?
 
JW: Does navigation need separate general guidelines?
 
WL: Probably not.
 
MRK: I think navigation is really important.
 
MM: If you can't get to the page, it doesn't matter how it's presented.
 
GV: The problem we're trying to address it that when you use presentation to
indicate content, or use it to indicate structure, or use it to identify
navigation, you create a problem for people who cannot perceive that
presentation. Perhaps better worded: Do not use presentation to convey
semantics meaning, to indicate structure or to identify navigation. Use
proper markup, not presentation.
 
JW: The question is whether there are requirements for navigation or whether
they should be understood as consequences of the requirements for proper
presentation and content.
 
CMN: The structure needs to be specific, everything else can derive from
that.
 
CMN: So links and navigation elements are part of the structure of a page.
So the cons of separating presentation from structure... UA can then say,
these things are neatly separated... so make available what has been
separated out. Linking is just one of those.
 
JW: Web allows links to be created in and between resources. So to that
degree, one could be justified in speaking of link requirements as separate.
Or they could be part of separating content from presentation.
 
WL: I agree... there does not need to be a separate reference to navigation.
It's already covered (under structure).
 
(MJ left call.)
 
JW: (Citing his proposal about separating presentation from content.)
 
GV: You don't want any semantic distinctions to be distinguished via
presentation...
 
MRK: ...alone.
 
JW: Structure and semantic distinctions must be conveyed in markup or data
model or whatever. Presentation alone should not be used to communicate
signify structure.
 
GV: Need good phrasing for all this.
 
GV: The content and structure should be derivable from unformatted text and
markup (or data structure). So the focus is from unformatted text and markup
you get all the information you need.
 
The call was adjourned after the group agreed to pursue wording for these
issues on the list.