Agenda, Previous meeting minutes
reminder: if you want to participate via IRC during the telecon refer to the note I sent in July.
JW Proposals:
one from WC, one from GO.
What should be the defining characteristics that fall in the minimum set. Want to start out general to gather criteria then go back to checkpoints to determine if some are included or not. A 2 step process.
CS Support behind idea of testability and practicality as part of it.
WC tries to explain proposal.
GO Problem w/heuristics and semantics.
WC explains heuristics and semantics and tools. @@
JW Could be derived.
GSW Could be problematic, browsers react to content differently. It might be specifying a preferred browser.
JW That's what people who implement ensure presentation is consistent?
GSW If we organize checkpoints on what the author can specify, IE and NS deal w/style sheet differently. One rule says content displays correctly, would not be same across IE and NS.
WC @@
GSW Not display differently, but not at all. e.g., NS we're going to use CSS, when open in NS layed out one after another rather than how wanted to display. Content there.
WC Likely using absolute positioning. This way author must provide structure and semantics. Then a graceful transormation can occur.
GV When talk about separate content from presentation, what if a technology where can't be done. Does that mean that if you use where not possible, then
WC Gets into final form questions....
GO If I am developing content designed solely for mobile pohnes, and using that specific language, then things are different than if trying to serve more than one device.
WC If designing something only for one format, always inaccessible. Never have any caveats.
CS Not if you know that your audience only has that, e.g. an intranet.
GV Not talking about that - talking about something that can only be presented visually or something. Really important point. Many of our rules are things to do if you have one form of the info. A viable alternative would be that instead have something in pure audio, pure video, etc. But would anyone want to do that? Either create materials that will transform into various forms or provide in various forms. If one is text, that will transform. Add a caveat checkpoint (all else fails) or a tree at the top as WC suggested.
GO Going 2 ways (decision tree) seems complex. Secondly, if someone is writing for a phone and can only be accessed visually would have thought that we don't want anything to do w/it.
GV If someone is writing something can not be transformed, then don't need to worry about our guidelines.
WC intersection DIWG - author creates device independent but serves device dependent. Need to make sure that what is served is accessible. Could be great for someone who is blind to use a VoiceXML app, but someone w/a learning disability to use the full-blown desktop multimedia version.
GV Server-side solutions are acceptable (this is a consensus point). Would this conform?
JW Right, need to make sure we get this right. Would like to get away from it. What is the more general issue. What must be provided by the author versus what could be implied by a user tool. Seems to be an interesting way to draw the boundary.
CS I like it conceptually, but what happens when the software gets better, do we change the min. requirements?
GV What is machine-perceivable vs that which is not. If whatever it is is machine-processable, either AT would do or create a piece of AT that could change into a form they could deal with. That raises the issue of today or tomorrow. WC's language moved up a layer of abstraction. If the info is derivable, an AT can work to get around. Test: is the info there or not there, machines can't make it appear. Unless, machine can look at picture and describe, then future WCAG may not require any sound be captioned since machines are so good.
JW Write it in such a way that it would assume current technology or reasonably foreseeable. Not assume any fundamental advances in AI.
CS My concern is to pull away from current available technology. Make lifetime shorter.
GO This is a fine line, tech avail. in near future, page authors - we must show the why. Why they need to do something. My experience that that is one of the weakest areas that needs work. One danger of including guidelines in the min set that have min practical benefit w/current tech it undermines the guidelines. They don't see benefit of following. Going to WC's point of providing strong structure, using H1, H2, etc. The only piece of AT that uses those is HomePage REader. JAWs users not aware of functionality that does this. I'm not saying the idea is bad, but warning sign that it's a weakness of WCAG 1.0 - the lack of rationale. Must be a demonstrable need for the guideline.
JW But don't want to limit to current technology. If we were to go down path suggested by WC, only be revisions of recognition technology that would change the min. set.
CS Don't know that it would, but we should keep it in mind. We need to keep in mind the lifespan.
GV We don't want to assume something is accessible as soon as someone develops a technology. When 2.0 comes out, do we want to say that the min things to do are the following...not including some items b/c someday in the future...On the other hand, don't want to anchor to one point in time. Don't know how to address it. What is possible for people to do, what is possible for a consumer to do in terms of reading it. Possible would have to be both for authors to do as well as for users to do - on the day we release them.
GO I think the solution to that problem - technology that we think is on the horizon but not there yet. Flag the guideline in a special group - just outside minimum group - recognize to go into min once tech is available.
GV As technology advances, the min. should get smaller.
GO talking about 2 issues. e.g., strong structure. currently no pieces of ATs that can make use of pieces of markup. But say we are aware that JAWs is about to introduce it. We flag that as, "as soon as this becomes mainstream, this goes into the min. set."
WC Amaya, Opera, etc. support this. The benefit exists for other people...
GO Bad example.
GV Yes, but I understand your point now.
WC Believe this gets into the technology-specifics. The requirement still exists, but how you fulfill is based on what supported for the tech today.
GV Can we still have conformance at this level, but depending on technology go to criteria.
WC Not sure. 2 audiences, one may be non-technical: policy-makers, evaluators, disability advocates, etc.one may be very technical: developers. Becomes complex, but could be helpful.
GV Around the table.
GSW Problematics - it will become techonlogy-specific.P3 - tables. Tech has improved, thus priority improved. Not in minimum set, not used by a lot of people, may get forgotten. If we concentrate on technologies we get away from the basic premise. Many are exceptions - if your browser doesn't support images, then do this.
AP I like WC's proposal. My original thought was to go through user groups and cover as many people. It looks like it covers what I want to cover under user groups, but a better definition.
CS Like it conceptually but concerned about how workable it is.
LGR Missing some context, not sure.
JW Idea is that the min. set should be defined as including those requirements that must be satisfied by author that a tool can't satisfy itself. e.g. semantics and content that must be provided by author but not auto generated.
GSW Example where author provides this info b/c tools don't render properly.
WC Goes through some checkpoints that might be in minimum versus those that might be secondary.
GV Discussion isn't about these checkpoints and how they would sort, but what do people think of the rule in general.
GO Are you trying to make a distiction between the author of content and the developer?
WC Focusing on end result, whether it comes from author or developer, looking at characteristics of what gets shipped to the user.
GV One thing - the min the author knows or can provide, 2ndary derived from tool. If we want to have a good dichotomy, they should be compliments of each other. The 1st is min set that the author knows and cannot be derived, 2nd could be derived. The 2nd should be "derived by tool or the user." Some things a tool can't do but that the user can.
WC Like that, yes, "can be derived."
Action GSW: write a proposal based on user groups. something that is also simple. takes into GO's point that about being usable today.
JW In general, there is a policy in the way the guidelines are structured such that if something can be handled by software and is going to be handled by software, it can't be a requirement in our guidelines except at a provisional level. There are strong objections from content developers. Also ours must relate to ATAG and UAAG. Therefore problematic to include a requirement that would become obsolete, unless we go back to something like the Until user agent clause.
GV GO had posted 9 items. Interested if people look at those and say "Yes, no, don't know, or something." to see where we are on things.
Action everyone: go through GO's 9 items and respond, "yes, no, don't know, or ...."
GV We did say that the minimum set had to be normative items, right?
CS, JW yes.
Action JW Try to formulate WC's idea as a statement of distinction.
GV If proposals could be proposed with a name so that we can refer to them.
WC Track on home page?
WC Quickly goes through draft Timeline. Says Rec by July/August, but October/November of next year is probably more likely. Please send comments. If want to help edit CSS techs, please let me know.
GV change to "initial conformance scheme proposals" since we've got that. Says public draft next month - have a lot to do with success criteria before next draft.
CS Could work on at breakout sessions at F2F?
JW Improving the success criteria so they meet the requirements we have set out for them: testable, reliable, etc.
Action everyone: Go through the draft timeline. Please comment, question, and suggest changes, additions, etc.
$Date: 2001/10/25 21:43:29 $ Wendy Chisholm