<Andrew> scribe: Justin
Shawn: We should be looking at our priorities soon. We've had one main editor for a while. Need to look at who wants to do what.
http://www.w3.org/WAI/EO/changelogs/cl-aria-docs
http://www.w3.org/WAI/EO/changelogs/cl-aria-docs
Shawn: Purpose, Goals, Objectives...
Sharron: Should we articulate who we're giving what
Justin: Is this just for the Overview & FAQ?
Shawn: We're going to talk with PF.
... Approach...
Sharron: Developers will go right to the best practices guide... emphasize the other documents
<scribe> ACTION: Shawn, on the best practices under the approach to clearly strongly point to overview and FAQ because devs will go there first [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action01]
Helle: When we assume, someone has read
something... in the document actually say we assume you've read X,Y,Z
... With the evaluation tools list didn't we do a required reading?
Shadi: Yes, but ER was all EO docs
Shawn: The Best Practices is going to be a W3C Note... means there is front matter
Group: *sigh*
<shadi> http://www.w3.org/WAI/ER/tools/
Shawn: with WCAG2, we were looking at
alternative versions of specs so that they don't have all the front-matter
... Audience and Document Use... a list of the documents and who's going to
read what doc.
Wayne: For web developers, why somewhat primary
mean for the roadmap
... for people writing JavaScript Libraries, is the best practices document
going to be enough?
Shawn: i think so
Sharron: Does Web Developers include JavaScript programmers?
Shawn: yes
Wayne: for Tool Developers...Best Practices doc would be some
Shadi: Do browser developers need the roadmap?... the web technology developers need the roadmap a little bit more
http://www.w3.org/WAI/EO/changelogs/cl-aria-docs
<scribe> ACTION: ask pf the relevance of the different documents for the different audiences [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action02]
<Sylvie> zakim unmute sylvie
Sharron: should we put Authoring tool developers in there own audiences
<Sylvie> difficult to understand person who is talking, it is broken
Andrew: What about adding web applications things like Flickr
Shawn: The action is to break up the audiences a bit more
Wayne: We shouldn't later merge the audiences together
Shawn: *going over the audiences and
documents*
... Most web developers won't take the time to read the roadmap
Shadi: Web developers will only read the
overview the first time
... policy makers will use the overview as their primary doc
Henny: In #3 should we add consultants...
Shawn: #3 or #2?
Andrew: #2
Sharron: It depends on the type of consultant
Andrew: Row 1 stays as is... Row 2 is authoring tool and eval tool developers
Sharron: They're separate audiences no matter what document
Shadi: consultants take different roles...can be developer or can be manager or can work with the authoring tools.
Andrew: They run across the whole thing
Shawn: The tool developer is the primary group
for the roadmap
... for the roles, states, and properties... tool developers primary
... BP guide... web developers primary, what about the other groups?
<scribe> ACTION: Wayne, for the bp guide do they consider the authoring tool, eval tool, ua developer an audience for this? [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action03]
Sharron: would we want consultants and trainers?
Shawn: Should we do a aria presentation?
Group: yes
Sharron: We should add a row for those guys
Shawn: Trainer/consultant... primary for
overview and faq... tec docs it depends
... We may wanna do something especially for the presenter/trainer
audience
Sharron: If we do this as a presentation and people use it, they sound good, we get the message out, and the message is consistent
<scribe> ACTION: Shawn, look at the translation priorities and bring to an EO agenda [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action04]
Shawn: WAI would have the basic FAQ... Mozilla would take the advanced stuff
Jack: How will people know the difference?
Shawn: There's is specifically HTML5
<scribe> ACTION: Sharron, for the faq, clearly distinguish the two and point to the other [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action05]
Shawn: What about video introduction?
... Let's talk about priorities
Jack: FAQ, Overview
... first do a presentation of what it is and why it's important... then do a
how to do it presentation
Shawn: Should we prioritize FAQ questions
Justin: What about implementations in the wild?... as a developer i'll want that
Shawn: That's in the FAQ... let's discuss it there
http://www.w3.org/WAI/EO/Drafts/ARIA/faq
Sharron: adapted the Mozilla one... we took out
the refs to html5... added a few basic questions
... need to know if these are the questions that people will have
... which ones are too advanced
<shawn> welcome Sharron!
<Sharron> thanks!
<shawn> scribe: henny
<Andrew> http://www.w3.org/WAI/EO/Drafts/ARIA/faq.html
Shawn: Overall skim over the questions, first impressions coming to this document, what do you think?
Sylvie: If this document is dedicated to advanced people, technical people or people that don't know much about ARIA? Will it have a glossary?
Sharon: The FAQs are for all levels, it's an introduction to ARIA for all reasons. This will probably be kept fairly basic then forward people to the advanced FAQ kept by teh Mizilla Foundation
Sharron: there should be enough here for people
to investigate further.
... what were there terms that were most problematic?
Sylvie: widget and others
Shawn: so we understand you will send more feedback later but what did you pick up on for now?
Sylvie: I will send an email with this later.
<Sylvie> I have already sent an email to shawn on my availability tomorrow
Sharron: we want to give a good foundation for less technical people and direction to more information to more technical people.
Shawn: and we don't want to repeat information from the Overview
Wayne: the overview is not a technical report?
Shawn: No.
Jack: Couple of general reacitions. I found
this helpful. I had started from the technical documents which were
tedious...anyway, this was good.
... second reaction seemed sour, like pulling teeth but we have to do it
anyway. Do we want to convey this or the idea that this is good stuff and
people should do it
Sharron: Some of the text is right out of Mozilla which we may want to take out?
Jack: "Is ARIA too complex for developers to get right"? This is possible off putting.
Shawn: Remindsme that stating the myth perpetuates the myth.
Sharron: Maybe the way to format the question is how difficult is it to learn ARIA.
Shawn: Good point Jack. What we do want is developers to relate to the questions.
Andrew: Each question should have a positive spin.
Jack: So each question is asked and then the answer dispells the myth. You don't want to sugar coat it but you don't want people to think it is a teeth pulling exercise.
Sharron: Be positive but realistic.
Andrew: People may skim over teh document and if the question is negative this is what they may read rather than the answer.
<sr> ACTION: Sharron FAQ rewrite Question 8 [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action06]
Wayne: A lot of this stuff is simplifying organisation. If you start off in the Roadmap doc and get lost you can really not see what it is about. ARIA is an easier way to develop JavaScript but you need to learn it.
<Sylvie> last quick note : question 13 should also be rewritten :
<Sylvie> 13. Isn't ARIA expensive to implement in browsers?
Wayne: this should be in the questions and answers. It's easier to do it once you have this framework.
<sr> ACTION: Wayne to send point by point how ARIA framework makes JS process easier to Sharron [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action07]
Sharron: The question about widgets should be moved up in the order
Justin: People have different ideas of what a
widget is.
... like desktop widgets, iGoogle, Windows Vista, these are widgets.
Shawn: this is a different definition to what I
use.
... widget means different things to different people. Can we find a more
precise or less confusing term.
Sharron: but lots of programmers know what a widget is.
Shawn: but different people have different understanding of widget.
Sharron: How about in Q3 we say for our purposes we define it.
Helle: Wikipedia calls it a web widgets, portable code that can be used
Shawn: is there something else that can be used instead?
Wayne: what about using web widget?
Justin: Input, slider bars, buttons...
Andrew: there are hundreds of sites refering to JavaScript widgets.
Justin: JavaScript componants?
Andrew: if widgets are used by this community then we should use this.
Helle: It's a technical gadget or small thing.
Wayne: Everything I read about JavaScript refers to widgets.
Andrew: agrees.
Sharron: we should clarify our references.
<scribe> ACTION: Sharon - the first mention of widgets clarify what we mean by it. [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action08]
<shawn> s/sharon/sharron/
Shawn: We've said that we assume peoplel have read the overview or that if people arrive here first we say that.
Sharron: It's in question number two but it might not hurt to have that in teh introductory paragraph.
Jack: We should add why is WAI-ARIA needed?
Shawn: should these be in the FAQ or the Overview?
Jack: My guess is in probably in both places but in the FAQ have one or two simple sentences saying why you should be doing this.
Shawn: One thing we said is that we were not going to repeat information between the Overview and FAQ.
Jack: For some people they make it through the
overview but reinforcing it here is a good thing.
... a one or two sentences on why is ARIA needed is a good thing.
Shawn: what about if we had in the FAQ it listed more specifically what was answered in the Overview.
Jack: I wouldn't do that because you are having several people do several mouse clicks to get to teh same information.
Wayne: maybe recast it so it says "Why is WAI-ARIA a good thing"?
Jack: I think that you need a compelling reason as to why people should do this as it is going to take some effort. Some of this is buried and you have to work hard to figure that out.
Shawn: Where do you think is the split between the Overview and the FAQ.
Jack: We tend to talk to ourselves as to why this is needed as rather than others.
Sharron: There's no headline anywhere saying why WAI-ARIA is needed.
Wayne: we may not be communication that WAI-ARIA is necessary. This could be in the Overview.
Shawn: It depends what you are doing with it. A person may design an application that doesn't need WAI-ARIA.
Wayne: If you delve into these technologies and you don't use WAI-ARIA something is going to fail. This is going to guarantee that it wont fail.
Shawn: We need to work out what goes in the Overview and the FAQ.
Sharron: If we are sending people to the Overview first we should put it there. Then they will be motivated to go to the rest.
Wayne: could we put what we mean by teh term widget in the Overview?
Shawn: The overview doesn't refer to widgets.
Wayne: but we could introduce it there...
Shawn: We will take teh question about widgets
on further research for everyone.
... What is the philophy or differences on teh Overview and FAQ.
Sharron: the Overview introduces the documents.
Shawn: the Overview is the short version and
the FAQ is the longer version.
... Sounds like a short pithy "why this is needed" at the beginning of the
Overview is needed. So let's look at getting this across right away. We want
this in the Overview does it doe it sufficiently.
Wayne: Somewhere in the first paragraph it shoudl be said.
Jack: ...the ARIA suite should be explaoning
how to make these things accessible.
... It seems you have to dig really hard to understand that you can make
these things accessible. ARIA is here to solve the problem.
Shawn: that isn't conveyed in the Overview?
Jack: For me it wasn't.
Shawn: I want to clarify that you can use JavaScript and be accessible for some things.
Justin: Number 3 says that "Accessibility should not hold web authors back from innovating. Several basic Javascript widgets are well-known and commonly used and yet conspicuously missing from HTML 4 today. Accessibility need not lag behind such innovations. The problem is not that JavaScript is bad for accessibility, as some have claimed, but that there is no mechanism to describe what the script is visually portraying to a user. The ARIA initiative seeks to make a
Wayne: No I don't think it does it. I needs to
have something in here that says right now people can't use a lot of
JavaScript, it's easy to do it wrong so we need to learn this structure.
... the point is most people that do JavaSript, change the DOM and make it
accessible without knowing it.
Jack: it seems to me that part of the information that needs to be conveyed is to policy makers is why you should be doing this. For the policy maker audience that's missing.
Judy: I thought I was hearing pithy...to say up front in a basic way that we need this but doesn't go into detail.
<Sharron> ACTION: Sharron to make business/usability case strong and near the frontand in a basic, non-detailed way [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action09]
Judy: I would have the first paragraph not include an example (in the Overview).
Andrew: that statement is in the opening paragraph.
<shawn> ACTION: shawn - consider if can rewrite: "This page introduces the WAI-ARIA Suite of technical documents THAT IS REQUIRED for making dynamic" [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action10]
Judy: One way to say it is many applications pose accessibility challenges, WAI-ARIA provides a suite to address this and this page is an introduction.
Shawn: Let's go back to the FAQ. Imagin that the Overview does what we want it to do. Looking at these first few questions in the FAQ how do we reference the Overview.
Andrew: We should have an introductory sentence saying we assume you have read the FAQ - just as we do in the other documents. Question two should go lower in the list.
Shawn: how to point to the Overview should be
left to Editors discretion.
... it should either be the first question or in the opening paragraph.
<Sharron> ACTION: Sharron to consider how to introduce Overview as opening sentence or question 1? [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action11]
Shawn: What else at the beginning?
Wayne: I still think the "why" is important. We really need to state the necessity without so much justification. Here we could put in an example.
Sharron: Some of the statistics that Jack picked up on.
<Sharron> ACTION: consider how to extend basic need for ARIA into information that brings it hoem and makes the need compelling [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action12]
Shawn: Any more for now (we will come back to this?)
Helle: We use WAIr-ARIA and ARIA, interchangable...
Shawn: On first reference it should always with WAI-ARIA then after that it can be ARIA.
Judy: It's a trademark issue. So if we use an additional identifyer it skirts that.
<scribe> ACTION: Judy check when we can use ARIA and WAI-ARIA. [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action13]
Judy: Announcements. Andrew will be joining WAI
on the WAI-Age project.
... Shawn is chairing EO now. One other change is that Shadi is now the
Activity Lead for the WAI International Office.
<shawn> http://www.w3.org/WAI/PF/aria-practices/
<justin> Andrew: There is all the stuff at the front
<justin> Andrew: Can we have a link to the contents?
<justin> ACTION: BPG, adding a link at the top for contents, overview ? [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action14]
<justin> ACTION: Overall link at alternatives to TF front matter - aria bp, mobile web-wcag2 [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action15]
<justin> ACTION: BPG, title of the doc should be WAI-ARIA [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action16]
<justin> ACTION: BPG, in their intro add a link to the overview [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action17]
<justin> Justin: The intro is really an abstract
<justin> Andrew: The intro is longer then that...
<justin> Andrew: the whole thing 34 print pages
<justin> Justin: Yikes
<justin> Andrew: it should be clear where you go
<justin> Shawn: what about progressive disclosure... give people the ability to drill down
<justin> Justin: I'm looking for best practices... where do I find the best practices
<justin> Sharron: they'd skim the intro saying there is nothing there that I need
<justin> Justin: Within WCAG 2.0 TC, it's easy to know where to start
<justin> Shawn: after the intro it's all best practices
<justin> Shawn: What about a small TC and a long TC
<justin> Henny: What about bolding the major section headings in the TC
<justin> Shadi: some of the third levels are not important enough to be in the TC
<justin> Andrew & Justin: Yes
<justin> ACTION: BPG, for the TC provide a shorter one... and then provide an expanded one... for the expanded table of contents and be able to limit them where appropriate...consider using less things on the third level... consider using a tree control [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action18]
<justin> Shawn: Lets look at roadmap review
<justin> Jack: There is a disconnect
<justin> Wayne: Isn't the roadmap optional for the developer audience?
<justin> Jack: Why not take that right out of here and put it in the FAQ
<justin> ACTION: BPG, in the beginning add a link to the overview, our faq, and technical faq [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action19]
<justin> ACTION: BPG, ref the 55% stat and any other one they quote [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action20]
<justin> Jack: I wouldn't get rid of any of the intro information i'd just move it to other places
<justin> Shawn: they could move 1.1, 1.2, 1.3
<justin> Shawn: where are we moving this stuff? The FAQ?
<justin> Sharron: for the detailed intro... if we put that in a separate doc, we could make small references
<justin> Shadi: There is a need for rationale. The concepts need to be explained somewhere.
<justin> Jack: There is agreement for the need of rationale. many of these aren't specific to a best practice.
<justin> Shawn: People need to be able to find the info when they need and not when they don't.
<justin> Justin: there is the overview... we need a technical overview that goes between the overview and the best practices
<justin> Shadi: That would help to address the audiences better
<justin> Shawn: is it hard when there are that many documents
<justin> Henny: With it being that big, you need multiple documents
<justin> Justin: This seems like it should be techniques
<justin> Wayne: There should be a mid-level document for developers
<justin> Henny: you wouldn't know to look for the technical overview in the best practices guide
<justin> Justin: aren't there aria techniques in WCAG2?
<justin> Shawn: yes
<justin> Andrew: They should be synced up
<Andrew> Scribe: Andrew
<Henny> http://www.w3.org/WAI/EO/changelogs/cl-aria-docs
http://www.w3.org/WAI/EO/changelogs/cl-aria-docs
Shawn: gives backround to PF on our day's discussion
Document: http://www.w3.org/WAI/EO/changelogs/cl-aria-docs
Lisa: BP is intended to be a "how to"
Michael: tool developer will need the Spec and the BP
Justin: tool developer is a seconadry audience for BP?
Lisa: agree
Michael: Roadmap audience is probably mostly
internal W3C plus people interested in background
... specifically spec developers and those interested in Vision of W3C
Wayne: Is Roadmap like a design architecture?
Michael: not that formal - more of a gap analysis around accessibility API and current technologies
<shawn> ^^^ "sound bite"
Michael: we analysis what existing APIs provide, then look at what else is needed to fill those gaps and extend 'non-extendable' languages
Shawn: average web developers don't need to read RM?
Michael: correct
Lisa: reading the RM gave me an understanding
of what is needed
... tend to think RM will continue to stand on its own and give an
undertsanding of why it is important
Michael: RM gets too trechnical for that role - an extended intro might better serve that purpose
Justin: ave web developer just wants to get stuff done, but don't the why, just the what to get the job done
Lisa: so how do we get them to look at BP?
Justin: a direction to be accessible
... but they just want the what
Lisa: trying to break it down to key elements - training wheels for ARIA in BP
Justin: just tell me how - and lead me to 'why' if I choose to read further
Lisa: BP is intended to be a step-by-step for developers
Sharron: too much in BP intro for this purpose
Justin: we thought about amore technical intro for those who want to know more
Lisa: the missing technoical doc - what is going on with the DOM, what a user agent (or AT) does, etc
Shawn: demos WCAG 2.0 QuickRef for a possible
approach
... the ave developer should be just able to get the essential 'how-to' info,
and then the why is they chose it
Justin: also good for the repeat visitor
Michael: most authors will us elibraries, not
implement ARIA directly.
... they just need to know what elements to select from their library
... as well as the author doing ARIA form scratch
... eg DoJo
Jack: so, msot develoeprs will be using a
library?
... in this case they need to know that the library they have chosen is
"good"
michael: also need usage guidelines - how to associate the libary with your control
Lisa: thought BP was for those developing ARIA natively (not for those implementing from libraries)
Justin: vcan't assume all devlopers use libraries
Lisa: UIUC have a sample library - people might
take these and customise to their specific needs
... and use the BP to help cutomise
<shawn> ^^^ sound bite
Jack: developer want enuigh knowledge to be able to select a good library/widget
Lisa: there is no ARIA validator
Shadi: that requires a layer of test suites
Jack: want to kow if I'm getting good stuff
from X or Y library?
... this is related to BP - identify a need, grab sonething from a library,
want to know it's good, then how to modify/adapt it
Wayne: hybrid approach is what people do -
build/borrow/adapt
... don't let BP get too lean so the build person gets it wrong
... RM doc is way too much
... need something in betwen RM and Roles and Properties
Michael: the idea of yet another doc is frightening - it keeps growing and delaing the relaese
Shawn: consider breaking the current BP into two docs for these audiences
Michael: BP is not mature enough to just do this
Lisa: what did EO envisage?
... a coneptual and a step-wise?
Shawn: possibly - because some poeple will get lost/overwhelmed by the current BP
Lisa: basically just a collection of
information - not complete
... we have a lot of refernce material - the QuickRef approach may be good
Justin: whint WCAG 2.0 there are ARIA techniques - what will the relationship be?
Michael: this a question for WCAG group, not
PF
... a few WCAG 2.0 SC edpend on ARIA, but would probably be happy for BP to
take over (subject to chairs/WG's )
Shawn: what can we help with?
Michael: discussing who is editing whaich docs
- BP is under PF (and Lisa)
... overview is EOs; RM is PFs; BP seems to be in the middle
Lisa: after the next round of drafts, EO help
would be good
... and if we decide to break into two docs, then EO ideas would be good
Wayne: offers to read as a technical writer
Shawn: next question is - should some of the BP
intro move to the FAQ?
... considering there might be two FAQs - basic and technical
Michael: don't want to remove stuff from BP - it should stand alone
Shadi: what about changing the title? BP impies that it is targetted at the develoeprs (who probably doesn't want the background detail)
Shawn: seemed that we needed a 'technical' intro between Overview and BP
Judy: FAQ can have the same info - but in different detail
Lisa: FAQ is meant to be quick answer
Michael: if stuff is in the FAQ and not in the
spec, hen the spec is deficient
... had originally intended just two docs - so may not be quie right as we
break up and add more bits
Judy: FQ can have stuff that is implicit in the
tech spc or basic overview
... making stuff more explicit
Michael: ok, and somethings should not be repeated, some should be
Sharron: need some stuff on teh business case in the FAQ
Lisa: had a sense of 'de ja vu' as writing the same info that was in the RM - worried about change in one place ad not the other
Shawn: every doc should point to the overview - we need to assume everyone has read it
Judy: don't want too much repetition; want to steamline approaches; multiple paths are good for encouraging people to get the stuff they want efficiently
Shawn: most of EO said on first read said "too much info - overwhelming"
Judy: EO docs in general - initially tried to
make every doc fully complete, then changed to multiple pointers to important
info (rather than repeating)
... admit that we do lose some people, but hope we help more than we lose
Michael: objet to saying we can assume people
have read something else. Need to point explicitly to 'reuqired'
pre-reading
... need to intro a topic and then link off
Wayne: some people want to know everything;
other groups need a more gentle intro and some intermediate material
... eg a tool developer doesn't need the easy stuff (they already have the
context); other need the background
Jack: distinct audiences, so 'one size fits
all' is a problem
... some just want the nuts and bolts; others need the background &
context
Wayne: two very distinct audiences - tool developers and others, with very different needs WRT detail they need
Michael: PF aware of this - hearing that we need to widen the difference between the two types of dicuments to help address their different needs
Justin: MWBP is easy to read and palatable
Micheal: but not inherently a spec
Michael: we need to reflect this feedback back
to the PF working group and see what they think
... we have a seeison for this tomorrow - would be good for EO to be there
(13:00 - 15:00 on Tuesday)
Lisa: the whole thing has grown out of a need
from users
... Overview needs to be brief - and then branch for different audiences
Judy: shorter is better for users - can we
stream more?
... shorter FAQ is better for users - can we stream more?
<scribe> ACTION: for FAQ consider categories such as relation to other W3C specs and business and such [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action21]
Sharron: what will happen to stuff we don't incorporate? don't want to los them - will they form part of another document?
Michael: we don't want to point to te Mozilla doc - was intended to form a discusison document
Shawn: listing implementations is a question -
who support it
... what do we do with this?
Sharron: gives validation to the practice
Michael: set up a page on PF and just point to that
<scribe> ACTION: Michael - capture the implementations for PF [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action22]
Judy: 'supports' is confusing - maybe we want
'incorporating'
... generally good to have a luist available
Shadi: but not in FAQ
Andrew: support list needs version of tools
Justin: can we group by authoring tool, UA, etc
A ction: for FAQ - say somethikng generic and point to the (to be developed) list
<scribe> ACTION: for FAQ question about implemenation/support - say somethikng generic and point to the (to be developed) list [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action23]
Sharron: will take out the technical questions in next pass
Shawn: or categorise?
... discuss 'widget'
Lisa: a reusable piece of code that is reused
for a specific purpose within a user interface
... danger that "widget" will be translated into a vendor specific term
<scribe> ACTION: PF needs to inlcude a definition of Widget - and we may repeat (expand) it in the FAQ [recorded in http://www.w3.org/2007/11/05-eo-minutes.html#action24]
Shawn: program check
Hoemwork: WCAG comments (from email)
Meeting closed: 17:30
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Henni/Henny/ Succeeded: s/ER stuff/evaluation tools list/ Succeeded: s/quest/questions/ Succeeded: s/Sharon/Sharron/ Succeeded: s/Sharon/Sharron/ Succeeded: s/Sharon/Sharron/ FAILED: s/sharon/sharron/ Succeeded: s/talj/talk/ Succeeded: s/teh/the/ Succeeded: s/teh/the/ Succeeded: s/it's/the whole thing/ Succeeded: s/optional/optional for the developer audience/ Succeeded: s/intro docs/intro information/ Succeeded: s/eys/yes/ Succeeded: s/Shaw:/Shawn:/ Succeeded: s/on first read/on first read said/ Succeeded: s/down't need he easy/doesn't need the easy/ Succeeded: s/code tat is resued/code that is reused/ Found Scribe: Justin Inferring ScribeNick: justin Found Scribe: henny Inferring ScribeNick: Henny Found Scribe: Andrew Inferring ScribeNick: Andrew Scribes: Justin, henny, Andrew ScribeNicks: justin, Henny, Andrew Default Present: Sylvie Present: Wayne Sharron Shadi Jack Henny Justin Helle Andrew Shawn Sylvie WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Agenda: http://www.w3.org/WAI/EO/2007/11f2f WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 5 Nov 2007 Guessing minutes URL: http://www.w3.org/2007/11/05-eo-minutes.html People with action items: alternatives as ask at bpg categories consider faq for how judy link michael needs overall pf relation sharon sharron shawn such wayne[End of scribe.perl diagnostic output]