AGWG Teleconference

13 Apr 2021


sajkaj, JF, Laura_Carlson, AWK, alastairc, Makoto, Rain, julitte_alexandria, mbgower, JustineP, MelanieP, Fazio_, jeanne, sarahhorton, KarenHerr, johnkirkwood, Jennie, stevelee, Katie_Haritos-Shea, Rachael, jon_avila, bruce_bailey, Wilco, StefanS, GN, Francis_Storr, morr, GN015, morr4
Rafel Charlampowicz, Charles Hall, Nicaise Dogbo, Chris Loiselle
Laura, bruce_bailey


<Chuck_> meeting: AGWG-2021-04-13

<laura_> Scribe: Laura


<laura_> Chuck: Anyone new?

Silver FPWD issue resolution

<laura_> chuck: we will spend 30 minutes on silver issues.

<laura_> … wcag 3 would like to learn how ag operates.

<laura_> … silver team has just had some training from AC.

<Chuck_> https://github.com/w3c/silver/issues/

<laura_> chuck: link to all of the silver issues

<jeanne> Weekly report https://www.w3.org/WAI/GL/task-forces/silver/wiki/Issue_Processing_Report

<laura_> chuck: link to report https://www.w3.org/WAI/GL/task-forces/silver/wiki/Issue_Processing_Report

<laura_> … issue raised by ITI

<laura_> … process > draft response. survey.

<laura_> … I have put together a draft response.

<laura_> … … today we are skipping the survey

<laura_> … I have put together a draft response.

<Rachael> Thank you for your comment. This terminology is intended to express concepts that have yet to be fully explored. The working group will maintain a list of different possible terms for these concepts, which will guide us as we explore these concepts in greater detail.

<laura_> … “Thank you for your comment. This terminology is intended to express concepts that have yet to be fully explored. The working group will maintain a list of different possible terms for these concepts, which will guide us as we explore these concepts in greater detail.”

<Rain> +1 to Jeanne's question: can we start that list and link to it?

<laura_> AC: group will take into account your suggestion.

<laura_> js: maybe have a list of candidate terms.

<laura_> ac: if we have a list we could link to it if we had it.

<laura_> chuck: positive input. I will adjust the proposed response.

<jeanne> To AWK, "status: schedule future draft"

<Zakim> AWK, you wanted to propose label for issues closed but that should be followed up on later

<laura_> awk: this response “yup noted” but this will happen again.

<laura_> … have a set of labels in case anyone else comments on it so it doesn’t get forgotten.

<laura_> jeanne: we had a label we could revisit the label name for it.

<laura_> rm: think there is a difference in labels.

<Zakim> sajkaj, you wanted to suggest this is a milestone meaning

<laura_> awk: make sure we address comment.

<laura_> js: you can set milestones.

<alastairc> I think it's the other way around, issues need to be closed before a milestone.

<laura_> rm: could make sense to close and then set a milestone to check.

<Rachael> I agree that is how it usually works alastair

<laura_> chuck: question on kiosks.

<Chuck_> https://github.com/w3c/silver/issues/225

<laura_> … “Can content accessibility guidelines explicitly apply to user interfaces of closed systems and kiosks?”

<laura_> … question on scope.

<laura_> … scope could be viewed in not so limited a fashion.

<laura_> … best for ict or WCAG3?

<jeanne> Scope section of the AGWG Charter of 2019 <- https://www.w3.org/2019/12/ag-charter#scope

<laura_> js: in spirit to expanding - it is basically just another interface.

<laura_> …think it would be compelling.

<laura_> rm: can be web interface but there are others.

<laura_> js: is in challenges doc.

<laura_> chuck: hoping someone will assign themself to this issue and craft a draft response.

<Rachael> But for those that have web interfaces, I think WCAG should definitely apply. For the other approaches, it should depend on how we handle mobile, desktop, etc.

<laura_> mg: some challenges with this one.

<laura_> … would be good to delineate what silver will cover and what it won’t cover.

<jon_avila> EN 301549 does better than 508 about applying WCAG to closed functionality but doesn't really specify or interpret enough to fully address accessibility of these systems.

<laura_> awk: short answer is no. WCAG focusing on APIs and AT. That is the problem of closed systems.

<jon_avila> closed functionality is defined that you can't bring your own assistive technology - keyboard interface is different in my opinion.

<laura_> … if it is really closed would be beyond the scope of WCAG3.

<Fazio_> There were discussions aaabout having multiple versions to address different systems

<laura_> … happy to draft the word no.

<laura_> … happy to help.

<johnkirkwood> is this aldo non standard language beyond HTML

<laura_> sl: one of the projects I worked on was ATM.

<laura_> … all sorts of proprietary ,

<jon_avila> This isn't limited to just kiosks but to connected devices like smart TVs, etc.

<laura_> dm: can’t bring your AT to closed systems.

<laura_> … big concern would be delays and lack of expertise.

<laura_> ac: base response on the charter and mention closed systems.

<jeanne> +1 Alastair

<Rachael> +1 to Alastair's approach

<laura_> mg: I volunteer to draft a response.

<Chuck_> https://github.com/w3c/silver/issues/286

<laura_> chuck: other issues:

<laura_> … looking for volunteers.

<laura_> … have over 200 issues.

<laura_> awk: ARIA WG has also gotten this 286 comment regarding "disabled" used in the ARIA and HTML attributes.

<laura_> … may want to link some issues together.

<laura_> chuck: still need to address the comment.

<Chuck_> https://github.com/w3c/silver/issues/286

<laura_> awk: I will bring it to james.

<laura_> chuck: hoping to make this a regular event.

WCAG 2.2 Redundent entry (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/

<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/results

<laura_> chuck: Alter note for Redundant Entry #1660

<laura_> … Michael Gower opened Issue 1660 to suggest the note is adjusted to be more specific to repeating passwords.

<laura_> … There is an updated PR 1659 was created to implement that, which: Removes the note entirely. and Expands the explanation in the understanding document.

<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/results

<laura_> … Rain agreed with the update with adjustment

<laura_> rain: worried about passwords.

<laura_> … Guidance on what constitutes a secure password changes over time, so I would recommend removing "non-dictionary string." This could be replaced with other wording if needed (though I don't think it is since describing good password practice is not the intent of this document). Example replacement wording: "unique, containing a large variety of character types and/or random words"

<Fazio_> Where is this paassword verbiage?

<JF> +1 to DAvid

<laura_> df: where did all this password stuff come from?

<laura_> …sounds like accessible authentication

<laura_> mg: I took away the note.

<laura_> … some good feedback that I think I can incorporate.

<laura_> chuck: a lot of support for rain’s text.

<laura_> df: like what mike said.

<Fazio_> +1 JF

<Fazio_> +1 again JF

<laura_> jf: should not be talking about authentication. It is not our job.

<Fazio_> It's not the essence of redundant entry

<laura_> … outside of our scope.

<laura_> ac: talking about redundant entry.

<Rain> +1 to JF and Mike, my concern is more about becoming dated in guidance, and removing would resolve the concern

<Fazio_> If it's essentia;

<Fazio_> essential

<laura_> … repeated password is a very common use case.

<Fazio_> I guess I missed the convo

<laura_> … mg made an update.

<laura_> … need to explain it somewhere.

<Fazio_> It's not always ok

<Fazio_> It can be burdensome

<laura_> … why it is okay to have a repeated pass work. - can’t copy paste.

<Zakim> JF, you wanted to note that 'password' is one of the form inputs covered by SC 1.3.5 and @autocomplete

<laura_> … take out from SC and add to understanding doc.

<Fazio_> well redundant entry isnt creating new passwords but reentering

<Fazio_> +1 Rain

<Fazio_> accessible authentication!

<michael> Yep, I will incorporate

<Fazio_> biometrics

<alastairc> Fazio - as written it applies to all unless we consider it essential

<laura_> rain: feel more comfortable with the word “may”

<laura_> … may be essential.

<johnkirkwood> +1

<laura_> df: not about creating new password.

<laura_> … maybe dovetail with accessible authentication.

<Fazio_> yes

<johnkirkwood> reduntant entry can also prevent keying errors.

<laura_> awk: we have other SCs. hard time with out definition of essential. Don’t thing it really fits here.

<laura_> … change the exception.

<Wilco> +1

<michael> Yep

<johnkirkwood> +1

<johnkirkwood> validation

<laura_> rm: started talking about security. but the redundant entry is what we are talking about.

<Fazio_> I'm on the fence

<laura_> awk: this is splitting a hair.

<Fazio_> I'm concerned about excessive password reentry

<laura_> … make the exception include security.

<alastairc> Fazio - that shouldn't be an issue given accessible auth.

<laura_> mg: I’ll rewrite it. This is not about security.

<Fazio_> no wrgument there

<Rachael> +1 to mbgower

<jon_avila> I agree with Mike and Andrew - this is about functionality and not security.

<johnkirkwood> +1 to MG it is not about security

<Zakim> alastairc, you wanted to say that as Rain mentioned there are other methods

<laura_> … can’t copy a password. Security is confusing the SC.

<Fazio_> moodle allows that

<laura_> ac: other methods than repeating a password.

<laura_> … can’t be essential. agree with awk expand exception.

<Rain> e.g., not requiring password repeat but creating a smooth way to recover with email validation or other methods

<laura_> df: coga folks tend to reuse passwords.

<laura_> … concern with having people locked out.

<alastairc> That's a different issue... this is repeating the password as part of the same process, I haven't come across that.

<laura_> … having to reenter password is a problem.

<laura_> chuck: heard that reentry is a problem and that there are mechanisms.

<Rain> My concern, to be specific, is using the word "is" vs. "may be" (implying that this is the only way)

<Zakim> alastairc, you wanted to check what we can live with.

<Fazio_> Only for confirmation purposes

<laura_> … not sure which way the group is leaning.

<johnkirkwood> password reentry for validation shoud be an exception

<laura_> ac: essential doesn’t really cover it.

<laura_> … make sure the exception covers it.


<jon_avila> When re-entry is essential to validation of the information this is considered essential

<Zakim> Rachael, you wanted to ask if we can qualify that its data validation when correction is not possible

<laura_> gn: when entering a password I have seen it have the ability to make it visible.

<Fazio_> can't we say exception when confirming a new password is correctly entered

<Fazio_> or some variation

<alastairc> but without allowing everything to be 'validated'...

<laura_> rm: need to clarify the exception.

<laura_> mg: email can rely on auto complete.

<GN015> +1

<laura_> … if people think it is not an exception I’ll take it out.

<laura_> jk: it is about of data validation. people may not be on their own machine.

<laura_> ja: we should not limit to passwords.

<alastairc> anything for authentication?

<laura_> .. finanial and leagle use cases too.

<bruce_bailey> scribe: bruce_bailey

<johnkirkwood> I trust MG.

<johnkirkwood> ;)

<Jennie> Employee ID number is another one.

chuck: summarizing, think that we hear that validation is a reasonable use case
... we do not have consensus on language

DavidF: yes, could be generalized to cover situation on SSA

<Fazio_> validation of only something just created

Chuck: we do have consensus on point to be moving to
... Mike G has offered to take another cut at drafting

<jon_avila> I agree with David on immediate validation.

Chuck: action item is for Mike G to keep working and bring back to group

WCAG 2.x issues https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/

<johnkirkwood> David said validation should be immediate. Agreed.

<alastairc> mbgower - branch https://github.com/w3c/wcag/tree/wcag22-redundent-entry-security-note

DavidF: one requirement is for validation to be immediate

Changes of context definition

DavidF: if it is on a different screen, that is very confusing

<Fazio_> validation of data entry must be immediately

JohnF: what if the user is warned ahead of time they will need to reenter PW or whatever ?

DavidF: No, since the prompt might not immediate enough

(John and David discuss)

Decision policy https://www.w3.org/2002/09/wbs/35422/ag-decision-policy-update3/

WCAG 2.x issues https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/

Chuck reads question.

Changes of context definition



User perceive context changes as setting the focus to other locations, based on change of

Oliver Keim responds to his survey entry.

OK: Not sure if viewport used in this context is clear

Gundula: redraft is not much clearer than previous version
... subclauses are not as easy to follow
... complete subclauses beter than interrupted subclauses
... disagree with update

MikeG: easy fix would be just to remove "changes of content"
... redraft does not change any meaning

<Chuck_> +1 mgower

MikeG: taking "change of context" is opening a can of worms since it impacts other SC
... point of view is a big issue though, so simple removal is was to avoid that problem

<alastairc> Jake - did you agree with Mike's suggestion?

Sarah Horton: don't think edit address the main problem

scribe: i am in favor of keeping work on this and related definitions

AWK: i am seeing to much redundancy between opening and middle
... more importanly, we should only change Understanding

<laura> s/focusing on APIs ans /focusing on APIs and /

AWK: if we are changing Normative text, it should be done as Errata
... i strongly recommend against this.

<johnkirkwood> +1 to AWK

<alastairc> It is 3, one is "changeS of context"

Wilco: Agree with Andrew. There are two SC where this definition is used, so it is very problematic
... not worth the risk for such a small edit. Agree with AWK that Errata is the way to make this change, if that is what we want to do.

Chuck: I agree that there are pretty serious ramification for relatively small edit.

<mbgower> "Major changes to the web page that, if made without user awareness..."

Alastair: This could be a small erratta that doesn't effect implimentation.

<mbgower> agreed

Chuck: Issue was raised by Jake, and we have a PR (JawsTest) to address, and we do not have consensus for this PR.
... There may be another way to address this.

Alastair: Errata would be formal change.

<Rachael> draft RESOLUTION: Reject this PR and explore other solutions, perhaps an errata

<mbgower> +1

<sarahhorton> +1

<AWK> +1

<JustineP> +1

Chuck: Either way, THIS pull request is not the fix.

<Wilco> 0, would rather not explore

<laura> +1

<johnkirkwood> +1

<mbgower> I'd like to hear Jake's response to my suggestion

(vote on draft resolution)

<GN015> +1

<mbgower> I'll put it in his issue

<Ryladog> +1

RESOLUTION: Reject this PR and explore other solutions, perhaps an errata

<Fazio_> 0

RESOLUTION: Reject this PR and explore other solutions, perhaps an errata

<Rain> +1

<JF> +1

Inconsistent SCs that use "media alternative" in Guideline 1.2 #796



awk ask bruce to clarify

<Chuck_> bruce: Missed the survey, haven't refreshed my mind.

<Chuck_> bruce: This is an inconsistency that lead to a lot of thrashing at one point.

<Chuck_> bruce: Not sure if that answers the question.

<Chuck_> AWK: Who was thrashing?

<Chuck_> Alastair: Me!

<Chuck_> Alastair: When we were doing 2.1, and testing including our own site, there was a thing about sync'd media, whether it needed audio description.

<Chuck_> Alastair: Because the exception is in ...

Alastair: it was confusing people, even me

AWK: so no error, just an opportunity for confusion

<Wilco> +10

AWK: recommend addressing in Understanding or as Errata

<JF> +1 to AWK

Alastair: okay with errata
... same idea, text change not in 2.1, could be in 2.2 maybe

Chuck: am I correct to understand that your strong prefference is to avoid normative text changes unless through erratta?

AWK: Yes. There is so much tools and resources, and small edit to normative text, especially for something that changes understanding, is going to draw too much attention.

<Zakim> JF, you wanted to discuss errata versus updating Understanding doc - one is a normative change, the other isn't

<alastairc> We have changed a level in 2.2, and the titles of a couple of SC

Chuck: So we have not had to make normative SC changes yet, and this also does not seem like something worth doing except as an erratta

JohnF: Agreed, we should not be making normative changes.

AWK: I see 3 situations: 1: Understanding has changed, we need to update SC.
... situation 2 is that normative, but not changing understanding. Spelling errors, hyper links
... situation 3 is addressing by Understanding.

<Wilco> Also added "color" to 1.3.3. Which created a mess in the WCAG translations

Alastair: This strikes me as situation 2, because it has caused difficulty with people not realizing exception is hidden (one place) in the definition (but not another)

AWK: This one probably didn't come up before because just not that much experience, even ten years later, with Audio Description.

MikeGower: I think we are are actually missing a definition
... media alternative to media -- see my comment in survey
... someone could come away with impression that you need to caption your audio description
... could be something for Silver

<alastairc> I had to ask on the list to get confirmation, as a client (who had read into it extensively) was not sure: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020JulSep/0184.html

MikeGower: Weird situation wehre you can pass AAA but fail AA
... the transition from AA to AAA are not strictly additive

JohnF: I want to understand about the difference between Erratt and normative change to SC text
... I understand that we would not be changin the fundamental understanding of the requirements.

Alastair: Yes, my first hand experience with this was working with a client very interested in audio description
... and phrasing of SC being so inconsistent really tripped us up.

<alastairc> https://github.com/w3c/wcag/pull/806/files

Alastair: There is no change in the requirement, merely moves a bit of text from definition to SC

Wilco: Sychronized definition used elsewhere
... can't just pull it out and put in one SC
... this is a normative change

JohnF: prose in Understanding could also achieve the same thing.

Chuck proposes resolution

<JF> +1 to updating Understanding

<Wilco> +1

<johnkirkwood> +1

<laura> +1

<AWK> +1

<mbgower> 0

<alastairc> -1, but will build a better case

<Chuck_> 0

<Rain> 0

<JustineP> 0

<Ryladog> 0

no consensus

Sarah Horton: I am hearing an underlying question about what things rise to the level of being normative or not, and how to address

scribe: we have not really had a conversation about what things we might change and what things we cannot change
... i would vote +0 because it might be worth the conversation to decide what should be worth the attention and conversation

Chuck: Comment was that we should build a better case.
... Sarah you suggested that if we have a definition, that my guide us to decide when we can make normative changes

Sarah: It would be helpful to have better articulation as to what we are willing to look at, and what not.

<laura> s/financial and legal /financial and legal /

Alastair: Agree that it might be worth writting out more, but ultimate the group can change its mind
... There is a great deal of resistance to normative changes
... there has been been some, like SC titles
... I am voluteering to do more throurogh analysis, and bring something back to the group.

<alastairc> I had a look through those - it didn't apply

Chuck: Okay we will not be deciding on the call today.

DavidMcDonald: In the 2.0 drafting, there were many discussion about having definitions in the SC

Decision policy https://www.w3.org/2002/09/wbs/35422/ag-decision-policy-update3/

DavidMcDonald: the definition is pretty long, longer than some SC, so it makes it difficult to read.

Decision Policy

Chuck: Seeing no further comments, we will table for now.


(Chuck reads)


Chuck: Gundala asks for a full week

<alastairc> Currently 2 days

Gundala we have had surveys with only 3 or 4 days.

Chuck: W3C policy formally only requires 2 days

<alastairc> https://github.com/w3c/wcag/compare/wai-site...wai-site-decision-policy-update

Chuck: Gundala, we don't have place for that in this policy though.

Wilco and Sarah discuss miss-placed list.

Chuck: AWK asked for some adjustments

AWK: Would like to know the problem that is trying to be solved by concerns raised previously rather than raised during CFC
... seems like good concerns are good concerns

Chuck: Agreed, we are trying to give chairs another tool to move forward

Alastair: goes to trying to get suggestions and dialog sooner than later
... mostly an attempt to get people involved sooner

<JustineP> +1 to Andrew's point given that a consideration might only be realized by a participant later in the process, though I understand the rationale behind the change in language

<JF> +1 to Wilco

Wilco: seems like that sort of thing should be addressed one-on-one

Alastair: it is natural that issues raised sooner and discussed more are naturally going to have more weight and more consideration
... it makes management easier for the chairs

<JF> FWIW... https://www.w3.org/2020/Process-20200915/

<alastairc> JF - doesn't really speak to this problem.

AWK: I have some empathy about making life for chairs easier!
... It seems like there are other channel for the chairs if someone seems to be delaying or sabotaging (sp) with late comments

<Wilco> +1

AWK: Language as is seems unnecessarily harsh. Need to encourage participation does not seem like it needs to be in this policy doc.

Chuck: Understand your concern. We had a request to address this point. It might be that this doc is not the right place for the idea.

JohnF: Notes that W3C policy document is consistent with chairs descretion.

Wilco: Not going to vote against this, but I disagree with this addition.

Alastair: Thinking/talking outloud, might instead mention individual who is trying to manipulate CFC process to delay things.

<AWK> https://www.w3.org/2020/Process-20200915/#WGChairReopen speaks to W3C process to reopen decisions, and that is even after a CFC

<Rachael> Draft proposal: Remove "Objections from people who raised their concerns to the group during discussions may be weighted more than objections from people who had opportunity and chose to not participate in those discussions." and approve the other changes

<JustineP> +1 to JF and Wilco

JohnF: Seems like scenerio you describe is already addressed by policy and precedent. ad hoc solutions have been suffient in the past

<Wilco> +1

<Rain> +1

<Rachael> WE woudl also remove the related line "If the substance of the objections was raised during discussion leading to the CfC, the chairs may weight the objection more than objections which were not raised during the discussion leading to the CfC, and reasonably could have been."

Chuck: I agree with Rachael has proposed. straw poll

<AWK> +1

<JustineP> +1

<JF> +1

<morr4> +1

<Rachael> +1

<Ryladog> +1

Chairs discuss if this needs to be CFC.

<Rachael> DRAFT REsolution: Move Decision Policy to CFC with proposed removals

Chuck: any objections?

RESOLUTION: Move Decision Policy to CFC with proposed removals

<alastairc> PR for CFC: https://github.com/w3c/wcag/pull/1737/files

Summary of Action Items

Summary of Resolutions

  1. Reject this PR and explore other solutions, perhaps an errata
  2. Reject this PR and explore other solutions, perhaps an errata
  3. Move Decision Policy to CFC with proposed removals
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2021/04/13 16:59:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/ spipping/ skipping/
Succeeded: s/valication/validation/
Succeeded: s/reponse. /response. /
Succeeded: s/togeter /together /
Succeeded: s/servey/survey/
Succeeded: s/propsed /proposed /
Succeeded: s/lables /labels /
Succeeded: s/lable /label /
Succeeded: s/a differnce in lables/a difference in labels/
Succeeded: s/Cancontent /Can content /
Succeeded: s/bacically /basically /
Succeeded: s/yes thain you.//
Succeeded: s/respons./response./
Succeeded: s/thnk /think /
Succeeded: s/delinate /delineate /
FAILED: s/focusing on APIs ans /focusing on APIs and /
Succeeded: s/beyonf /beyond /
Succeeded: s/bout havaing /about having /
Succeeded: s/sysrtems/systems/
Succeeded: s/ariawg /ARIA WG /
Succeeded: s/286 comment/286 comment regarding "disabled" used in the ARIA and HTML attributes./
Succeeded: s/coment/comment/
Succeeded: s/Agree with the update with adjustement/agreed with the update with adjustment/
Succeeded: s/accessibile /accessible  /
Succeeded: s/I thing /I think /
Succeeded: s/soem /some /
Succeeded: s/alot /a lot /
Succeeded: s/tauli=ng /talking/
Succeeded: s/comforatble/comfortable/
Succeeded: s/acessibile /accessible /
Succeeded: s/definatition /definition /
Succeeded: s/redundent /redundant /
Succeeded: s/leansn/is leaning/
Succeeded: s/doen’t/doesn’t/
Succeeded: s/propriitory /proprietary /
Succeeded: s/talkingabout /talking about /
Succeeded: s/not our /It is not our /
Succeeded: s/Errata//
Succeeded: s/to having /with having /
Succeeded: s/errata//
Succeeded: s/calify /clarify /
Succeeded: s/thier /their /
Succeeded: s/ti is /it is /
FAILED: s/finanial and leagle  /financial and legal /
Succeeded: s/concensus /consensus /
Succeeded: s/a nother /another /
Succeeded: s/ans AT/and AT/
Succeeded: s/finanial /financial /
Succeeded: s/leagle /legal /
Succeeded: s/missplace list/miss-placed list/
Succeeded: s/concensus /consensus /
Succeeded: s/concerns raised rather than raised during CFC/concerns raised previously rather than raised during CFC/
Succeeded: s/involved soon/involved sooner/
Succeeded: s/straw pool/straw poll/
Default Present: sajkaj, JF, Laura_Carlson, AWK, alastairc, Makoto, Rain, julitte_alexandria, mbgower, JustineP, MelanieP, Fazio_, jeanne, sarahhorton, KarenHerr, johnkirkwood, Jennie, stevelee, Katie_Haritos-Shea, Rachael, jon_avila, bruce_bailey, Wilco, StefanS, GN, Francis_Storr, morr
Present: sajkaj, JF, Laura_Carlson, AWK, alastairc, Makoto, Rain, julitte_alexandria, mbgower, JustineP, MelanieP, Fazio_, jeanne, sarahhorton, KarenHerr, johnkirkwood, Jennie, stevelee, Katie_Haritos-Shea, Rachael, jon_avila, bruce_bailey, Wilco, StefanS, GN, Francis_Storr, morr, GN015, morr4
Regrets: Rafel Charlampowicz, Charles Hall, Nicaise Dogbo, Chris Loiselle
Found Scribe: Laura
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Scribes: Laura, bruce_bailey

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]