<Rachael> scribe: laura

RM: any new topics or members?

<AWK> +AWK

RM: (none)

Update on 3rd Party Media (30 minutes)

rm: update on 3rd party. We are not approving today.

<sajkaj> https://www.w3.org/WAI/GL/task-forces/silver/wiki/Media_Considerations

Js: we are breaking parts off and looking at media considerations.

<sajkaj> https://www.w3.org/2021/09/publishing-seminar/talk/Mussinelli

Js: webinar recently at https://www.w3.org/2021/09/publishing-seminar/talk/Mussinelli
... on how publishing group is approaching things.

<Rain> presen+

Js: we may be able to learn some things form them.
... there is congruity.
... drafting: https://www.w3.org/2021/09/publishing-seminar/talk/Mussinelli
... drafting: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Media_Considerations
... (Walking through it)
... may have techniques but not for others.
... section 2 has use cases.
... and examples of large archives.
... legacy, lack of rights, licensing agreements..
... may not have techniques.
... longest section on direction for WCAG 3
... Should say methods and not techniques.
... relatively short list.
... may be others structural navigation is impaRTANT.
... tell people what is there or not there via meta data.
... may need to bug the license holder.
... user generated think of youtube.
... may be auto generated captions.

Jf: how we can use metadata still needs to be discussed.

rm: questions?

Js: open to mail or GitHub for comments. Google docs is least favorite.

chuck: what's next?

Js: can't go forward without conformance model.
... how can we normatively reference schema is fundamental question.
... read research going back to the 1950's.
... people lipread and don't even know they are doing it.
... will be talking withe epub

<GreggVan> The best source of information on that is from Gallaudet University - where they did quantitative research on speech / video synchronization. Also for information on caption sync

Js: 26 and 28 ePub and apa will meet.
... push industry to make things accessible. And inform people.

Peter: AG needs scoring, levels and conformance.
... need broad feedback.

<Cyborg> can't seem to log into zoom, so relying on it here...

<Cyborg> (been trying for 20 minutes)

Peter: other conformance challenges beyond 3rd party.

<JF> @Cybog, try this URL: https://mit.zoom.us/j/583945521?pwd=TE9HM1BSN1N4Ri9rMHdPU3pVZ0RoQT09

Peter: we are breaking things apart. Scenario where things are intermixed.

<Cyborg> @JF - thanks! that worked.

<Cyborg> (will have to catch up later)

Peter: intermixed can be challenging.
... other items beyond 3rd party.

Jf: ePub have started putting things into a w3c repository.
... use of metadata in this context needs work.

Df: I really like this.
... helps people with comprehend content.

Gv: we had an exception in 2.0. for users in organizations.

Peter: we are moving forward with website visitors. Have already discussed this.
... important part is bound up in rights.
... there is an issue there..
... you must at least do the following... and vector back to the site.

<Cyborg> but will leave it here...can someone read it for me?

Ag: has conformance options subgroup been started?

<sajkaj> https://www.w3.org/WAI/GL/task-forces/silver/wiki/Substantial_Conformance

<Cyborg> Is there any relationship between this question and the EME question?

peter: been running for a while.
... focusing on challenges.

<JF> @Ctborg - can you expand on that?

<Cyborg> because I know that when the EME question came up with W3C there was a related question about accessibility, and the capacity to "hack media" to improve accessibility

Rm: conformance is a large topic.

<JF> @Cyborg, I think that is tangental

Rm: different subgroups looking at different topics.

<PeterKorn> "EME question" - what does that mean?

<JF> @Peter code for DRM

Cybele: is there a tie between eme and this?

<JF> "Encrypted Media Extension" - part of HTML5

js: could not pin it down. Talked with Judy about it.
... we have mechanisims.

<alastairc> We'd need to have an identified problem before we could address it.

Cybele: is it worth adding language to this proposal to address encrypted?

js: maybe.
... should be a way to push this upstream.

<alastairc> We should obviously avoid clashing recommendations, but there has been no impact on captions/audio-desc so far, which is the focus of this work.

Cybele: if no encryption, people could hack a11y on to it.

Jf: content would fall under media with limited rights for publishers.

<alastairc> We'd need to account for legal AND technical aspects, so we'd need to allow for authors who cannot modify it due to legal or encryption reasons.

Jf: thing what you are talking about is a different conversation.

<Cyborg> thanks JF - if you don't mind emailing me the material to look through, I'd appreciate it. thanks

<JF> @Cyborg: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Media_Considerations#Media_with_Limited_Rights_for_Publishers

Rm: reach out to js with follow-ups.

<PeterKorn> Thanks; dropping off now.

Rm: hold 90 minutes for next week for conformance

WCAG 2.2 Accessible Authentication (Q1-2) https://www.w3.org/2002/09/wbs/35422/wcag22-accessibile-auth/results

Rm: AA and AAA text for Accessible Authentication

<Rachael> https://github.com/w3c/wcag/pull/2042/files

Rm: In Issue 1902 wardav asks about the definition of a common object. Last week we agreed to move forward with an AA and AAA SC.
... PR 2042 has the AA and AAA version and updates to the understanding documents.

Ac: For the AAA understanding document, can we remove the bits which are identical to the AA version, and just link across at the top (like focus-appearance (enhanced) does).
... Also, I don't think we should remove the note under the current one (starting "Examples of mechanisms include: 1)...") as that was agreed previously.

<Rachael> Alastair's update at https://github.com/w3c/wcag/pull/2046

Ac: I've created an update to that branch here: https://github.com/w3c/wcag/pull/2046

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

That PR: - Removes most of the 'intent' content in the AAA understanding doc.

scribe: - Slightly re-structures the SC text (separating the exception).
... - Clarifies the new note.
... - Includes the previous note that had been removed.- Clarifies the new note.

<alastairc> Common objects and content for the exception may be represented by images, text, video or audio.

Rm: any concerns with ac's proposal?

<Fazio> they make sense

rain: comfortable but haven't read all of it.
... yes I'm comfortable with it.

<alastairc> For each step in an authentication process that relies on a <a>cognitive function test</a>, at least one other authentication method is available that does not rely on a cognitive function test, or a mechanism is available to assist the user in completing the cognitive function test.</p>

<alastairc> Exception: When the cognitive function test is to recognize common objects or content the user provided to the website.

<alastairc> (NOTE) Common objects and content for the exception may be represented by images, text, video or audio.

<alastairc> (NOTE) Examples of mechanisms include: 1) support for password entry by password managers to address the memorization cognitive function test, and 2) copy and paste to help address the transcription cognitive function test.

dm: quite a change in the note.

Ac: just added an exception.

<Rachael> https://github.com/w3c/wcag/pull/2042/files

Rm: was a mistake.

Dm: oh. Okay.
... seems like a very different note.

<Rachael> https://github.com/w3c/wcag/pull/2046/files

dm: okay.

Ac: new content in AAA version,
... (reads text.)

<Rachael> Draft RESOLUTION: Accept the updates to AA and AAA SC and understanding documents for Accessible Authentication

<Rachael> Draft RESOLUTION: Accept the updates to AA and AAA SC and understanding documents for Accessible Authentication as in PR 2046

<Ben> +1

<sarahhorton> +1

<Chuck> +1

<julierawe> 0

<ShawnT> +1

<Azlan> +1

<Rachael> +1

<mbgower> 0

<Rain> +1

Laura: +1

<Breixo> 0

<Fazio> 0

<kirkwood> +1

<Wilco> 0, with the addition that I never learned why we're making an exception for 1 type of CAPTCHA

<JakeAbma> 0

<david-macdonald> +1

<GreggVan> +1

RESOLUTION: Accept the updates to AA and AAA SC and understanding documents for Accessible Authentication as in PR 2046

<jon_avila> +1

<Chuck> 10 +1's, 6 0's

Note for WCAG 2.2

Rm: Last week we discussed adding a note to WCAC 2.2 to point readers to the coga related AAA criteria
... "Note: While WCAG AA is typically used as the standard for conformance, it is important to note that important solutions to barriers experienced by people with cognitive and learning disabilities are included in the AAA criteria. In order to support people with cognitive and learning disabilities, please consider also supporting [list coga related AAA SC]. Additional non-normative design guidance is available at Marking Content Usable for People wi[CUT]

Ac: where would this note go?
... we already have a similar note.
... suggest merging into what er already have.
... I don't think we should add a list of particular SCs at the top.

<Rachael> Note that while WCAG AA is typically used as the standard for conformance, it is important to note that important solutions to barriers experienced by people with cognitive and learning disabilities are included in the AAA criteria. Even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas.

<Rachael> Authors are encouraged to consider the full range of techniques, including the advisory techniques, and the _Making Content Usable for People with Cognitive and Learning Disabilities_ note

gv: this has morphed completely from my suggestion.
... original coga tasks on capchas were very strong. Should go into 3 but have a note in 2.2. that this is a sever barrier on the AA.

<Rachael> https://www.w3.org/TR/WCAG22/#later-versions-of-accessibility-guidelines

Ac: thanks Gregg for reminder. We could put your suggestion into understanding doc.
... can bring it back next week.

Gv: always have that info at the front.
... stuff in preamble never seen.
... thing it is very strong. Lots of 0's in the poll.

Mg: this SC bothers me from one perspective.
... forget password. That should not be part of this.

<Fazio> Also when you enter your pass ot name incorrect multiple times

<Fazio> captcha will pop up to verify you arent a bot

<Wilco> +1

Mg: any way to separate authentication from authentication.

Ac: dealing with a niche case.

<mbgower> right, NOT registration.

<Fazio> out of country

Ac: common on registration.

<kirkwood> Disagree with it being niche. “I am a human” is standard too

Ac: will come up as standard long in?

Wilco: support for mg's suggestion.

<Fazio> Im opposed to object recognition

<JF> +1 to Wilco

Wilco: captchas change. Not a good way to do this. It is not future proof.

<Zakim> Chuck, you wanted to ask for scribe change

<kirkwood> +1 to Wilco

<Wilco> scribe: Wilco

<GN015> Sorry, I have to drop.

<Zakim> alastairc, you wanted to say that the authentications after CATPCHA are likely to pass anyway

<Fazio> biosensors

Alastair: I've not been in all the conversations, but my understanding is that the likely next step are WebAuthn. We're hopefully seeing the last of CAPTCHAs. We're not quite there yet.

<Fazio> email authenticate links

Alastair: I agree it's odd to call out a particular thing. It will hopefully fall away, so it catches in scope quite a lot of CAPTCHAs.
... This just allows the last efforts of companies preventing abuse.

Rachael: We can choose to not put this in and risk objections because it's such a widely used solution, or we can move forward with this.

<mbgower> no alternative :(

Rachael: We have reasonably good consensus around this. We have no objections to the approach.

Alastair: Considering the strong opinion on either side, this is probably as good as it will get.

Rachael: We'll move forward with the note as it stands.

<Rachael> q

Rachael: That still leaves us with the question of if we should make any changes to the forward matter.

<david-macdonald> -1

<Rachael> straw poll: Should we update the note at the front? yes / no

<JF> +1 to emphasizing "Making Content..."

<Chuck> 0

<alastairc> No, Suggest we drop that forward-matter aspect, we already have a similar bit of text. Suggest adding a link to COGA-usable.

<JakeAbma> +1

<kirkwood> +1

<Rain> +1 to emphasizing Making Content Usable

<AWK> 0

<mbgower> 0

<Ryladog> +1

<sarahhorton> +1

<ShawnT> 0

+1

<Breixo> 0

<KarenHerr> +1

<Detlev> -1

<Ben> 0

<david-macdonald> Note: not going to fall on my sword

<mbgower> I like Gregg's suggestion of language in the AA SC clarifying the shortcomings of object recognition

Rachael: The question of if the front-matter should be updated to point to content usable.

<Chuck> 2 -1's, 6 0's, 8 1's

<GreggVan> 0

Detlev: Agree with Alastair, don't think we need to tackle that.

<laura> 0 I like Gregg's suggestion of language in the AA SC clarifying the shortcomings of object recognition

<Ryladog> Mine is not a huge objection

<GreggVan> most important is to have not on SC only update front if alastair thinks it is helpful

Rachaeh: Any objection to adding a link to content usable?

<Ryladog> Mine was +1

<Fazio> Its a Note

David: What's the status of Content usable?

<GreggVan> +1

Rachael: It's an informational document. Should come out as a more readable web version in the future.

David: I just don't want organisations to think that we're signalling to include that in their policy.
... Organisations should do it voluntarily.
... We don't want to send the signal that we want policy makers to implement this.

<alastairc> "Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, _COGA usable_, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far

<alastairc> as possible, to this community. Metadata may assist users in finding content most suitable for their needs. "

Alastair: It would be straight-forward to add, it was well vetted.

<Rachael> draft RESOLUTION: Accept Alastair's proposed text.

<david-macdonald> +1

<sarahhorton> +1

<Chuck> +1

+1

<Ryladog> +1

<Rachael> +1

<Azlan> +1

<KarenHerr> +1

<Fazio> 0

<Detlev> +1

<Breixo> +1

<Rain> +1

<JakeAbma> +1

<kirkwood> +1

<ShawnT> +1

<julierawe> +1

<laura> +1

RESOLUTION: Accept Alastair's proposed text.

WCAG 2.2 Focus visible (Q1-6) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

<laura> s/lare topic/large topic/

Update Technique G195 procedure #1931

<Rachael> https://github.com/w3c/wcag/pull/2004/files

Rachael: Mike suggested updates to the techniques, along with a new technique.

<laura> s/mechanisims /mechanisms /

<mbgower> I didn't create it that way :)

Rachael: We have general consensus, with editorial adds.

Alastair: Trying to understand GN's point on allowing it to blend.

Mike: Where it's 2 pixels thick, it creates a wider border. Even if it matches the original text, it's thicker.

Gregg: Two pixels is not sufficient change in the size of something to notice it.
... If it's the only button it doesn't get larger, if it's immediately next to another button it's barely noticeable.
... Larger buttons is not a solution to a provision that there must be contrast.

<mbgower> Not sure I want to go back trhough all the scenarios again :)

Alastair: In the context of focus indicator we found that 2 pixels around buttons, even if the color is the same as the button is reasonably noticeable.
... For the purpose of this change, I think this matches what the SC is asking for.

<mbgower> Focus appearance.

<AWK> I knew a WCAG chair who might have said "perfect is the enemy of the good" in this situation... :)

<alastairc> https://github.com/w3c/wcag/

Gregg: For people with low vision, 2 pixels is not sufficient. It's noticeable to use.

<alastairc> https://github.com/w3c/wcag/issues/new

<alastairc> Sorry, slightly more-direct

Mike: The SC has scrutiny, including people with low vision. This is about the focus indicator.

<Fazio> growth/expansion is a great method of attentional capture

<Fazio> its been scientifically proven

Rachael: We're going to focus these conversations about what is in the survey. The SC has been discussed, this conversation is about the technique.

<Fazio> yes/no

Gregg: I agree the technique matches the SC. Attention gathering doesn't work with screen zoom, if the button just is larger, they have to remember what it used to be.

<alastairc> Gregg - we've been through this already

<alastairc> Tangent...

Fazio: I do research on abrupt visual onset, as long as it's in the peripheral, it automatically captures attention.

<Zakim> Chuck, you wanted to say that there is definitely interest in this topic, but not related to the question.

<GreggVan> agree with Fazio -- but doesnt work if zoomed in and button is offscreen

<Zakim> alastairc, you wanted to say that I think Gundula was thinking of the AA version

Alastair: I think GN might have been thinking of the AA version, in the AAA version adjacent contrast is not included.

<Rachael> draft RESOLUTION: Accept technique update with Patrick's edits and changing the color from red to another color

<GreggVan> Sorry for side track to the SC language. Will post comment there

<ShawnT> +1

<Chuck> +1

<david-macdonald> 0

<GreggVan> +1

<alastairc> +1

<Ryladog> +1

<Ben> +1

<JakeAbma> +1

<Rachael> +1

<sarahhorton> +1

<Breixo> +1

<kirkwood> 0

<Azlan> +1

<Fazio> 0

<GreggVan> 0

<Rain> +1

<jon_avila> 0

<Chuck> 12 - 5

RESOLUTION: Accept technique update with Patrick's edits and changing the color from red to another color

Make clearer the method of calculating the minimum area #1883

<Rachael> https://github.com/w3c/wcag/issues/1883#issuecomment-906471738

Rachael: This was about using CSS box model terminology.

Alastair: Someone came from the CSS perspective, from their view it would help to define the area in box-model terms.
... It would make things more complicated. If something doesn't have visible padding, it doesn't help to define it.

Rachael: All 8 reviewers agreed

<Rachael> draft RESOLUTION: Accept the response

<Rachael> suggested rewording to be clearer: The AG WG discussed, and we do not think it would be helpful to relate the calculations to the CSS box model.

<Chuck> wilco: Is there a reason we are not motivating the response, explaining why...?

<Chuck> wilco: not giving a rationale.

<Chuck> rachael: I think there was more information related in the response. Does that meet the motivation?

<Chuck> wilco: I think I missed it.

<Chuck> back to you wilco

<Rachael> The AG WG discussed, and we do not think it would be helpful to relate the calculations to the CSS box model. The visible boundary of the element (if there is one) is more important than whether the boundary is at the edge of the content, padding, or border. The figures in the sizing area now have pixel values, and those talking about contrast have hex values.

<Rachael> any objections?

<Chuck> no

RESOLUTION: Accept the response

Sizing impresise and fairly complicated #1718

<Rachael> https://github.com/w3c/wcag/issues/1883#issuecomment-906471738

Alastair: My main point is that it would allow for a lot of very small focus indicators.
... To allow for smaller but thicker contrast indicators, you need two methods of making the calculation. Otherwise you either catch too much or not enough.
... The other comment was on bounding box vs perimeter. I would not be opposed to that.

<Rachael> Possible text change in the SC from “the area of a 1 CSS pixel thick perimeter of the unfocused component” to “ the area of a 1 CSS pixel thick line around minimum bounding box of the unfocused component”

<Chuck> wilco, I can scribe if you want to deeply engage.

Gregg: Trying to make sure I understand. What is minimum bounding box?

<alastairc> https://w3c.github.io/wcag/guidelines/22/#focus-appearance-minimum

Alastair: Here's the definition.

<kirkwood> minimum bounding box is confusing langage

Alastair: Where the perimeter is not easy to work out you can draw the smallest rectangle around the shape

Gregg: If I put a focus around the bounding box, does that mean there is a gap?

Alastair: This is about the area of the bounding box.

Gregg: Does that says it counts if you grow the component by one pixel?

Alastair: If you have a contrasting focus indicator, then the minimum area can be a 1 pixel perimeter.

Rachael: The preference so far is to keep perimeter.

Gregg: So this could be a spot above the component?

<AWK> Gregg, if you have a focus that appears around a control that would pass. If the area of that 1 px perimeter is 23 pixels^2 then you can also use that area to determine if the size of a spot added to the component as a focus indicator.

<mbgower> It helps to look at the Understanding document

Alastair: The understanding document has lots of examples

Rachael: What we're looking at here is whether to change the word perimeter to minimum bounding box.

<alastairc> The 'bounding box' change didn't seem to click with people, so we can probably just discard that.

<mbgower> I'd like to keep perimeter

<mbgower> the focus indicator

<Chuck> wilco: If it helps... I suggested perimiter, so you can have a circle w/ 1 line pixel around it. That's 1xpi which is smaller than 4.

<Chuck> wilco: You need to be able to pass that.

<Rachael> draft RESOLUTION: accept the proposed response and keep "perimeter"

<mbgower> +1

<kirkwood> +1

<GreggVan> +1

<Ben> +1

<AWK> +1

+1

<ShawnT> +1

<alastairc> +1

<sarahhorton> +1

<Chuck> +1

<Breixo> +1

<Rain> +1

<Detlev> 0 (prefer boundary box but can live with both)

<david-macdonald> +1

<laura> +1

RESOLUTION: accept the proposed response and keep "perimeter"

<Ryladog> +1

Rachael: It may be worth having a meeting to give an update on this SC. Reach out to the chairs if this is something you're interested in.

<Ryladog> Thank you Gregg!!

<mbgower> https://github.com/w3c/wcag/issues/created_by/GreggVan

<mbgower> I'm not seeing any ^

<alastairc> probably on WCAG 3?

Adobe Comment on 2.4.11 Focus Appearance (minimum)

<Rachael> https://github.com/w3c/wcag/pull/2000

Rachael: Andrew raised this, we have a PR for this.

<Azlan> Apologies - I have to leave.

Rachael: Alastair suggested that the PR addressed the issue. AWK suggested something else.

AWK: I can go along with it, but what I feel is being said here is. I want to express concern with the ease with which humans can understand what this is saying.
... One part about the shape, it references the area, but then the area includes a mention about that it can't be less than 2 pixels.

Alastair: If you have a 1px ouline, it should contrast with the component, or be at least 2 pixels thick. You can have indicators like crescents on either side of a button which is of a variable thickness. You could also have things like gradients, which make it bigger, but does not meet 3:1 everywhere.
... This is saying it shouldn't be thinner, although if you did have it, if that's not contributing to the area we're assuming it's not there.

<kirkwood> Need a plain language version of this.

AWK: Every time I come back reading this, it takes a long time to re-understand it. That is the core of this comment.

<mbgower> see the next question :)

<alastairc> Any outline that is at least 2px thick and contrasts with the non-focused state would pass this criterion. The detail in this document is for people who do not wish to use such an outline.

Alastair: I can't really argue with that, if we want to tackle this problem, this is the best way to do it.

AWK: I think the underlying concern is something I expect we'll get additional comments around.

David: We receive a lot of criticisms for complicated SCs.

<ChrisLoiselle> If it worthwhile, Low Vision Task Force is working on supplemental guidance, so if it fits within https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Supplemental_Guidance_List, perhaps that is an avenue moving forward for clarity ? Just a suggestion. Understood that SC should be clear as can be.

Rachael: Does it make sense to dedicate one of the Friday meetings to this?

<Detlev> Dont open that can of worms, we'll never get anywhere...

<Chuck> wilco: I should point out that the suggestion I made for 3 CSS pixels simplifies this significantly. There is a potential solve. There's a balance we are doing. Do we want to cover a big thing well, or squeeze and simplify.

<Zakim> Chuck, you wanted to express concerns about relitigating past progress

<GreggVan> pointer to proposal?

Chuck: I'm not opposed to us reviewing this, but am concerned that the effort we've put forth can be undone by rehashing all of this.

<Rachael> sc at https://w3c.github.io/wcag/guidelines/22/#focus-appearance-minimum

My proposal: https://github.com/w3c/wcag/issues/1718#issue-851678497

Alastair: We haven't got better wording to achieve the same thing. Wilco's I disagree with because the common case gets harder to calculate
... It would let things pass that I don't think we'd want to let pass.

<mbgower> there are still survey questions left. It's not being closed

Gregg: This is the one I was commenting on before, I would like to suggest we not close this, if we haven't answered the question.
... I would like to ask that we take time to look at it further.

Rachael: We'll come back to this topic.

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/lare topic/large topic/
Succeeded: s/caption were/capchas were/
Succeeded: s/withe epub/withe epub/
FAILED: s/lare topic/large topic/
FAILED: s/mechanisims /mechanisms /
Succeeded: s/Talk with /Talked with /
Succeeded: s/followups./follow-ups./
Succeeded: s/re-authenication /authentication /
Succeeded: s/authenication./authentication./
Succeeded: s/people/reviewers/
Default Present: Chuck, Rachael, sajkaj, Fazio, Breixo, Laura_Carlson, PeterKorn, garrison, ShawnT, kirkwood, ChrisLoiselle, sarahhorton, alastairc, Azlan, Francis_Storr, AWK, Ben, Joshue, MelanieP, Lauriat, Léonie, (tink), JF, Detlev, julierawe, Rain, KarenHerr, jeanne, Nicaise, stevelee, Jemma, Wilco, GreggVan, david-macdonald, Cyborg, jon_avila, JakeAbma, Katie_Haritos-Shea, mbgower
Present: Chuck, Rachael, sajkaj, Fazio, Breixo, Laura_Carlson, PeterKorn, garrison, ShawnT, kirkwood, ChrisLoiselle, sarahhorton, alastairc, Azlan, Francis_Storr, AWK, Ben, Joshue, MelanieP, Lauriat, Léonie, (tink), JF, Detlev, julierawe, Rain, KarenHerr, jeanne, Nicaise, stevelee, Jemma, Wilco, GreggVan, david-macdonald, Cyborg, jon_avila, JakeAbma, Katie_Haritos-Shea, mbgower, Joshue108, Léonie (tink)
Found Scribe: laura
Inferring ScribeNick: laura
Found Scribe: Wilco
Inferring ScribeNick: Wilco
Scribes: laura, Wilco
ScribeNicks: laura, Wilco

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


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.)