W3C

- DRAFT -

AGWG Teleconference

18 Jan 2022

Attendees

Present
alastairc, shadi, Azlan, janina, JakeAbma, Rachael, bruce_bailey, SuzanneTaylor, sarahhorton, Fazio, Jen_G, jeanne, Lauriat, AWK, JF, garrison, kirkwood, Raf, Detlev, MelanieP, Jemma, david-macdonald, GreggVan, Laura_Carlson, Nicaise, Wilco, stevelee, Katie_Haritos-Shea, jon_avila, ToddL, .5, Francis_Storr, mbgower, GN, GN015
Regrets
Jaunita George, Jennie Delisi, Rain Michaels
Chair
Chuck
Scribe
Fazio, bruce_bailey

Contents


<Chuck> meeting: AGWG-2022-01-18

Meeting Start (Scribe, Introductions)

<alastairc> scribe: Fazio

<AWK> +AWK

<scribe> scribe: Fazio

<scribe> New topics = none

WCAG 3 Project Plan

<Rachael> https://github.com/w3c/silver/wiki

Rachael - transparency concerns, content findability concerns, keeping pace with necessary schedule is a concern

Project plan increasdes visibility

Rachael - Wiki page is core of the plan

Rachael - Key Points: foundational work, scoring, content creation, guidelines

Rachael - projects divided into milestones divided into stages

Rachael - milestones help for organization but aren't permanent

Rachael - organization is being documented by wiki

Rachael - each milestone has a wiki page, same basic template.

Rachael - Wiki is github linked

<Jemma> + 1 to note key decusuibs argreed on!

<Jemma> s/decisions/decesions/

Rachael - Use wiki to document key decisions.

Rachael - Stages are based on process discussed in October 2021

<Detlev> Rachael could you repost the URL

Rachael - Github issue mapping is still in process

stages are in process doc

Judy - I'm happy

<mbgower> great work!

Judy - POC info is important standard for continuity across all W3C work

JF - I'm happy to see the clarity and transparency too

JF - why is conformance and scoring separate

Rachael - it seemed like a natural grouping

Shadi - I'm happy too

<Rachael> Note: Add the email for ag-plan to all group POCs

Shadi - are their parts that need to be achieved before re-chartering?

<Zakim> bruce_bailey, you wanted to ask about Edit Mode drop down

Rachael - I don't know

Bruce - I'm happy too

Bruce - curious asbout backend

<alastairc> If anyone is confused by (or wants) the black background, that's a setting in github: https://github.com/settings/appearance

MC - slightly different than traditional wiki, all features are github standard

Gregg - I'm happy too

Gregg - It's approachable in understandable. Under guidelines (alphabetical order) I suggest sorting by POUR. It keeps things that are related together.

Gregg - re-sorting helps reduce confusion during re-naming

DM - Watershed moment. Everything is coming together better. Wiki was great idea

Janina - can we get pointers to the rules? What's different?

<AWK> GitHub wiki markup: https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

<MichaelC> https://github.github.com/gfm/

MC -I will find a doc link. Preview exists to help

<MichaelC> https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

<Azlan> I'm going to have to drop off. I'm having connectivity issues. Will catch up when the minutes are shared.

<Zakim> Chuck, you wanted to comment on POUR

<Zakim> jeanne, you wanted to say that they are done in MediaWiki

Chuck - organizing by POUR is intriguing. How much do we want to attach to WCAG 2.x or a new standard? We need to consider

<alastairc> If we used categories, I'd suggest a different set of categories.

JS - syntax is done in media wiki

JS - need to choose media wiki as format

<Rachael> https://github.com/w3c/silver/wiki

<Zakim> bruce_bailey, you wanted to say that it seems to that syntax is tied to the page not the authors preference

Bruce - Syntax is page creators choice, not user-editors choice

<Zakim> Jemma, you wanted to ask how other subgroups like protocol group will be added to project plan (or protocol is not subgroup)?

Jemma - how are subgroups documented in project plan?

Rachael - organized by milestones not subgroups. Multiple groups may be involved in a milestone or multiple mile stones

Rachael - Groups that want a page can request one from Rachael and/or Jeanne

Rachael - a lot of content is already available in Silver wiki

<Jemma> Can you share "milestone page" example link or protocols page itself is the mileston page?

WCAG 3 Issues - Survey https://www.w3.org/2002/09/wbs/35422/wcag3/

Question 1 - 380 - Question on Clear Words Revised

<Chuck> https://www.w3.org/2002/09/wbs/35422/wcag3/results

AK - difficult to say yes or no until additional conformance issues are decided

AK - Alastair response is ok, but no might be better, or not sure

<mbgower> +1 to AWK

laura - agrees with andrew and john

<JF> https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/clear-words/#develop-button

JF - how to section says inline dictionaries need to be keyboard accessible. It's way too early to comment on this guideline

I agree with JF!!!!

Guideline is misdirected

<ToddL> +1 to JF

<jon_avila> I agree with Andrew as well.

<Chuck> proposed RESOLUTION: Accept AWK's response to address issue 380

Alastair - agree with Andrew. user agent tools are not sufficient currently. This content is exploratory. Issue still needs to be closed though.

Alastair - standard response is needed

JF - don't understand the point. basically responding on a hypothetical is problematic

MG - add info to dev technique page, that dev tech alone won't be sufficient

<mbgower> That seems like a good stock response for many things

<mbgower> "progresses"?

<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag as discussed

JF - Guideline might not even make the cut. So using the term "matures" doesn't make sense. Too many issues with it

JF - putting it in for the sake of being able to revise is a problem

Alastair - levels of maturity are part of the guideline approval process

<Jemma> +1 to alastair

JF - Mike Gower's term progresses is a better statement

Chuck - me too

<JF> +.5

<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag as discussed

<mbgower> I guess "progress"?

<Jemma> +1

<Ryladog> +1

<AWK> yes, "pregress"

<AWK> "progress"

<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag with input-for-future-version

<bruce_bailey> comma after progresses (before we)?

<sarahhorton_> +1

<Chuck> +1

<bruce_bailey> +1

<ToddL> +1

<kirkwood> +1

<Rachael> +1

<JF> +.5

<mbgower> +1 with grammatical tweaks

<alastairc> +1

<AWK> +1, but without Bruce's comma :)

<jeanne> +1

<Detlev> +1

<laura> +.5

<Lauriat> +1

thx for the typing break

<Raf> +1

<Rachael> Draft text for resolution: Thank you for your comment. The Working Group has concerns that current implementations may not fully meet user needs, and as the WCAG 3.0 conformance model and this method progress we will work to clarify whether or not this will be sufficient. We are closing this issue but are adding a label (input-for-future-version) to ensure the group considers your point as we move forward and look at techniques.

<Chuck> proposed RESOLUTION: Accept amended response to address issue 380, and tag with input-for-future-version

RESOLUTION: Accept amended response to address issue 380, and tag with input-for-future-version

<bruce_bailey> s/s/

Question 2 - 169 - Consider "accessible name" instead of "alternative text"

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag3/results#xq3

Alastair - How does alt text and accessible name fit in wcag 3?

<Chuck> I will process queue once I have gone through the responses that request "something else"

<Jemma> +q to ask the context of the issue to wilco

text alternative seems to be preferred by more people

get ready for scribe change btw

AK - nothing to add

Laura - agree with Rachael

<Zakim> JF, you wanted to comment on Leonie's response

JF - terminology depends on your role.

<Jemma> I am sort of agree with Leonie and wilco's point but concerned about how users will easily understand the concept of accessible name.

<alastairc> accname applies beyond images though

<Zakim> Jemma, you wanted to ask the context of the issue to wilco

<Wilco> Context: https://www.w3.org/TR/wcag-3.0/#text-alternatives

<JF> +1 to Jemma

<bruce_bailey> +1 to JF suggestion for parenthetical -- i.e., accessible name in the DOM

JF - Jemma - accessible name maybe difficult to understand

Jemma - who do I contact to raise issue

Janina - we need to get this right. Possibility for misunderstanding. Need a global standard for this topic

Janina - big difference from accessible name and info summary, but both are text alternatives

<Zakim> mbgower, you wanted to say they're not synonymous

<GN015> +1 to Mike

<bruce_bailey> +1 to MG that that Accessible Name is synonym for alt text

<alastairc> New suggested response: https://github.com/w3c/silver/issues/169#issuecomment-1015619337

MG - text alternative and accessible name are not synonimous

I spelled that wron :(

wrong

<bruce_bailey> scribe: bruce_bailey

Wilco: alt text might be super set of accessible name,

<Jemma> Jemma agree with the "accessible name" concept because it can cover more but I see the challenge how this radical change will be accepted to not techcial users.

Wilco: suggest definition list or add terms or glossary

<Fazio> Wilco - defintion needed to make difference clear between text alternative and accessible name

Wilco: also , it might be that wcag3 not require text alternatives -- because it outcome based

<Zakim> Rachael, you wanted to ask if we should rework this or pass it back to the subgroup?

Wilco: so if the outcome is that end user gets information, might not mention alternative in outcome per se

<Zakim> Chuck, you wanted to say that John's suggestion seems to get us closer

Rachael: sounds to me like feedback might need to go back to sub group

chuck: i think i agree we need to see where we should go

<Fazio> scribe change please

Alastair reads his reply from github issue

<Rachael> Option 1) Send feedback back to the group. We think "text alternative" is the better terminology. Consider adding definitions that distinguish between accessible name and text alternatives. Option 2) New suggested response: https://github.com/w3c/silver/issues/169#issuecomment-1015619337

<alastairc> https://github.com/w3c/silver/issues/169#issuecomment-1015619337

<Chuck> https://github.com/w3c/silver/issues/169#issuecomment-1015619337

chuck gives straw poll

alastair: is short, group should continue to refine turn

<Rachael> 2

<Chuck> 2

chuck straw poll

<mbgower> 2

<AWK> 2

<jeanne> either is fine

<alastairc> 2

<Raf> 2

<ToddL> 2

<JF> 2

<Detlev> don't know

<kirkwood> 2

<Rachael> subgroup

chuck: clarifies who gets work

<Chuck> proposed RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on textual alternatives for additional review

<Rachael> +1

<Rachael> +1 to mg text alternative

MG: advocate for text alternative over textual alternative (since the latter is new)

<Chuck> +1

<JF> +1 with "text alternatives"

straw poll on proposed resolution

<Rachael> +1 if changed to text alternatives

<ToddL> +1

<kirkwood> +1

<jeanne> +1

<janina> +1

<Francis_Storr> +1

<laura> +1

<Raf> +1

RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review

<mbgower> +1 with preference for no "textual"

<JakeAbma_> +1

<mbgower> been updated already :)

JF: but want text alternative over textual alternative

janina: might ask group to consider

<Chuck> proposed RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review

<laura> +1 to preference for no "textual”. It is simpler.

<janina> +1 to GV. That was my concern precisely

gregg: this is not going to final language, we might consider textual just because it sounds good, but it is not plain language because it is not a real word

RESOLUTION: Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review

<janina> Suggest we not sacrifice precision on the altar of plain language

Alastair: this a response providing sub group with information, this will be coming back to AG WG...

<Jemma> +1 to GV and further more we are trying to minimize the confusion rather than moving onto "accessible name".

Alastair: better to tackle wordsmitting then

Question 3 - 257- Meaningful Text Alternatives

https://www.w3.org/2002/09/wbs/35422/wcag3/results#xq5

https://github.com/w3c/silver/issues/257

Chuck reads from survey

This guideline should state up front that a "meaningful" text alternative is required, rather just a text alternative...

scribe: We will keep your points in our mind.

6 agree, 6 something else

Chuck: reads from survey replies

Bruce from survey..escriptive Identification -- which is decidedly *not* an equivalent text alternative -- is (sometimes) not only sufficient but the best practice.

Tink from survey:I do not agree with this response. I think it's important to include an adjective in the guideline itself, though I would use "appropriate" instead of "meaningful", for the reasons stated in the proposed response.

Alastair: My concern was between the guidline text and page

It does appear that the issue-poster was asking for an update to the guideline text, not the title.

Detlev (from survey): I think it is currenty difficult to solve this for Silver since the granularity of guidelines overall is not clear yet....

A draft of all guidelines and how they divide the cake would be needed for this. I suggest to postpone answering.

JF: I don't agree that focus is on title [explains]

MG (from survey): I would like to advocate that the existence of a text alternative be one requirement, and that the quality of the text alternative be another requirement. Not only Is the first much easier to confirm through automation, but the existence of the alt is an implementation check, while the quality of the alt is a design check.

AWK (from survey): A nice short guideline is desirable, but "Guideline: Provide text alternative for non-text content." could benefit from the addition of equivalent: "Guideline: Provide equivalent text alternative for non-text content."

Larua Carlson: I agree with suggestion from AWG and MG.

Chuck: People seem to be agreeing with AWK and MG, but not sure where that leaves the response.

MG: Previous discussion was more towards to stock response ... but want more feedback from group ...

<Rachael> the best way to capture additional things woudl be to add an issue and tie it to the milestone

MG: but for future work we need a consensus respones

chuck summarizes and mike agree

<alastairc> Suggested poll: Should the guideline include an additional adjective such as meaningful/equivelent/appropriate? Y/N

<mbgower> N

chuck, this might help us tie work to outline we reviewed at top of call...

scribe: i dont feel like we are exactly close to that at the moment

<alastairc> "Provide text alternative for non-text content."

<Chuck> poll: Should the guideline include an additional adjective such as meaningful/equivelent/appropriate? Y/N

Alastair: It seems to me we should be able to tie this response closer the the guideline as in...

and return back to subgroup, maybe address in the next draft

scribe: so just make that suggestion to subgroup?

<JF> a HUGE +1 to @mgower

<janina> +1 to Mike

Mike Gower: Current approach, with machine assessment and 1.1.1 and need for quality, we need to tackle this gap with wcag3

<AWK> +1 to Mbgower

scribe: so i would really like for us to get closer to quality with wcag3 guideline

<Rachael> I don't think we know quite yet but I think adding that as an issue woudl be useful

<mbgower> I don't know :)

Alastair: so is quality this guideline or a new and different one?

JF: I agree with MG response, and passing feedback to text alternatives subgroup...

<Zakim> Rachael, you wanted to asnwer

seems unanswered.

<mbgower> opening an issue

<Chuck> proposed RESOLUTION: Return the issue to the team working on the response, and consider an adjective, and consider separating requirements.

Rachael: It is worthwhile we are addressing this, and we have similar aspect with other guidelines

chuck proposes resolution, reflecting what we are hearing

three things in proposed resolution,

<Chuck> +1

<janina> +1

<Rachael> +1

<laura> +1

<jeanne> +1

<JF> +1

RESOLUTION: Return the issue to the team working on the response, and consider an adjective, and consider separating requirements.

Question 4 - 457 - ITI Comments on flexible conformance

https://www.w3.org/2002/09/wbs/35422/wcag3/results#xq9

Chuck reads from survey.

From ITI: ...it will be difficult for policy makers to understand what conformance levels can be reasonably expected for technologies to attain that can be included in regulations. More clarity in the specific proposals is needed to give a more detailed response to the question.

See issue: https://github.com/w3c/silver/issues/457

4 agrees, two something elses

JF: ITI issue is not complexity but need for complexity.
... also reference to "group voting" is not correct, its is just that AG WG has not gotten consensus

Laura Carlson: also agree with deferring on response

AWK: the way question is phrased, ITI is asking for flexible conformance model...
... so this answer to question prompted, not ITI per se

<alastairc> +1, they aren't requesting a specific change, they are stating a wish to have 1 conformance model.

Chuck: If AWK interpretation is correct, is response as-is?

AWK agrees that response is okay in that regard

Chuck ask if JF agrees with AWK reading of ITI comment?

<alastairc> They said "There should be one model for conformance, based on rating and scoped by documenting the sampling, processes, and any other testing performed with an easy way to calculate the conformance level."

<laura> +1 to jf

<janina> +1 to JF

JF: Agree w/ how characterized ITI comment, but our proposed response is still off.

<janina> We might say we're trying to minimize complexity while contemplating flexibility

<laura> we need a stock reply for these.

Alastair: Proposed response to complexity is further down in there comment. I am not sure what more we can do with comment.

<alastairc> Thank you for your ideas. The Silver Task Force agrees with you that we do not want to make the conformance too complicated. We are closing this issue but are adding a label input-for-refinement to ensure the group considers your point as we move forward.

JF: Agree with most of response, but would just remove comment in middle about complexity.

Alastair proposed (shorter) response.

<Chuck> proposed RESOLUTION: Accept amended responses to address issue 457

Chuck reads, and proposes ammended response for straw poll.

<laura> suggest changing move forward to progress

RESOLUTION: Accept amended responses to address issue 457, and tag issue as input-for-refinement

<janina> It's still addressing complexity, though

JF: Alastair response still emphasis for complexity rather than flexibility.

<Jemma> "If it is too complicated, it will be difficult for policy makers to understand what conformance levels can be reasonably expected for technologies to attain that can be included in regulations. More clarity in the specific proposals is needed to give a more detailed response to the question."

<janina> They want flexibility without complexity

Alastair: ITI comment concludes with concern for complexity.
... Balance is needed, as more flexibility likely to mean more complexity.

<Chuck> Thank you for your ideas. The Silver Task Force agrees with you that we want to make the conformance more flexible and not too complicated. We are closing this issue but are adding a label input-for-refinement to ensure the group considers your point as we move forward.

Janina: We are working hard to make that balance.

<jeanne> jeanne: They are responding to the a SotD question on flexibility. Their comments are about complexity.

Chuck reads.

<janina> +1 to Chuck

<JF> +1

Alastair: agree that ITI had concern for complexity

<Chuck> +1

<alastairc> +0.5 and move on

<Rachael> +.5 I can live with it

<JF> +1

<jeanne> +1 to move on

<Jemma> +1

<janina> +1

<Chuck> proposed RESOLUTION: Accept amended responses to address issue 457, and tag issue as input-for-refinement

RESOLUTION: Accept amended responses to address issue 457, and tag issue as input-for-refinement

chuck that is 3 issues

WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Alastair: given time left today, we will focus a little bit...

Size basis for focus-appearance

<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq32

Alastair: please see update

<alastairc> https://docs.google.com/document/d/1aW5BHq0hzKlOmU8wrB0OLipVmcg-SfT5MqU1BhNzqYs/edit

Alastair: also have discussion document

What do we use for basis of size? Outlines, other focus indicators...

What are they measured against?

This issue was focus of Friday call, and include feedback from Wilco.

<alastairc> "Note: In HTML the size of a component is measured up to and including the CSS border."

Component term implies perceived size, but elements like "button" is not enough

we came up with a new note, the html css border aligns with target size

<Jemma> s/componet term/user interface component/

scribe: this approach gives a concrete target

<Zakim> JF, you wanted to suggest The Silver Task Force agrees with you that we want to make the conformance model flexible.

Chuck: That recent work does focus on component (per survey) but this has an additional change.

<alastairc> SC: "When a component receives keyboard focus, an area of the focus indicator meets the following"

Alastair: yes, this is recent not enough to be in a PR proposal
... Friday we talked about "perceptual size" but also get at discrete measurement

Wilco: i have other concern for this SC, but not being able to measure accurately was my main concern...

so problem area reduces. As written, this might be limited to markup languages.

<Chuck> proposed RESOLUTION: Carry on with the current approach, focused on 'component'. Accept yet to be created PR that amends the first sentence of the SC to "When a component receives keyboard focus, an area of the focus indicator meets the following…"

Alastair: We also had conversation about bounding box as fall-back measurement.

chuck reads proposed resoultion.

Alastair: CFC soon, and CFC will include note.

Wilco: As Melony mentioned, Chrome will soon have user setting to expose focus. Is that impact this?

Alastair: We discussed recently, but conclude implementation (in Chrome) has significant limitations.

Wilco: Is that a normative change though?

Alastair: No, because user-agent solution is not enough.

<alastairc> Wilco, see https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html line starting "The default focus indicators..."

Gundaula: Are we deciding on final wording now?

<alastairc> Note: In HTML the size of a component is measured up to and including the CSS border.

Alastair: Not, replacing note and adusting opening phrasing.

Gundula: Seems out of sync with some other proposed SC phrasing.

Alastair: We have another survey itme on that detail.

<Chuck> proposed RESOLUTION: Carry on with the current approach, focused on 'component'. Accept yet to be created PR that amends the first sentence of the SC to "When a component receives keyboard focus, an area of the focus indicator meets the following…" and update note

<mbgower> https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html

Mike Gower: We have a long history for resize text, and when UA is enough. That phrasing is part of the Understanding document, not normative text.

Wilco: I would like to see PR before straw poll.

<alastairc> https://docs.google.com/document/d/1aW5BHq0hzKlOmU8wrB0OLipVmcg-SfT5MqU1BhNzqYs/edit#

Alsastair: change is in above doc, with yellow highlight

<Jemma> trying to understand creating PR makes what difference....

Chuck and Alistair agree they have phrasing correct.

<alastairc> proposed RESOLUTION: Carry on with the current approach, focused on 'component', tweaking the SC text to make clearer the basis for size

Alastair: looking to get feedback on most recent approach

<Jemma> +1

<Chuck> +1

<alastairc> +1

<Wilco> -.5

<mbgower> +1

<GN015> +1

<Rachael> +1

<Detlev> +1

RESOLUTION: Carry on with the current approach, focused on 'component', tweaking the SC text to make clearer the basis for size.

<GN015> I do not agree to base on the CSS border.

<JF> bye all

<ToddL> +1

Wilco and Gundula have concerns

<Jemma> html section is the note.

Gundala: proposed css measuring is novel

Summary of Action Items

Summary of Resolutions

  1. Accept amended response to address issue 380, and tag with input-for-future-version
  2. Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review
  3. Accept Alastair's response to address issue 169 and send back to the team working on text alternatives for additional review
  4. Return the issue to the team working on the response, and consider an adjective, and consider separating requirements.
  5. Accept amended responses to address issue 457, and tag issue as input-for-refinement
  6. Accept amended responses to address issue 457, and tag issue as input-for-refinement
  7. Carry on with the current approach, focused on 'component', tweaking the SC text to make clearer the basis for size.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2022/01/18 18:00:01 $

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)

FAILED: s/descusibs/decesions/
Succeeded: s/descusibs/decisions/
Succeeded: s/I'm happy/I'm happy to see the clarity and transparency/
Succeeded: s/Syntax is owners choice not user/Syntax is page creators choice, not user-editors choice/
Succeeded: s/version [08:45] <bruce_bailey> comma after progresses (before we)?/version/
Succeeded: s/[08:45] <bruce_bailey> comma after progresses (before we)?//
Succeeded: s/accepted/accepted to/
Succeeded: s/Alastair reads  his reply from survey/Alastair reads his reply from github issue/
Succeeded: s/on textual alternatives for additional review/on text alternatives for additional review/
Succeeded: s/three things in PR./three things in proposed resolution,/
Succeeded: s/liver/live/
FAILED: s/componet term/user interface component/
Succeeded: s/concrete targe/concrete target/
Succeeded: s/That phrasing is not part of this SC/That phrasing is part of the Understanding document, not normative text/
Default Present: alastairc, shadi, Azlan, janina, JakeAbma, Rachael, bruce_bailey, SuzanneTaylor, sarahhorton, Fazio, Jen_G, jeanne, Lauriat, AWK, JF, garrison, kirkwood, Raf, Detlev, MelanieP, Jemma, david-macdonald, GreggVan, Laura_Carlson, Nicaise, Wilco, stevelee, Katie_Haritos-Shea, jon_avila, ToddL, .5, Francis_Storr, mbgower, GN
Present: alastairc, shadi, Azlan, janina, JakeAbma, Rachael, bruce_bailey, SuzanneTaylor, sarahhorton, Fazio, Jen_G, jeanne, Lauriat, AWK, JF, garrison, kirkwood, Raf, Detlev, MelanieP, Jemma, david-macdonald, GreggVan, Laura_Carlson, Nicaise, Wilco, stevelee, Katie_Haritos-Shea, jon_avila, ToddL, .5, Francis_Storr, mbgower, GN, GN015
Regrets: Jaunita George, Jennie Delisi, Rain Michaels
Found Scribe: Fazio
Inferring ScribeNick: Fazio
Found Scribe: Fazio
Inferring ScribeNick: Fazio
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Scribes: Fazio, bruce_bailey
ScribeNicks: Fazio, 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]