This discussion is based on theBig issues. 19 Sept 2001 - Gregg Vanderheidene-mail list of issues raised at the 10/11 Sept F2F meetings.
GV Only posted the 3 documents yesterday. Since not enough time to review, perhaps leave discussion until next week. Are there other big issues we can generate? Perhaps we can put some of them to bed. Anne said that it didn't seem like a number of the big issues were addressed by the consensus items.
JW We need to reach the point where we can draft a conformance and priority scheme.
GV As I look at the list of issues..."what is an equivalent" is #4. Can we sort out those that deal with conformance and priorities and go for those first? As I look at them, they all seem to relate to priorities. I would like to start at the top and walk down the list to see if we have a nomination for something to work from. OR is there a question to answer before we tackle - i.e. a work item to tackle before moving forward.
KHS Baseline capabilities.
LGR Would like Cynthia here for this discussion.
JW Baseline tightly coupled with technology-specifics.
LGR Content developer needs to know what is reasonable to assume. then someone assumes "latest and greatest" then ok as long as they say that?
JW That's one position they could adopt. Would not be good for interoperability.
GV The consensus statement is: Techniques should specifiy if particular browsers are needed.
JW Or particular support for a particular standard. e.g. CSS2 vs CSS1.
GV Another stab, "Techniques should specifiy if particular browsers are needed or specify particular technologies. e.g. you must have CSS2 support for this technique."
JW Yes, gives people choice how far back they want to take backwards compatibility.
GV If a company says, "i have to work back to Netscape Communicator 2", they can't use CSS, etc.
JW Unless they transform gracefully.
GV They can't depend on CSS for default presentation. We used to have an assumption that if accessible via lYnx that is good.
JM I don't think anyone is saying "we want the site to support NS2" but lynx seems reasonable. This brings us back to Cynthia's original question (re: client-side scripting).
GV Her question is, "accessible as long as support client-side scripting." or can't you assume scripting?
JM I don't want to put words into her mouth, but we have not made a statement about if site should work with javascript off, or unsupported.
JW Could be asked for SVG, SMIL, etc. We're plannig techniques for all of those. Therefore, content developer have to make a choice whether to support or not based on how inclusive they want to be.
GV Do we think that pages should be accessible with browser that do not support scripting?
JM If the decision is that we won't make a decision and give them techniques for them to make their choices, we need to state that explicitly.
GV If we leave it to the dev, we have made a decision. Implies, requiring scripts is ok.
WC We might want to do some research.
JW I think that devs should be aware of the consequences of either option. If require them, there are a variety of UAs that won't support them or turne doff for security. Therefore, limiting audience in some way. I'm a bit worried about mobile devices which don't have many resources.
WC WAPScript. Need to do some research.
GV Then deciding all users must support scripting in their browser.
WC Raman's client-side proxy that will interpret client-side scripts.
JW Then this issue will disappear for certain types of issues. Still issue with if we want to impose that assumption across technologies. Make decisions about when or not people will use.
JM What type of research, Wendy?
WC Similar to survey sent out about a year ago, but sent to wider audience, perhaps ask help from organizations in disability community. Also needs to bedesigned to get feedback from non-technical, e.g. test page and ask for results.
JW Can't have in normative, since changing all the time.
WC "until user agents", although bain of existence for 1.0, was helpful in that it separated those things that authors had to do forever, from those that they wouldn' thave to do once user agents or other types of clients support. This distinction is helpful, although not sure how to address.
GV If write for the future, today some pages will be inaccessible. Perhaps we should do that. Let's argue the point to discuss. I'm not convinced myself. No matter what we do with the guidelines, some people will not be able to things. If we write with until user agents, it gets complicated: who decides when true? instead if we say, "these do not desribe everything you can do to make accessible" put in the techniques. In techniques say, "you can use scripts, and call pages accessible, but there are some people who won't be able to use it." Here are more things you can do...it will be more straightforward than until user agents. We can say, "this is a reasonable set" and people should program pages to it and assistive tech and user agents should build to it. Things will get more accessible over time.
JW With our guidelines as they stand we don't need to address the issue there since the guidelines are not technology-specific. The techniques are and that's where the problem is dealt with. There are different ways of doing it. What I had in mind, was to state the assumptions on each technique as to what support it required. PRovide informative info elsewhere. Keep that info up to date.
GV Technology-specific checkpoints are normative, techniques are informative. Put in techniques and are all right.
JW Yes, thought we had decided that long ago.
GV This works if people use all three pieces. The only hitch, is that some people are only looking at normative info. If normative says, "I can use scripts." then they will only do that. Won't dig to find that page should be used w/out.
JW Don't put it in techniques, put it own document or annotated version of the technology-specific document.
GV But they are only looking at the normative docs.
JW Normative says, "do a or b, or do a, or b and c" and "a requires support for X and b does not require support for x" then they make that decision on what they think is supported.
JM Give them as much supporting material as possible. I see the rationale of removing from normative, but many people will not go beyond it. I predict that when 2.0 replaces 1.0, there will be articles that say "what's new." In 1.0 they will say, "script usable when turned off in 1.0, in 2.0 no longer needed." therefore, we have effectively said, "go wild with javascript."
JW It would be unworkable to have that info in a normative doc.
WC Could look at W3C process for publishing update. Updates have been done for errors, but WCAG is reflecting current state of the art which is a new situation for W3C.
GV Isn't this just "until user agents" in different clothing? Now we're saying "there's a technique you have to do but you can't do this unless these technologies are supported."
JW It's different. Previously we didn't spell out the techniques as alternatives as clearly as we could.
GV If we say "do a, or b, or c" if someone comes up with "d" then they won't conform.
WC Gregory proposed this, as did GV, that there would always be "d" that would outline the intent of the "rule" and that the content developer would have to document what they did.
GV Yes, that's right.
GV Moving back to the list, what was the meaning of "2. User literacy level"?
KHS The reading level of the audience. It's a cynthia thing. Along the lines of education.
JM I was asking if anything had been decided on it.
WC CS concerned that 3.3 require a minimum reading level, is very much against.
JW I wouldn't call it a big issue, but that this issues is one example of a larger one. Can you design content to be comprehensible with less and less assumptions of the abilities of the user. You need to determine when to stop. How much to invest and how far to go.
JM More of 3.4.
JW 3.3. and 3.4. These are the most controversial.
WC Basically, the issue is "where do you draw the line?" You can't reach 100% of the audience, how can we help authors determine where to draw the line.
GV Big issues cover several checkpoints. "Differences by language" what does that one mean?
KHS CMN issue?
JW Bidirectional issues with UA support. Subset of 1 and baseline capabilities.
GV Equivalents collapsed to 1.1.
JW related big issue - if anyone proposes to combine 3.4 and 1.1. The question of whether to keep perception and conception requirments separate and effect on conformance scheme.
GV Have something related to organization? Is the first set all perception? guideline 1 also has structure. Structure important for cognition.
LRG This goes back to issues we agreed on. If we can't agree on things to test/success criteria, then discussing if that should be in a separate document or marked separately. Rather than zeroing in on cognition, then look at what can test or not.
GV Yes. I thought one decision was not to claim conformance by disability.
JW This not necessarily by disability.
GV How doc is interpretted by non-tech people. Basically, we should write as simply as possible. Therefore, can we agree on that?
JW Yes.
JM Links to definitions.
GV Implementation?
WC These discussions were minuted and perhaps we could look for clarification there rather than trying to recreate them. Plus, we are over 5 minutes on the call and could clarify these on the list.
JW Were not minuted well. This is a good exercise.
GV I am pushing through to make sure we get these addressed.
* GV reads the rest of the list. All seem to be open.
$Date: 2001/09/20 21:40:11 $ Wendy Chisholm