<Chuck_> egrets: Charles Hall, Nicaise Dogbo, Steve Lee

<laura_> Scribe: Laura

<laura_> Scribe: Laura

Timezone changes

<Chuck_> https://lists.w3.org/Archives/Member/chairs/2020OctDec/0011.html

Chuck: Reminder on time zone changes.

<AWK> +AWK

Check the web page for details.

<alastairc> E.g. for me in the UK, it's 3pm next week, but 4pm now and in November.

Decision policies for Siler & COGA TFs

scribe: couple of Decision policies

<Chuck_> https://www.w3.org/WAI/GL/task-forces/silver/decision-policy

<Chuck_> https://www.w3.org/WAI/GL/task-forces/coga/decision-policy

scribe: Silver and COGA

<Zakim> bruce_bailey, you wanted to discuss editorial suggestion

scribe: will be putting up for CFC so we don't have to rehash decisions.

Bruce: shouldn't use upper case for "and"

<sajkaj> +1 to bb

<alastairc> suggest also spelling out "tag" in the COGA doc, not everyone will know that acronym.

Bruce: it is in the COGA one

RM: I'll take care of out.

Pre-CFC Silver, final comments

<Chuck_> https://w3c.github.io/silver/guidelines/

Chuck: lot of work by content editors.
... hope we are there. Have done a lot of work.

Wilco: what has been changed in the last week or two?

RM: most are changes as discussed on this call.

<MichaelC> Suggest looking here for diff: https://github.com/w3c/silver/commits/master/guidelines/index.html

RM: clean up things.
... I can send a list of changes.

MC: link to a Dif: https://github.com/w3c/silver/commits/master/guidelines/index.html

<alastairc> Given the re-structuring, a lot of a "diff" would look like it has changed, but it hasn't really...

MP: appreciate the editors notes.
... the one in the conformance section don't ask for input.

Rm: we are asking for feedback. It is not set in stone.

<Rachael> "We seek feedback on whether this flexibility will be beneficial in encouraging content providers to meet conformance because it is more achievable or whether content providers are less likely to improve accessibility if they aren't required to."

MP: (reads note)

<Rachael> https://w3c.github.io/silver/guidelines/

RM: will add a sentence.

Bruce: Access Board has hired technical writer who is looking for news articles

MC: formal review going into January

WCAG 2.2 Dragging issues https://www.w3.org/2002/09/wbs/35422/wcag22-dragging-issues/

Will be reviewing some changes for dragging.

<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-dragging-issues/results

Dragging on mobile apps #1307

<alastairc> Draft response: https://github.com/w3c/wcag/issues/1307#issuecomment-678176499

Gundula: We have some technology dependent techniques, so why not having this one for native iOS apps?

<Zakim> alastairc, you wanted to talk about scope

AC: can't add because it is out of scope for out charter.

Gundula: need to rewrite it anyway.

MC: we are planning to update WCAG to ITC

DM: through WCAG to ITC doc.

Gundula: I can live with the response.

<david-macdonald> EN301549 in EU references native apps through the WCAG2ICT rather than directly

<AWK> Thank you for your comment. While applying specific assistive technology settings like assistive touch on iOS may alleviate the dragging problem for some users, these options are not universally available and @@would@@ not qualify as Sufficient Technique for a wider accessibility baseline covering different platforms and user agents. @@That said, until WCAG2ICT is updated to provide non-normative advice on how to apply WCAG 2.2 to native applications, WCAG

<AWK> 2.2 is not intended to apply to native mobile apps.@@

awk: proposed response, "Thank you for your comment. While applying specific assistive technology settings like assistive touch on iOS may alleviate the dragging problem for some users, these options are not universally available and @@would@@ not qualify as Sufficient Technique for a wider accessibility baseline covering different platforms and user agents. @@That said, until WCAG"

<alastairc> +1

<Fazio> +1

<Sukriti> +1

Laura: +1

<sarahhorton> +1

<Sukriti> +1

<juliette_mcShane> +0

<AWK> +1

<Fazio> +1

<bruce_bailey> +1

<JakeAbma> +1

<Wilco> +1

<kirkwood> +1

<Ryladog_> +1

<MelanieP> +1

<GN015> 0.5

ja: concerned we may be setting a precedent.

<Ryladog_> "Until User Agents" raises its ugly head.....

Dm: we could soften it a bit.

<alastairc> Last sentence proposal: "That said, until WCAG2ICT is updated to provide non-normative advice on how to apply WCAG 2.2 to native applications, the group @@has not provided any guidance@@ on applying the SCs to native mobile apps."

<Glenda> I agree with David and Jon about softening this statement

Dm: could say new SC have not been vetted for mobile.

<bruce_bailey> +1 to DM suggestion

<kirkwood> “may not apply” ?

<Glenda> +1 to “the new SCs to native and mobile apps”

<AWK> +1 to AC's edit

<Chuck_> That said, until WCAG2ICT is updated to provide non-normative advice on how to apply WCAG 2.2 to native applications, the group @@has not provided any guidance@@ on applying the new SCs to native mobile apps.

Dm: (Wordsmithing)

<david-macdonald> +1

<AWK> If we are going to that level of specificity we should mention WCAG 2.1 and 2.2 SC

<Chuck_> POLL: Accept Detlev's response to 1307 with modifications

<Fazio> Is this for all 2.2 sc’s

Ac: yes. to Fazio this for all 2.2 sc’s

katie: talked about updating with Judy.
... we need to update but need to coordinate with Judy and others.

<Zakim> bruce_bailey, you wanted to say this is an important caveat

Bruce: regulators might take up 2.2 prematurely.

<Chuck_> POLL: Accept Detlev's response to 1307 with modifications

<bruce_bailey> yes, That said, until WCAG2ICT is updated, the group has not provided any guidance on applying the new SCs to native mobile apps."

<Chuck_> +1

<Wilco> +1

Laura: +1

<Francis_Storr> +1

<bruce_bailey> +1

<JakeAbma> +1

<Sukriti> +1

<Fazio> +0

<GN015> +1

<alastairc> This comment is specific to the issue raised

<laura_> chuck: just applying to 2.2

<bruce_bailey> yes, 2013 version is most recent and was the last and only version

<laura_> chuck: WCAG2ICT is not being ignored.

RESOLUTION: Accept Detlev's response to 1307 with modifications

Adding the word "Pointer" to "2.5.7 Dragging" #1397

<bruce_bailey> https://www.w3.org/TR/wcag2ict/

<laura_> chuck: SuzanneTaylor on github asks in issue 1397 if the word "Pointer" could be added to clarify the scope of the SC. However, after discussion Detlev suggested "Dragging Movements" because it chimes with "Pointer Gestures".

<laura_> Gundula: I agree with the name change that is not the point.

<laura_> … I feel the explanation on pointer gestures and dragging are hard to understand. The latter seems to be discussed in both this question and the next one, as both issue 1397 and 1398 point to PR #1423 .

<Zakim> alastairc, you wanted to say it was separated to help decision making...

<laura_> ac: appreciate the structuring of it.

<laura_> … covered in the next couple questions.

<laura_> chuck: Stefan said: “Pointer Gestures never drag a physical object on an UI. IMHO, this is the difference since the term "dragging" involves exactly this movement. Therefore, no additional wording is necessary.”

<Zakim> alastairc, you wanted to say there are other scenarios as well

<laura_> ss: don’t think it needs clarification. But you can prove me wrong.

<laura_> ac: more scenarios. covers dragging that is not a redefined gesture.

<laura_> .. see the point to differentiate it from the pointer gestures.

<laura_> … I don’t have not a strong opinion it.

<laura_> ss: feels it is a bit redundant.

<Chuck_> POLL: Accept adding the word "Pointer" to Dragging

<Chuck_> POLL: Are people ok with changing title to Dragging Movements.

<sarahhorton> +1

<laura_> mg: wasn’t original issue that she wanted pointer?

<alastairc> +1

<laura_> ac: yes. but we had discussion with her.

<GN015> +1

<Chuck_> +1

<laura_> Laura: +1

<Sukriti> +1

<mbgower> meh

<Raf> +1

<juliette_mcShane> +1

<Fazio> +1

<Ryladog_> +1

<kirkwood> +1

<MelanieP> +1

RESOLUTION: Approve changing title to Dragging Movements.

Relationship/overlap between 2.1's "Pointer G

Relationship/overlap between 2.1's "Pointer Gestures" and 2.2's "Dragging" #13

Chuck: @patrickhlauke on github asks in issue 1398 for some more explanation of why Pointer Gestures and Dragging are different, where their overlap is, and what makes one be a level A and the other a AA, would be necessary here.
... Detlev provided some changes for the understanding document in PR 1423.

GN: The current explanation is mathematical and very hard to understand.
... In the understanding for 2.5.1 it says: "A path-based gesture involves an interaction where not just the endpoints matter. ", which is easy to understand.

So for dragging only the endpoints matter, while for path based pointer gestures at least one intermediate point matters. If this understanding is correct, I suggest to say so.

scribe: what is this trying to tell me?

AC: suggest a small update.
... will work on it.

Cross-reference Dragging and Pointer Gestures in Understanding #1316

Chuck: Wardav on github suggests in issue 1316 that it would help to differentiate the two SCs better.
... Detlev provided a Pull request to provide that cross reference.
... everyone agreed.

<Chuck_> POLL: Accept PR 1334 to address 1316

Laura: +1

<Ryladog_> +1

<bruce_bailey> +1

<juliette_mcShane> +1

<Fazio> +0

<david-macdonald> +1

<JakeAbma> +1

<Fazio> lol

<sarahhorton> +1

RESOLUTION: Accept PR 133416 to address 1316

Relationship/overlap between 2.1's "Pointer Gestures" and 2.2's "Dragging" #1398

<alastairc> Proposed 1st sentence: "A dragging movements is a pointer interaction where only the endpoints matter. Once the pointer engages with a target, the target (or a position mark related to the target) will follow the pointer regardless of the direction of the pointer movement."

<david-macdonald> typo movement(s)

Ac: second sentence hasn't changed.

<david-macdonald> tak the plural off the first "movement"

<Chuck_> POLL: Accept PR 1423 to address Issue #1398 with Alastair's modifications

<sarahhorton> +1

<alastairc> The whole diff: https://github.com/w3c/wcag/pull/1423/files#diff-cd021394f819834793f964417026464e1451bfd474bad7b490caa6338b51b8f2

<Raf> +1

Laura +1

<Ryladog_> +1

<Sukriti> +!

<Sukriti> yes

<david-macdonald> +1

<Sukriti> haha

RESOLUTION: Accept PR 1423 to address Issue #1398 with Alastair's modifications

<GN015> +1

<Zakim> mbgower, you wanted to say is it possible for me to talk to something already resolved (from today)? It isn't critical, but i would like to hear thoughts on the larger issue of the

MG: spent time looking over the 1st question.
... Suggestion for when we go back to the previous topic "A dragging movements is a pointer interaction where only the endpoints matter. Once the pointer engages with a target, the target (or a position mark related to the target) will follow the pointer regardless of the direction of the pointer movement."
... We say that Assistive Touch is not an acceptable support because it is not universal. What if it was?
... Also, IF there is a mobile device that offers no simple single pointer affordances for all its functionality, then a user who isn't able to operate their entire device without simple single pointer operations has bigger things to worry about than not being able to operate an author-created dependency on a single web page!
... I thought a main argument on this not applying to the OS gestures was that it only applied to author-created gestures which deviate from the OS-allowed ones. _Every user_ is still going to have to invoke a drag (or at minimum directional flick) to 'page down' to move their viewport, for instance. We're not requiring authors to resolve that.
... I can see us getting in an odd situation here where every touch-OS provides affordances for single-touch drag and drop, and yet we continue to insist author's solve this. The analogy would be making authors responsible for key repetition and a bunch of other keyboard operation simplifiers offered at the OS level which can be piggy-backed by any web author.
... Someone in a response cited Mouse Keys as an example of where we don't allow an OS support to overcome a requirement for Keyboard, but that is not the rationale regarding mouse keys. It is not allowed as a keyboard equivalent because it "looks like a mouse to the application". It isn't an equivalent argument. Here, we are discussing pointer interaction, so OS-level accessibility features for pointers are relevant.
... I get the value of encouraging authors to offer simple, single pointer actions. But does this SC become redundant when hardware providers are required to provide single-touch mechanisms? When are we placing undue burden on an author for a common interaction already solved by an elegant accessibility setting at the OS level?
... do worry about this.

AC: think accessibility supported may be one way this has been dealt with before.
... how much do we assume that a person would have the AT?

Mg: seems to be a fallacy.

ac: gets into complicated territory.

Mg: happy to let it go.

<bruce_bailey> +1 MG it is an important point

chuck: could raise it as an issue on GitHub.

<MelanieP> q

Katie, "until user agent" rears its ugly head. It is an important discussion.

bruce: agree it is important.

Melanie: agree.

<mbgower> scribe: mbgower

WCAG 2.2 Pointer Target Spacing Issues (Questions 1 & 2 only) https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/

Updated proposal for "Target Size"

<Chuck_> https://docs.google.com/document/d/1gl0XVAY66jpBXphDR_VbbtjsJZfC_vvDJCMa_17SR2U/edit

Chuck: MATF has proposed new version of the SC
... 5 agreed; 5 agreed bu wanted something else; 2 didn't agree

<GN015> would you mind sending a link to the questionnaire with results?

<Chuck_> The size of the target including the space around target is at least 24 by 24 CSS pixels…

Sarah: I included a proposed change

<Zakim> alastairc, you wanted to talk about definition of target

alastairc: The google doc didn't link through the definition, but the target defines it as the interactive area.

Sarah: I'm trying to conceptualize it. So the sentence is 'the size of the target including the space around the target'
... I thought we were just talking about the target, not the space in between the targets.

alastairc: I thought we weren't talking about spacing either. We've been through a few iterations.

Chuck: It looks like they've retained it.

Alastairc: I can summarize Patrick Lauke's comment.
... he's saying that 24x24 is somewhat arbitrary.
... He measured some things in CSS pixels, and it came out between 7 and 10 mm. So there is variation.
... He mentioned this is factored for touch, but mouse and trackballs have not been considered.
... he could find some links that would need to change. Also, he feels there are workarounds for users -- zooming in.

<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results

Alastairc: He's wondering if the rationale is enough for AA.

Gundula: Can't comment because she feels that it's not finalized.
... She cites different issues in her response.

Alastairc: The Google document does provide a point of discussion. If we can agree with the new version, we go back to those commenters.

Gundula: Because we answered different issues with different versions, it is inconsistent.

Alastairc: We discussed some in previous surveys, so it is only question 1.

Gundula: I do not feel that 1433 (?) is resolved.

Sarah: I already spoke to some earlier. The first one about the space around the target.
... That still needs to be clarified

Sukriti: The overall recommendations that comes from MATF is to avoid the really bad cases.
... The results was 6.5mm. We wanted to prevent the really poor cases.
... That is not a lot of cases.
... The intent was not allow overlapping space.

Alastairc: My comment was less about process and more about 'is there a useful SC?'
... Is it the shared spacing we were trying to get rid of?

Sukriti: Yes.

Alastairc: I think we may need some wordsmithing, then.
... I think that would resolve most of the issues I pointed to
... If we go down to 24px that is the smallest of any benefit according to the research. It would catch the tiny little crosses on advertisments.

Chuck: If those content updates were made, how much are Gundula's issues addressed?

Alastairc: The issues she raised around spacing would be resolved.
... For the comments on the user agent, I can't see that as an issue...

<Sukriti> 2.5.8 Target Size (AA) The size of the target including the space around the target, where space between adjacent targets cannot overlap is at least 24 by 24 CSS pixels except when: Inline: The target is in a sentence or block of text; User Agent Control: The size of the target is determined by the user agent and is not modified by the author; Essential: A particular presentation of the target is essential to the information being conveyed. Note: [CUT]

Alastairc: I think we've resolved most of them other than the user agent one, with the assumption we update wording to say we don't share spacing.

<Chuck_> SUGGESTED RESOLUTION: Update content and review later.

Alastairc: I would like to come to some resolution to see if we think it's a valid route.

<Chuck_> +1 valid step to go down to 24 pixels.

Alastairc: 24 pixels with no shared spacing.

Wilco: When is something "in line"?
... I think that is a trickier question. When is something a block of text?

Alastairc: I'm trying to remember what we had defined... Essentially, if you have text around it in the same layout element, then I think that would qualify as a block of text.

Sukriti: Links in the middle of text is the context.

Chuck: Does the group still think it's worth pursuing?

Alastairc: I think that covers David's point inthe survey.

Sukriti: I agree with Alastair. If it is less than 24, it's not worth discussing.

<Chuck_> POLL: valid step to go down to 24 pixels?

Sukriti: I've included text about spacing.

<sarahhorton> +1

<Wilco> +1, assuming we can come to a better description of inline

<kirkwood> abandon

<JakeAbma> 0

<alastairc> +1 amended so spacing is not shared

Katie: I do. We have not done enough for mobility issues. I don't see how 24 pixels is appropriate.

Chuck: So are you supporting 24 or saying it's not sufficient?

Katie: 24 is not sufficient.

Wilco: There is already a requirement that content can be resized a substantial amount.

<Zakim> alastairc, you wanted to described issues raise with 44

Alastairc: I got on queue to respond to katie, but I'll respond to Wilco first. Resizing can assist some people. But there are some people who don't use swtich access, but struggle with hitting a small target, who find resizing difficult.
... There are situations where resizing is difficult and target size is important.
... Katie, the kinds of issues we've been hitting are toolbars. We had a complaint from a user that if we required less density, once someone zoomed in, they would have less objects available.
... It starts to feel like something resovled through personalization.

<kirkwood> +1 to point of playing one group off another. and zoom issue of forcing the reducing info when zooming in

Katie: It seems to me that if it's low vision, it might be someone using AT. Generally a mobility issue, in many cases, are people who are elderly and less apt to be using an AT. Low vision is important, but our ability to address motility and mobility has got to get more robust.
... It wasn't on the radar enough in the past.

<kirkwood> +1 to Katie

<Fazio> +1 important for stroke survivors like me

<Chuck_> mg: What to do with statement on resizing. An entire website will appear in my mobile device, smaller than one point text. Every single target will not make the minimum.

<Chuck_> mg: I'm assuming that this gets resolved by reflow. but I have a q on ... what happens where the page is not reflowed properly?

<Chuck_> mg: Are we covered by reflow where that can't take place?

<Chuck_> alastair: You would fail reflow.

<Chuck_> alastair: That sounds like a website without a meta statement.

<Chuck_> mg: What is that failing? If it doesn't fail reflow... maybe we have that as a technique. I don't know that this is requiring that meta statement.

<Chuck_> mg: If we are ok saying that this is a failure, then I'm ok, but it is a strange outlayer.

<Chuck_> alastair: It is an interesting question. I don't think we need to address this in text. They could still meet this if the targets were 24 pixels. It wouldn't help people using a smaller device, but that would also fail reflow.

David: I wanted to flip back to Wilco

<kirkwood> This should be abandoned.

<alastairc> SC would start "2.5.8 Target Size (AA) The size of the target including the space around the target, where space between adjacent targets cannot overlap is at least 24 by 24 CSS pixels except when:"

Chuck: Does anyone feel this isn't worth the effort?

<kirkwood> +1

Alastair: John are you able to comment?

<kirkwood> sorry i think it shoud be abondoned

<kirkwood> -1

<JakeAbma> 0, -1

Alastair: Where we started with 44, we have a lot of issues.
... It's a large sweeping change.

<bruce_bailey> wow, 44 -> 24 is going backward

David: I want to rewind on that. Wilco made a comment earlier that there could be a benefit to zoomers.

<Ryladog_> There are points i between 24 and 44

David: I don't know if there is. Would it make sense to explore that and come back?

<kirkwood> don’t think there is a benefit it ‘zoomers’

David: I don't see 24 is much use. It will be a lot of testing.
... But if we help zoomers, that is the last straw I can grab at. We'd have to pitch it that way.

Chuck: I don't know that is was specific to zooming, and they found 24 was the 'sweetest spot'.
... If you're asking for more research, taht puts it out of the scope of 2.2

Sukriti: We did discuss about enabling zooming, which gets us better.
... We chose 10% error rate, and that's where the rationale came from.

<Zakim> bruce_bailey, you wanted to affirm that sites are going below 24 px

Wilco: What are the concerns? Why is 24 better than nothing?

<kirkwood> correct

<jon_avila> +1 It does address the worst cases. Maybe in the understanding doc we could put a statement indicating the that this only addresses the tip of the challenge of users with mobility needs - just like we have contrast minimum.

Bruce: 24 is still a nubmer that websites are not meeting. Having a low bar is okay. It's still a low bar/hurdle.

<Sukriti> +1

<sarahhorton> +1

Chuck: I"m hearing some folks say it gives us something.

<alastairc> I posted a comment about the motivations we've been through, in order: 1) Large target sizes so they are easy to hit; 2) Target size + spacing to reduce the chance of making an error; 3) Prevent very small targets.

<Zakim> alastairc, you wanted to speak to motivations

Alastairc: I posted something in another issue awhile ago. Initially we wanted large targets sizes.

That's where the AAA came from in 2.1.

The rationale this time was to reduce errors of people hitting the wrong target.

<jon_avila> reducing errors is good because recovering from errors such as navigation are difficult.

Alastairc: The 24 pixels prevents very small targets. it will make A difference. If this is pitched as the minimum bar, 'where possible do more' that's where the Android and iOS guidelines go.

Stef: 48 and 44 dp targets are what are listed by Android and Apple.

Alastairc: Yes, but if you look at their own sites, there are many cases where they go below that.
... They are working with "should" and we are working with "must"

<kirkwood> defer

Chuck: I'm hearing voices from both sides about whether to defer.

<alastairc> Who would object to continuing at 24px

<Sukriti> https://material.io/design/layout/spacing-methods.html#spacing - material guidelines with status bar 24 dp

<Ryladog_> +1 to David

David: Would it makes sense to put it out for draft, and get reaction?

<laura_> keep if we have volunteers to work on it.

Alastairc: We have half a dozen issues that can't be addressed without this. We're suggesting putting this out and asking for responses from those issue creators.
... It may be a curve ball, but... Do we really need the spacing aspect of this at all, given we're going down to 24 px.

Wilco: I think we need the spacing. You want to allow for margins and padding to be part of that.

Alastairc: Padding would be part of the target but not margins, in CSS.

<alastairc> "2.5.8 Target Size (AA) The size of the target is at least 24 by 24 CSS pixels except when:"

Sukriti: Wilco's point is what we were considering. Removing spacing would also work.

<Chuck_> POLL: Defer or Keep Trying

<JakeAbma> -1, 0, 1

<Wilco> Keep trying

<sarahhorton> Keep trying

<kirkwood> defer

<Ryladog_> Keep

CHuck: Either put in the word "defer' or "keep"

<jon_avila> keep

<bruce_bailey> Keep trying

keep

<Sukriti> keep

<david-macdonald> keep trying put it out there

<alastairc> For the minutes: Wilco's point was that it's harder to implement without the spacing aspect.

Kirkwood: I really don't see how it's possible. We're trying to relate real world sizing to digital sizing. We can keep trying, but I do not see how it's possible.
... It's going to make it difficult for people to understand priorities.

Sukriti: Most major websites are already half way there. I don't think life easier for designs is our goal.

Kirkwood: I'm talking about making it easier for cognitive disabilities.

Sarah: I think Wilco said some things about inline text. I'm still voting for keeping, but thinking about what we're getting stuck on.

<kirkwood> user agents handle this very well

Alastairc: I think it is worth coming back with another go. Refining what we have so far.
... Now that it's down to 24, I don't think it would impact how people design interfaces. ti would affect what they put in them.

Kirkwood: Things have evolved. I feel like we're beating a dead horse.

RESOLUTION: Continue working and review later.

How do input labels impact spacing requirements? #1432

Alastair: The definition of target meets this. Patrick was pointing out that browsers do taht, but it isn't a technical requirement.

Katie: We have someone who is going to be joining the working group.
... I would like to introduce him next meeting.

<Fazio> bravo katie

Sarah: If our intention is to make the control target sufficiently large, it should be the control, not the control plus label.

Gundula: I would add assumptions. I suggest we stop the second sentence earlier.

David: Is there any browser that doesn't let you activate the label?

<Zakim> alastairc, you wanted to propose an update

Alastair: I was going to propose an update based on comments.
... if they form one target, they can be included in the calculatoin, and include user agent support.

<GN015> @mbgower: is said I would add targets, if they experience as one for the end user.

Wilco: Radio buttons and checkboxes are 13 pixels in diameter. if we don't include labels, they will all fail.

<alastairc> Sorry, didn't realise Chuck was host!

<david-macdonald> looks like the hard stop

<kirkwood> gye! ;)

<alastairc> We will have to come back to that later!

<Ryladog_> LOL

<alastairc> Thanks Michael, I'll send around the minutes

trackbot, end meeting

This is scribe.perl Revision of Date 
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/an employee/technical writer who is looking for news articles/
Succeeded: s/the EU may be up taking/regulators might take up/
Succeeded: s/Coga/COGA/
Succeeded: s/It it /It is /
Succeeded: s/it it out /it is out /
Succeeded: s/stucturing /structuring /
Succeeded: s/yoou /you /
Succeeded: s/senarios/scenarios/
Succeeded: s/opnion /opinion /
Succeeded: s/disscuion with /discussion with /
Succeeded: s/is not resolved/is resolved/
Succeeded: s/inlcluded/included/
Default Present: Laura, sajkaj, Chuck_, Francis_Storr, MelanieP, Raf, alastairc, MichaelC, AWK, Wilco, Levon, JakeAbma, kirkwood, StefanSchnabel, sarahhorton, Sukriti, Katie_Haritos-Shea, Glenda, Fazio, david-macdonald, Caryn-Pagel, bruce_bailey, mbgower, !, PeterKorn, jon_avila, GN
Present: Laura sajkaj Chuck_ Francis_Storr MelanieP Raf alastairc MichaelC AWK Wilco Levon JakeAbma kirkwood StefanSchnabel sarahhorton Sukriti Katie_Haritos-Shea Glenda Fazio david-macdonald Caryn-Pagel bruce_bailey mbgower ! PeterKorn jon_avila GN GN015
Regrets: Charles_Hall Nicaise_Dogbo Steve_Lee
Found Scribe: Laura
Found Scribe: Laura
Inferring ScribeNick: laura
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Scribes: Laura, mbgower
ScribeNicks: laura, mbgower

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