RE: 20 Sept 2001 minutes

Is today Thursday? I've been thinking that it was Wednesday all day.

Belated regrets for the telecon. I'd intended to join you, but my brain
evidently had other plans. Sorry. My bad.

Chas. Munat

> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
> Behalf Of Wendy A Chisholm
> Sent: Thursday, September 20, 2001 2:43 PM
> To: w3c-wai-gl@w3.org
> Subject: 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 18:06:05 UTC