W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

irc log for monday morning

From: Charles McCathieNevile <charles@w3.org>
Date: Mon, 10 Sep 2001 15:32:08 -0400 (EDT)
To: WAI GL <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.30.0109101531190.14254-100000@tux.w3.org>
This is really raw, but here it is.

Chaals


#wai :@chaals
*** chaals has set the topic on #wai to irc.w3.org:6665 channel is #wai
*** Jo (~Jo@199.108.188.138) joined #wai
      <Jo> This is working now.
*** wendy (~wendy@tux.w3.org) joined #wai
*** mcmay (~Matt@199.108.188.138) joined #wai
   <wendy> GV How to make them accessible to more people, not accessible.
Always a line.
   <wendy> CM (Charles Munat) Is not boolean.
   <wendy> .. making them MORE accessible, not accessible.
   <wendy> .. other agencies help people provide ATs. We can't do everything
to make things accessible.
   <wendy> RN A goal - to make a site that is accessible to ATs
   <wendy> ? by itself but also w/ATs.
   <wendy> GV Gets into UA/designer issue.
   <wendy> JM Like the idea of introducing of "degrees" of accessibility.
   <wendy> .. some readers have a hard time coming at it.
   <wendy> .. oftentimes, accessibility considered boolean. it is or it is
not.
   <wendy> WC how about, "...creating Web sites that are accessible to more
people." also deal with in conformance.
*** mcmay has signed off (Connection reset by peer)
*** mcmay (~Matt@199.108.188.138) joined #wai
             chaals starts minuting
<chaals> CS would be fine having a subsection, likes having how to read in
TOC
<chaals> JM familiar and standard phrase
<chaals> This is getting chopped around a lot.
<chaals> ... might be a good idea to chop it at some point and rewrite it so
oit flows.
<chaals> ...using what is there.
<chaals> JM volunteers to rewrite intro.
<chaals> CM doesn't know when to keep his head down.
      <Jo> CM is thrilled to offer his rhetorical skills to the effort.
<chaals> RN missing: difference between structure and presentation piece was
really strong and that is important to understanding the document.
             chaals thinks we should quit with the jokes already ;-)
<chaals> GV: doing intro should include collecting notes about how to re-do
it, and wait before we start on that process.
<chaals> ... trying to do it too many times might take some attention away
from developing the content. When we think it is full, good idea.
<chaals> JM Right. take it off the table for now, and concentrate on other
stuff.
<chaals> ...also some material may belong in other places. But canbe visitied
later.
<chaals> GV let's not worry about wording, and note down the things we want.
<chaals> RN We could generate a TOC, and fill it in later.
<chaals> TOC == Table of contents
             chaals wants an abbreviation bot
<chaals> GV do we pull intro now or later?
<chaals> CM Now would be good - as long as it is there ist is a distraction
<chaals> WC we talked about making it a chapter - we can bypass it.
<chaals> CM Anything that focuses on guidelines themselves will be helpful.
Also, writing any doc the intro s the last thing you write.
<chaals> GV there is usually something
      <Jo> Chaals: thinks its important that the stuff in the intro is
available to the public as our attempt to explain where the doc is going,
what's missing, etc.
<chaals> CMN It is important for reviewers to have info about where the
document is up to, and what is the difference between things that aren't
there because we haven't finished them and things that aren't there because
we havent thought of them.
<chaals> GV Want to freezeintro until rest of doc is nearly ready.
<chaals> WC before that. We need something - make it a seperate chapter
<chaals> GV take "how to read document, target, drafts in non-web format' and
put them in that category.
<chaals> ASW that assumes we are all in agreement
<chaals> GV Good to have questions raised when they are issues about content
not just wording.
<chaals> ASW seems that the group are not in agreement about audience
<chaals> ASW charter says audience is authors who have some familiarity with
markup languages
<chaals> chartered audience: http://www.w3.org/WAI/GL/new-charter-2000.html
<chaals> GV the stuff in the document is a rough idea, not an attempt to
define the audience
<chaals> CM Do we need to define a target audience in the doc?
<chaals> CS If our target is tech implementors I don't think our writing
style is right.
<chaals> RN We have several audiences
<chaals> GV Theere is a different between target and intended audience -
there is the ones who need it and the others who will use it
<chaals> s/intended/actual/
<chaals> Bob: In my experience there are a lot of people using it. largest
group are people being told - here is the stuff you need.
<chaals> that audience is really imortant.
<chaals> ...one way to deal with that audience is to provide links to other
parts. We do need to recognise that this is used as the basis for a lot of
policy stuff - it has to be readily transferred.
<chaals> s/transferred/transferable/
<chaals> JM keep in mind role of support document. This may be the place that
people get lost. maybe some audiences can be supported by supplementary
documents
<chaals> GV Maybe shouldbe pointer to WAI EO section
<chaals> CS At CSUN meeting I agree with what was decided. There is a
mismatch in that and the charter.
<chaals> WC charter needs to be updated. It says we have expired...
   <wendy> s/wc charter has been updated...need to make sure you have the
right one.  we expire 2002/ previous()
      <Jo> CMN: the supplementary docs are critical.
<chaals> CM CM it is kind of impossible to adress every audience in the same
document. I think some readers are assuming this doc will answer all
questions. I think it is important that WCAG 2 maintains a tone appropriate
for a technical audience, but we are also going to need to have some stuff
that isvery simple.
<chaals> key is tie it in places like intro - e.g. for managers read this
bit, for developers read that bit....
             chaals notes that Johan Hjelm wrote a book with a very good
example of doing this
<chaals> GV Remember this will be a normative document. People will ahve to
meet this, sothey will read this.
<chaals> CM To enable that vocabulary etc must be carefully done.
<chaals> GV Pointing to individual documents will be hard, pointing to places
is good.
*** Jo has signed off (Connection reset by peer)
<chaals> WC A W3C Rec needs to stand on its own.
*** Jo (~Jo@199.108.188.138) joined #wai
<chaals> GV 2 things:
<chaals> 1. document diverse audiences
<chaals> 2. may decide we will focus on particular parts
<chaals> 3. dc must stand on its own. additioal how-to info can still be
provided.
<chaals> s/dc/document/
<chaals> JM can it stand on its own without techniques?
<chaals> GV In old doc we had checkpoints that were normative, and techniques
where there were lots of ways.
<chaals> we now have three - do you mean where it says you can do it like
this, or tech-specific checkpoints?
<chaals> question is whether tech-specific checkpoint should be normative.
<chaals> Will be discussed shortly...
<chaals> GV It has to stand on its own to be a W3C Rec.
*** mcmay has signed off (Connection reset by peer)
      <Jo> CMN documents can rely on other standards but the collection of
what you have as the recommendation cannot rely on scribbled notes that you
keep elsewhere. if you can't make the thing work without those, then it's not
enough to be a recommendation.
<chaals> GV Chair: scope and usability goes into open issues for intro...
<chaals> GV How far did you mean by intro, Jo?
<chaals> CM up to the guidelines
<chaals> general agreement.
<chaals> GV introductory material, not introduction "proper"
<chaals> ----
<chaals> success criteria:
<chaals> ASW. If scripts and applets can be made accessible they shouldn 't
need an alternative
<chaals> GV what if the device doesn't support scripts
<chaals> ASW how do we make that decision
<chaals> GV goes back to our assumption of HTML underneath everything
<chaals> CS Propsed that we require scripting in browsers - still an open
discussion
<chaals> WC It is open.
<chaals> CS A lot of success criteria will hinge on baseline capabilities.
<chaals> GV I would like to have a listof BIG issues.
<chaals> ...some of these are ones we need to highlight - we are fixing
typographical issues, but not resolving fundamental issues.
*** Nickname chaals is in use. Please choose another.
*** Welcome to the Internet Relay Network iamchaals!~charles@tux.w3.org
*** Your host is pfunk.w3.org, running version 2.10.2
*** This server was created Thu Jul 8 1999 at 16:35:44 EDT
*** There are 42 users and 0 services on 2 servers
*** There are 1 operators online
*** There are 1 unknown connections
*** There are 46 channels formed
*** I have 35 clients, 0 services and 1 servers
*** Topic for #wai: irc.w3.org:6665 channel is #wai
#wai :iamchaals Jo wendy @chaals
*** chaals has signed off (EOF From client)
      <Jo> GV if it's accessible, do you still need a text equivalent, or the
ability to reduce it to a text equivalent. Another big issue.
      <Jo> If the AT is available but people don't want to use the AT, do we
want to require that the site be usable without it.
<iamchaals> GV This issue touches on whether people have to buy a technology,
and compatibility vs direct access
<iamchaals> CS Big topics are easier ain person, editorial is eaassier in
email
<iamchaals> GV, KHS, CMN agree
*** iamchaals is now known as elephant
             elephant is scared now
*** elephant is now known as chaals
             chaals is scared now...
   <wendy> CMN part of the elephant in other countries - tech avail in
english,
   <wendy> welsh, etc, is a wide group.
*** mcmay (~Matt@199.108.188.138) joined #wai
   <wendy> either we need a baseline that works for every country, or break
it up by basis, like language.
   <wendy> GV assumption that once technologies available are avail
everywhere.
   <wendy> or run on all hardware.
<chaals> gv right. things are not avialble in all languages for all hardware.
<chaals> ...BTW have been approached by African and UN groups.
             chaals has been looking at access in arabic. Interesting...
<chaals> RN there are lots of ways of doing kiosks
*** Jo has signed off (Connection reset by peer)
*** Jo (~Jo@199.108.188.138) joined #wai
      <Jo> iCab runs happily in kiosk mode
             chaals thinks we are going down a rathole here.
<chaals> WC We should look at proposals about how to deal wit hthis?
<chaals> CM proposal. I think these elephants are the real issues, and the
ther stuff is procrastination until we have solved them.
<chaals> CM we shold therefore start by making the elephant list and start
consigning them to the elephants' graveyard
<chaals> s/metaphorical waffle/deal with the big issues here/
<chaals> CS agree. concern is that I am not convinced we have a quorum to
decide on these things. People disagree on list.
<chaals> WC we can take proposals back to list.
*** Jo has signed off (Connection reset by peer)
<chaals> GV we can't decide anything here. We can make proposed resolutions.
<chaals> CS When can we make final decisions?
<chaals> GV There are big issues. it would be useful to decide what they are.
Process problem is that having changed the agenda what we do is all subject
to review and being overturned.
<chaals> (for good reasons)
<chaals> It is perfectly appropriate to discuss tis stuff as a prerequisite
for dealing with the agenda, and to have proposed resolutions
*** Jo (~Jo@199.108.188.138) joined #wai
<chaals> ---break. When we return, thinking about big issues.
*** Jo has signed off (EOF From client)
*** wendy has signed off (Ping timeout)
*** wendy (~wendy@tux.w3.org) joined #wai
   <mcmay> GV What do we think big issues are?
   <mcmay> CS baseline browser capabilities, reading level
   <mcmay> WC of guidelines
   <mcmay> CS guideline for reading level requirements
   <mcmay> CMN Differences by language and technology
   <mcmay> Reading level with different languages (e.g., Arabic) is a
different issue
*** Jo (~Jo@199.108.188.138) joined #wai
   <mcmay> RN Conformance: how do we measure it; How document is interpreted
by non-technical people
   <mcmay> ...how management uses this document for costing/budgeting
   <mcmay> ... this is where the intro would be helpful
   <mcmay> (implementation issues)
   <mcmay> CM Normative vs. informative - do we need anything normative at
all?
   <mcmay> LGR Universal access - one representation applicable to everyone,
vs. targeted implementations for different groups
   <mcmay> CS and whether it can be considered to be universal if server-side
interaction is involved
   <mcmay> LGR Also an issue for reading level
             chaals notes we have a log up to here.
   <mcmay> GV (client-side vs. server-side as one issue, then reading levels)
*** Jo has signed off (Connection reset by peer)
   <mcmay> GV Are guidelines for access by absolutely everyone?
   <mcmay> GV If not, how do you draw a line?
   <mcmay> ... Guidelines for all sites, or for "special" sites?
   <mcmay> ... Do we intend these to be used by regulators and
requirement-setters?
   <mcmay> CS Sites where certain UAs are expected (intranets, etc.)
*** KatieHS (~kshea@192.239.92.63) joined #wai
   <mcmay> GV general and specific-audience sites and browser expectations
*** Jo (~Jo@199.108.188.138) joined #wai
   <mcmay> MM usability vs. accessibility
   <mcmay> WC conformance underlies everything.
   <mcmay> GV Certainly behind normative vs. informative.
   <mcmay> CS Issues where author and user are in conflict (art, distracting
ads)
   <mcmay> JM When needs of different user groups conflict with one another.
   <mcmay> CM Who is targeted by accessibility? Which groups are targeted. In
WCAG 1, people felt cognitive groups were left out, for example
   <mcmay> Issue of economic disabilities is as much of an accessibility
issue
   <mcmay> GV Economic is not considered a disability
   <mcmay> KHR Comes up under baseline capabilities
   <mcmay> GV No government body considers economic to be an accessibility
issue
   <mcmay> CMN Not true. Australia considers economic an accessibility issue
   <mcmay> GV We consider it "universal access"
   <mcmay> CMN In Australian they don't separate the two.
   <mcmay> CM "Yet". Still discussion about the Digital Divide
   <mcmay> LGR Concerned about scope...
   <mcmay> JM Is illiteracy considered a disability anywhere, and is it in
our charter?
   <mcmay> CMN Yes.
   <mcmay> GV People who cannot read are considered to have a disability.
   <mcmay> KHR What about India, where 50% of the population is illiterate?
   <mcmay> GV And 50 different languages.
   <mcmay> GV To sum up:
   <mcmay> - Baseline browser capabilities
   <mcmay>   - in general
*** TimLa (~timlaranc@199.108.188.138) joined #wai
   <mcmay>   - in specific contexts (intranet, public kiosk)
*** Jo has signed off (Connection reset by peer)
*** Jo (~Jo@199.108.188.138) joined #wai
   <mcmay> 2. User literacy level
   <mcmay> 3. Differences by language
   <mcmay> 4. How to measure conformance
   <mcmay> 5. How document is interpreted by non-technical people
*** Jo has signed off (Connection reset by peer)
   <mcmay> 6. Implementation
   <mcmay> 7. Normative vs. informative (do we need normative?)
   <mcmay> 8. One version for all vs. multiple versions of web content
   <mcmay>   - client-side vs. server-side
   <mcmay>   - reading levels
   <mcmay> 9. Access for absolutely all?
   <mcmay>   - If not, how to draw line
   <mcmay> 10. Guidelines for all sites vs. special sites
   <mcmay> 11. Do we intend guidelines to be used by regulators and
requirements-setters (e.g., in companies)?
   <mcmay> 12. Accessibility vs. usability
   <mcmay> 13. Conformance - why do it? How to test?
   <mcmay> 14. Author and user needs conflict
   <mcmay> 15. User and user needs conflict
   <mcmay> KHS 13 equals 4.
   <mcmay> GV What does implementation mean?
   <mcmay> CMN 5 and 6 are the same: how do people go about implementing WCAG
   <mcmay> .. same as 11: do guidelines need to be directly usable?
   <mcmay> ... there are issues in company policy
*** TimLa has signed off (Connection reset by peer)
   <mcmay> CM Also related to normative vs. informative.
   <mcmay> RN norm vs. inform is confusing because of the words used
   <mcmay> GV New issue under 12: Do we want to have levels of importance?
*** Jo (~Jo@199.108.188.138) joined #wai
   <mcmay> GV COnsensus that the agenda items are better for the list, and
these new items should be discussed now.
   <mcmay> GV 7: If the document is not normative, then it would be a Note.
   <mcmay> CM there are those who would say that this should be an
educational document.
   <mcmay> CM If this is going to be used by regulators, this will have to be
normative.
   <mcmay> TL Whether intended for regulators or not, they will use it.
   <mcmay> CM Disagree. There are ways to write it such that it would be
impossible. Al Gilman has suggested hypertext - it would be difficult to make
a document like that normative.
   <mcmay> GV W3C/WAI lobbied to get people to use this document, rather than
create their own.
   <mcmay> ASW If people are to comply with this, it has to be normative.
   <mcmay> WC W3C is a de-facto standards body. That's why we've lobbied to
host the work, as well as getting people to adopt it. We don't have a choice.
   <mcmay> LGR Issue of conformance: we can provide lots of information
that's not normative.
   <mcmay> ... this may devolve into what kind of conformance scheme are we
going to use.
   <mcmay> RN I see guidelines and checkpoints as normative, and techniques
as informative. Other documents are informative.
*** Jo has signed off (Connection reset by peer)
   <mcmay> CS If checkpoints are normative, technology-specific checkpoints
have to be normative.
   <mcmay> MM Agreed to in Boston as well.
*** TimLa (~timlaranc@199.108.188.138) joined #wai
   <mcmay> CM Wendy said this is what the charter is, etc. There seems to be
movement in a direction that wasn't chartered.
   <mcmay> The Web is a fluid medium. Just because the W3C set out to do
this, isn't necessarily what we should do. Charter may be too limiting.
   <mcmay> Do we need a WCAG 2, or a number of separate documents to support
a database-like structure?
   <mcmay> We're in a straitjacket in believing we're creating regulations.
   <mcmay> Issue is how can we best serve the users of the guidelines. We
shouldn't limit ourselves because that's what's in our charter.
*** oedipus (~oedipus@ns.hicom.net) joined #wai
 <oedipus> aloha, all - sorry i'
   <mcmay> We are not really going with guidelines or regulations. If we
decide to do normative guidelines, we'll have to take things out and focus on
what can be regulatory.
   <mcmay> If we don't choose guidelines vs. regulations, we're going to have
a mess.
 <KatieHS> welcome, gregory
 <oedipus> aloha, katie
   <mcmay> GV We studied why people create accessible products. There was
only one factor: profit/ROI.
   <mcmay> We thought another factor was regulation. Regulation is society's
way of moving something into profit.
   <mcmay> It only works if it is more profitable to follow the regulation.
 <oedipus> is matt minuting on IRC?
   <mcmay> ja. :)
   <mcmay> GV This does not move unless there is a forcing factor.
             chaals wonders if Gregory wants us to set up a telephone bridge
(we have one available)
 <oedipus> sure - show me the digits!
<chaals> +1.617.252.1859
   <mcmay> If we write a bad set of guidelines, either they will be used
where they are not designed, or people will write their own.
<chaals> (we need to dial in too).
   <mcmay> The problem is that this will bring things to a screeching halt.
 <oedipus> i'll wait until i get the signal to dial in
   <mcmay> We wouldn't get WG participation if this were a loose set of
suggestions.
   <mcmay> I think that this should be usable by regulators to cause the
regulations to look the same.
   <mcmay> If industry has no direction, they'll freeze. Two differing blind
groups will cause companies to freeze.
   <mcmay> CM Can we agree that regulators should be able to use the
document?
   <mcmay> (unanimous)
   <mcmay> ... then we should determine which is usable and which is not, and
move what is not usable into another document.
   <mcmay> CMN By usable, do we mean regulators can use this as their basic
reference, or that they can say "this is the regulation"?
   <mcmay> RN WCAG should be something that is definitive. Keep management
overview in EO
   <mcmay> WC Proposal: go through requirements document?
   <mcmay> LGR It's important to capture why. As technology evolves, that
information should be available.
   <mcmay> ...effects on certain user groups.
   <mcmay> ... if our goal is to be consistent across countries, we should
write these as regulations.
   <mcmay> GV Keep in mind the thought that we should have a document that
people could derive regulations from without throwing parts out.
   <mcmay> CMN Regulation in different countries is extremely different.
Anything acceptable in US would be unacceptable in Australia.
   <mcmay> ...verbatim adoption is impossible by those two countries.
<chaals> gregory we will dial you direct.
*** Jo (~Jo@199.108.188.138) joined #wai
   <mcmay> ... in developing policy, decisions are made based on cost,
availability of technology, many of which are outside our area of expertise,
others of which are variable by time.
   <mcmay> ... Australian law considers state of the art at the time and
expects technologies to advance over time.
   <mcmay> JM to LGR Is benefits section the place for the why?
   <mcmay> LGR don't know
   <mcmay> GV Benefits section should show the why
      <Jo> MM how a technique affects a certain user group is essential
tie-in.
      <Jo> MM having "this user agent does this, and this is why you have to
overcome it" is important at a lower level
   <mcmay> GV It's good to reflect that a wider range of users is covered.
*** Jo has signed off (Connection reset by peer)
   <mcmay> We'll try to see if we can eliminate "patches" from techniques
*** Jo (~Jo@199.108.188.138) joined #wai
   <mcmay> KHS What about assistive technologies? Do we have a responsibility
to address moving ATs to a standard?
   <mcmay> GV A spec for what we expect an AT to do?
   <mcmay> KHS What certain versions of ATs do and don't do, etc.
 <oedipus> gjr has his hand up
   <mcmay> GV There's been a lot of discussion about shifting ATs.
 <oedipus> need to work with ATIA on moving to standard, in conjunction with
UA, XForms, HTCG, etc.
*** mcmay has signed off (Connection reset by peer)
*** mcmay (~Matt@199.108.188.138) joined #wai
<chaals> ATIA == Adaptive Technology Industry Association. The rest are W3C
groups
*** Jo has signed off (ShadowIRC 1.1b2 PPC)
   <mcmay> Bob: I'm focusing on the non-technical user.
   <mcmay> ...and how we're taking away their ability to reach users.
*** Jo (~Jo@199.108.188.138) joined #wai
   <mcmay> All the users that are trying to be good citizens need somewhere
to start. This has been the only global conversation to allow that to happen.
   <mcmay> Focus on legislation is helpful, but smaller-level adoptions are
helpful as well. We don't want to isolate them.
   <mcmay> KHS Unicode support for ATIA.
   <mcmay> CMN to Greg: Issue of fixing content vs. fixing technologies.
   <mcmay> If a section is hard to do, should it be in the guidelines? My
answer is that the kind of document we can publish is a technical
recommendation.
   <mcmay> We should say this is what needs to be done to make things
accessible.
*** oeddie (~oedipus@ns.hicom.net) joined #wai
   <mcmay> Social decisions are outside our scope.
   <mcmay> GV Guidelines should include everything, no matter how hard it is
to do?
   <mcmay> CMN Yes.
   <mcmay> WC ref: http://www.w3.org/wai/gl/wcag20-requirements
  <oeddie> lost carrier, but irc still thinks that oedipus is here, so i'm
here as 'oeddie'
   <mcmay> GV This came as a set of agreed-upon principles.
   <mcmay> CM Our requirement is that we want our document to do everything.
Maybe we're biting off more than we can chew.
*** oedipus has signed off (EOF From client)
   <mcmay> ...we're going to dilute the power of the document. This is a tug
of war between regulatory groups and end-user authors.
   <mcmay> Bob: Agree. Put in the hard stuff, make it standard. Then
Macromedia, for example, can use it to press the standard.
             chaals notes that my Mum does accessibility at the university of
Melbourne...
   <mcmay> JM It's not just poor grandma, but making meaningful art. We're
saying you have to hire someone to do everything necessary.
   <wendy> MM Needs to be something that will be easy to modify.
      <Jo> MM not everything needs to be normative or be in a single grand
document. It gets down to a level of fine, fluid detail, so some things need
to be in a document that can be easily modified.
   <wendy> MM must be fluid.
   <wendy> CMN Is there consensus that we should set out all (as many as
possible) the requirements for accessibility?
   <wendy> CMN We've discussed writing something that will be taken up by
legislation, or whether writing something, "this is what you'll do in a
perfect world."
   <wendy> ..legislation, not likely in a perfect world, therefore you'll
have to interpret it.
   <wendy> CS Very concerned about things that have found their way into the
guidelines,
   <wendy> like creating art, writing well...most of G3
   <wendy> ..want to see something that is measurable and practical.
   <wendy> ..easier to translate into code.
   <wendy> CMN believe you'd have universal consensus on that.
   <wendy> CS Issues w/WCAG 1 that are difficult to do, many people discount
entier thing (based on one).
   <wendy> LGR Believe this is strongly related to conformance. Could
structure to make it reasonable.
   <wendy> ...also to address CS's issues.
   <wendy> CS A list of everything one could do, would be interesting, but
not appropriate for this.
   <wendy> GV We seem to consensus on what we're trying to achieve.
   <wendy> ..they should be usable in some way by people who write
regulations.
   <wendy> ..they should have a harmonizing effect on people writing
regulations.
   <wendy> ..different words, different countries, things done differently,
but the effect on companies
   <wendy> .. is similar.
   <wendy> ..i don't beleive we have consensus on whether we should put
everything in, including all the hard stuff, or jsut put
   <wendy> ..what is practical.
   <wendy> ..hard and practical, but not hard and inpractical.
*** mcmay has signed off (Connection reset by peer)
*** TimLa has signed off (Connection reset by peer)
   <wendy> ..we have a continuum.
   <wendy> ..things to require, but not sure how.
*** TimLa (~timlaranc@199.108.188.138) joined #wai
   <wendy> ..Another dimension - measurability.  we know we can do it, but
don't have a ruler to measure.
   <wendy> ... people ought to write things simply if they can, but we don't
know how to do that.
   <wendy> RN 2 yrs ago, i was adam ant.
   <wendy> .. wanted to keep them simple.
   <wendy> .. now, my thoughts have changed.
   <wendy> .. put them out there, w/everything in there.
   <wendy> .. let the countries and companies incorporate what they want.
   <wendy> JM the sum up is accurate.
   <wendy>  (she's talking as loud as she can....)
   <wendy> ..it's already in the draft requirements.
   <wendy> KHS propose, along with QA, shouldn't require anything we can't
show good techniques for.
  <oeddie> we have good techniques, they just aren't supported by the extant
technology
  <oeddie> what "mainstream" ua supports CSS2 in toto? these are the problems
- 508 is just a handy stick with which to beat people over the head
   <wendy> CMN we argue about philosphy way too much.
   <wendy> BR 508 effects what's going on at Macromedia.
  <oeddie> in order to get accessibility "out of the box" we first need to
get it into the box, via canonical specs
   <wendy> GV To get a hybrid, we ought to think about:
   <wendy> .. do kind of what we do in 1.0.  Includes all the info about what
would make things accessible.
   <wendy> .. then hi-lite what is critical in a short list.
   <wendy> .. perhaps short list is (previously P1-3). was
impossible/hard/helps, but somethings put down a level other than pure
definition.
   <wendy> .. sometimes you can do it, sometimes you can't.
   <wendy> .. might have a doc that could be used by others to figure out
what is essential and also
   <wendy> .. provide full range of things to move towards.
   <wendy> .. as tech changes they won't disappear.
   <wendy> .. one reason govnt did not include cognitive in 508 was that they
did not feel there was any way to measure.
   <wendy> .. part of this could be handled by structure.
   <wendy> .. objective, and others to address , but no criteria for success.
  <oeddie> accessibility isn't quantitative - it is qualitative (quality +
ative)
   <wendy> .."do what you can..."
      <Jo> gv - Perhaps aim for a document that includes all the information
about what makes things accessible, and highlight things that should be
critical in anyone's shortlist. We aimed for this in 1.0 with priority 1,2,3.
if we could figure out how to do that, then we'd have a document that can be
used by others (regulators, etc.) and can also provide the full range of
things that we ought to be shooting for. So that as technologies change, it's
still on the table. So we do
   <wendy> foood foood foood foood foood foood foood foood foood foood foood
foood
   <wendy> foood foood foood foood foood foood foood foood
   <wendy> foood foood foood foood foood foood foood foood
   <wendy> foood foood foood foood foood foood foood foood
      <Jo> gv - don't have to throw out the things that we don't have the
technology, techniques to address.
   <wendy> foood foood foood foood foood foood foood foood foood
      <Jo> wc is hungry
*** Jo has signed off (EOF From client)
*** wendy has signed off (...sunny days, sweeping the clouds away...)
             chaals offers wendy a steak
  <oeddie> quick someone feed wc before she takes a bite out of the vetetable
sitting next to her!
  <oeddie> oops, i meant vegetable


-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
Received on Monday, 10 September 2001 15:32:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:12 GMT