20 Sept 2001 minutes

http://www.w3.org/WAI/GL/2001/09/20-minutes.html

20 Sept 2001 minutes

Present
·       Jo
·       Wendy
·       Tim
·       Loretta
·       Jason
·       Katie
·       Gregg

Regrets
·       Matt
·       Charles

Issues
This discussion is based on the Big issues. 19 Sept 2001 - Gregg 
Vanderheiden e-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:38:55 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
/--

Received on Thursday, 20 September 2001 17:40:41 UTC