<Rachael> https://www.w3.org/WAI/GL/wiki/Scribe_List

<ChrisLoiselle> scribe:ChrisLoiselle

<Chuck> scribe: Chuck

<Rachael> scribe: ChrisLoiselle

Vacation schedule check in for June and July

Rachael: Two holidays coming up. June 19th and July 3rd. Any other holidays to cancel potential meetings for?

<Chuck> no concerns

ChrisLoiselle: I am on vacation on July 6th through 10th, unable to scribe :(

WCAG 2.2 Normative Changes https://www.w3.org/2002/09/wbs/35422/2020-05-cwa/results

Update to Redundant entry

Rachael: WCAG 2.2 Normative changes, update to redundant entry. 6 responses total.

<Rachael> For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either: auto-populated, or available for the user to select. Exception: When re-entering the information is essential.

<Fazio> We settled this early on

<Rachael> Proposed Revision: For information entered by or provided to the user in a process, at least one of the following is true. The information is: not requested a second time; or auto-populated; or available for the user to select. Exception: Re-entering the information is essential.

Rachael: To Alastair, did you want to add anything to that?

Alastair: I did try to adjust the technique procedures to match. Which hopefully covers Gundula's question. We can talk to Wilco's when we get there.

Rachael: Reviewing DavidM's comments. No suggestions on rewording, we can wait till he joins.

Pascal: Reading through the agenda, talks to normative changes. Would like to know what text was changed. I.e. a "diff".

<PascalWentz> https://raw.githack.com/w3c/wcag/wcag22-redundant-entry-nodef/understanding/22/redundant-entry.html

Rachael: Are you opening RESULTS OF QUESTIONNAIRE NORMATIVE ANSWERS TO WCAG 2.2 GITHUB ISSUES MAY 2020?

<Rachael> REsults of the questionairre: https://www.w3.org/2002/09/wbs/35422/2020-05-cwa/results

<Rachael> Original Text: For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either: auto-populated, or available for the user to select. Exception: When re-entering the information is essential.

Pascal talks to https://raw.githack.com/w3c/wcag/wcag22-redundant-entry-nodef/understanding/22/redundant-entry.html, which is the update. Rachael: The original text can be found here: Original Text: For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either: auto-populated, or available for the user to select. Exception: When re-entering the information is essential.

Steps have been removed.

Alastair: I'm attempting to set up a diff for everyone and will paste to chat.

<alastairc> https://github.com/w3c/wcag/compare/wcag22-redundant-entry...wcag22-redundant-entry-nodef

Pascal: I would like to review diff on changes , i.e. left and right hand side of pages to review changes.
... That is helpful, thank you.

<Zakim> alastairc, you wanted to say that I think David was right, copy paste is ok.

DavidF: To DavidM's point, we didn't mean to talk to copy / paste. I don't have a better way to word it either. Also, on not having steps, thats ok too. The main objective is to not enter information multiple times.

Alastair: On steps, we were struggling to get to a definition of "steps". We ended up taking "steps" out due to that issue with definition of steps.

<Zakim> mbgower, you wanted to say what was the rationale for removing steps? What does it gain?

Alastair and DavidF: Talk to point of use, readily available. Alastair: If we aren't rolling it out, then we could talk to DavidM's comment that copy and paste wasn't intended but we can talk to it.

<JF> +1 to Mike. "A step" is a generally understood process, despite a specific definition

<Fazio> Doesn't a process by definition have steps?

MikeG: Why do steps need to be defined? It is a generic term, that provides overall context of the SC. In removing it, the scenario of step process, why would we be removing?

<kirkwood> +1 to Mike

Rachael: Was it a CfC rejection?

Alastair: It was a late objection.

DavidF: How far does step go, i.e. what is the scope of a step?

<mbgower> steps

<Fazio> Steps

<kirkwood> steps

Rachael: Do you prefer direction of steps or removing steps? Please place the word steps or no steps

<OmarBonilla> steps

<JakeAbma> steps

<JF> steps

<Detlev> +0

<laura> +0

<alastairc> +0 don't mind

<Chuck> +0

<mbgower> -1

<Fazio> -1

<Chuck> -1

<JF> 0

<alastairc> -1

<OmarBonilla> 0

Rachael: Plus 1 is steps needs to be defined if we leave it in the text.

<kirkwood> +0

<JakeAbma> 0

<Rachael> Does steps need to be defined? +1 yes, -1 no

<Detlev> -1

<Brooks> +1 I think it needs to be defined

<laura> 0

Alastair: I think we need to either explain it in understanding or we try to define steps, which may be a dead end based on pages being defined , etc.

Rachael: To Brooks, on why you want to have it defined?

<mbgower> 2.4.5 Multiple Ways

<mbgower> More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Brooks: I'd be concerned on scope of what a step would be. Steps that are separated in time, i.e. sign up for one service, then signing up for another sub-service. Is it a user session or spread out over time. What is the step definition?

<Zakim> mbgower, you wanted to say it is already innormaltive text and to say it is already in normative text (undefined)

MikeG: Talks to multiple ways text that talks to "steps".
... Why would we need to clarify now ?

DavidF: A company would need to define that the process or step is essential rather than re-entering redundant entry information. Point of SC is to avoid re-entering all that information.

JF: Would it help about talking toward continuous steps?

<Zakim> alastairc, you wanted to say that steps isn't needed to achieve the goal

<Fazio> essential could be the way out

<Fazio> completed the process is the desired outcome

Alastair: I was happy not including word steps as we were talking to that in the process definition.

<mbgower> https://www.w3.org/TR/WCAG21/#dfn-processes

Rachael: Would steps in a process work for you Brooks?

<mbgower> Yes, we had these questions before, Brooks. It's a legitimate question.

Brooks: Yes, where you define steps in a process. I.e log in using "X" platform, will that information be fully brought over to another service you are logging into ?

<mbgower> Alastair, is the objection text/rationale linkable?

<Fazio> we discussed crossover and were ok with it crossing sites, pages, forms, apps

Chuck: The first question there was consensus on including steps. One second question was not defining steps. So I think the decision is to include steps but not define it .

Rachael: On the call, at least.

<kirkwood> against removing steps

Rachael: Can anyone not live with us removing steps?

<alastairc> mbgower - https://lists.w3.org/Archives/Public/w3c-wai-gl/2020JanMar/0284.html

Pascal: I have a problem with the new text. It talks to any process. The first the one says steps in a process. I would prefer original statement vs. the new one that is more general.

Rachael: I propose steps being in the SC text, but without a definition.

<Rachael> Proposal: Move forward with original text that included steps

<alastairc> Pascal - process is a defined thing for us: https://www.w3.org/TR/WCAG21/#cc3

<Rachael> Original text: For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either: auto-populated, or available for the user to select. Exception: When re-entering the information is essential.

MikeG: Was process linked originally?

<Rachael> +1 for moving forward with original text with link to process and steps undefined

Alastair and DavidF: I think was originally, but then changed to steps in a process.

<kirkwood> +1

<alastairc> 0

<Nicaise> +1

<Chuck> +1

<laura> 0

<Fazio> +1

<JakeAbma> +1

<Brooks> 0

<GN015> 0.5

<Francis_Storr> 0

<mbgower> +1

<JF> 0 leaning +1

<MarcJohlic> +1

<OmarBonilla> 0

<Detlev> +1

RESOLUTION: move forward with original text with link to process and steps undefined

<PascalWentz> +1

Rachael: Talks to confirmation of password field and being essential and needing to be fixed.

Alastair: I don't agree with that statement , as repeated password for security it comes through on that end. Process being completed without repetition? It may be worth adding a clarification on that. Andrew talked to that I believe.

<Zakim> mbgower, you wanted to say I disagree :)

MikeG: The re-statement of email or password is to help user to fix potential error. It could be listed as part of being essential.

<Rachael> Andrew's comment: Perhaps we need a note that re-entry for security verification (e.g., credit card number) or accuracy (e.g., contact email) is regarded as essential?

<Zakim> AWK, you wanted to ask what I've said

AWK: When resubmitting information, I re-enter things such as credit card, or email address for contacting or phone number. I think it could be abused in that all form information is essential.
... If we ask for credit card information, do we need to repopulate the second time? We need to make that use case clear.

DavidF: Talks to routing number / account number re-entering and fatigue and memory issues. It may be up to provider implement.

Rachael: Is everyone ok with adding a clarifying note on essential?

<Nicaise> +1

<kirkwood> +1

<alastairc> "Security verification, such as repeating a password, is considered essential."

<laura> +1

<PascalWentz> +1

<GN015> +1 fine with it

<jon_avila> +1

<Brooks> +1

<Chuck> +1

<JakeAbma> +1

<JF> +1 to "Security verification, such as repeating a password, is considered essential."

<david-macdonald> +1

<Francis_Storr> +1

Rachael: We have decided to move forward with original text and also include a note on essential.

<alastairc> Going back to: https://raw.githack.com/w3c/wcag/wcag22-redundant-entry/understanding/22/redundant-entry.html

AWK: Where is the current text we are talking to? Ok, yes that was what I was talking to.

<Fazio> yes

<Fazio> I originally said at point of use

For information entered ...at least one of the following is true, is available for the user to select, is how I read this. The second and third bullet don't talk to redundant. So that is where my comments were based on. I.e. does first bullet impact second and third bullet?

<alastairc> For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either:

<Rachael> Original Text: For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either: auto-populated, or available for the user to select.

Alastair to AWK: We did talk to changing this. Rachael: Places text into IRC.

Rachael: We are keeping steps, but not defining it.

AWK: I'll review further and let you know if I have any additional comments.

Proposed definition of "inactive"

Rachael: Next topic is proposed definition of inactive.

Alastair: Last week, we discussed proposal on inactive. AWK did define it and we are talking to that in the survey.

Rachael: To AWK, you wanted to talk to read only definition?

<jon_avila> thanks!

AWK: A read only is not intended to be hidden even if it is not changed..
... Talks to how Jon Avila mentioned that topic.

<Zakim> mbgower, you wanted to say I am assuming we aren't just replacing "inactive" with disabled because we don't want to alter normative text?

MikeG: I did a recursive search on inactive vs. disabled. Wanted to confirm reasoning for the text definition. Also talks to inactive definition vs. what "active" is being defined as , such as being interactive by a user vs. non interactive.

<CharlesHall> same. active is also a state in html and css.

Rachael to Gundula: Did you want to speak on your comments?

<CharlesHall> i think the intent is “an element that can be acted upon”.

<kirkwood> +1 Gundula

Gundula: I feel disabled is a variant of inactive and doesn't explain the difference. Disabled means does certainty receive actions. Inactive is not currently active OR the term is expressed that the element doesn't receive action, as to what AWK just stated. The definition does provide clarity.

AWK: When I review "active" I see that in one place at moment, 2.1.4 Success Criteria talks to it.

MikeG: For 1.4.11 Non Text contrast also talks to it in understanding.

<jon_avila> 1.4.3 as well

<jon_avila> Includes inactive

For 1.4.11 : Intent The intent of this Success Criterion is to ensure that active user interface components (i.e., controls) and meaningful graphics are distinguishable by people with moderately low vision. The requirements and rationale are similar to those for large text in 1.4.3 Contrast (Minimum).

<Zakim> alastairc, you wanted to say this started with adding a note to User interface components, but seemed better to add a definition.

Per 1.4.11 Inactive User Interface Components , in understanding: Inactive User Interface Components User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements in WCAG 2.1. An inactive user interface component is visible but not currently operable.

AWK: In being technology independent, we should either define inactive , or define inactive and disabled components.

Rachael: Would it make sense for you to re-work it and resubmit for a revisit on the survey results?

AWK: I would need to Gundula's concern better.

What are examples of the umbrella ?

<mbgower> I can live with the definition (especially because it is only used in regard to contrast assessments)

Gundula: Read only text , being active as it is able to be focused. It also doesn't receive "actions" so it can be "inactive".

AWK: Read only text is not a User interface component, so it would not apply.

<alastairc> It is a definition for "inactive user interface components"

Jon Avila: Could you talk to why a read only user interface component input field is not an interactive component?

<GN015> So an input field which is read-only is a user interface component? Is that right?

<alastairc> Note on read-only text added to the PR: https://github.com/w3c/wcag/blob/WCAG22_inactive_def/guidelines/terms/22/inactive.html

AWK: It is, what I'm talking to is more along the lines of text and read only.

<Zakim> mbgower, you wanted to say is there confusion between inactive and interactive?

MikeG: Talks to inactive vs. interactive controls.

If we change a definition, it would be a CfC change.

Gundula: Is inactive a synonym of disabled?

Alastair: We wanted to distinguish on HTML.

<CharlesHall> action asserts the user does something. interaction asserts the user and the system do something.

<trackbot> Error finding 'asserts'. You can review and register nicknames at <https://www.w3.org/WAI/GL/track/users>.

1.4.11 talks to inactive , An inactive user interface component is visible but not currently operable. An example would be a submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed.

<mbgower> scribe: mbgower

<alastairc> +1

<david-macdonald> +1 I like it

<AWK> +1

<Chuck> +1 to move forward with this definition of inactive

Plus one if you are comfortable moving forward with resolution

<JakeAbma> +1

<Rachael> A state of a User Interface Component when it is not available for user interaction, such as a disabled control in HTML. An inactive user interface component is visible but not currently operable using standard input mechanisms such as keyboard, pointer, or assistive technology.

<Detlev> +1

<Rachael> Note: An example inactive user interface component is a submit button at the bottom of a form which is visible but cannot be activated until all the required fields in the form are completed.

<kirkwood> +1

<Rachael> Note: An inactive user interface component should not be confused with controls which are not currently selected. For example in a tabbed interface, the tabs which are not selected are not regarded as inactive user interface components - they may be interacted with by the user to switch tabs in the tabbed interface, and therefore do not meet the definition of inactive.

<Rachael> Note: A read-only text input field which is focusable using standard input mechanisms is considered to be active.

<jon_avila> +1

<Nicaise> +1

<kirkwood> displayed ?

Jake: Questions the use of the term visible in the definition.

<alastairc> "An inactive user interface component is _visible_ but not currently operable"

Rachael: Suggests adding a note explaining "visible"

AWK: Not requiring contrast is saying 'it's okay to be invisible to some people'. I don't think any of us have been conformtable with that. My advice has been, make it invisible when not active'

Jake: Can we change the word "visible" to "present"?

AWK: I wouldn't object to that.

<kirkwood> present or dispayed ?

Rachael: Does anyone object to that change?

<Chuck> +1 to change, no objections

<AWK> no objections +1.03

<PascalWentz> +1

RESOLUTION: To add the definition of Inactive in this week's survey, including the three Notes listed in the survey results, and the change of 'visible' to 'present' as a normative definition in WCAG 2.2

<CharlesHall> rejoining

Focus visible enh part 3: https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues3/

<alastairc> https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues3/results

AWK: Slightly disappointing results (only 2)

Add another size metric

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-focus-visible-enh-updates/understanding/22/focus-visible-enhanced.html

Alastair: We updated the size indicator to be simpler.

<alastairc> Size metric: The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control.

<alastairc> "The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or an 8 CSS pixel along the shortest side of the element."

Alastair: some discussion talked about allowing a shorter, thicker indicator.
... Having a proportional indicator does create a better result in most cases.
... Any comments? Jake?

Jake: We need to take into account all the different menus out there. For instance 8 px border on the left.
... They will not pass this criteria anymore.

<alastairc> For those that can see it, an example comparison: https://user-images.githubusercontent.com/216630/81121817-840a8580-8f27-11ea-9b1a-1daa61bc70ca.png

Jake: It's a hard one to solve. You are right that a 1px border is better. Those who use squares or single side indicators will fail this in the future. We must be sure we stand behind it.

Alastair: Anyone else?
... People should consider. There are going to be cases that can be argued in both directions.

David M: Talking with a company yesterday creating a major framework, they got a lot of complaints that they made a double one. They got complaints about it being too obvious.

David M: I would like us to consider Jake's proposal.

Alastair: We're not being completely prescriptive.
... Responsive design can make an indicator fail

Brooks: I'm open to remaining flexible with this SC. If we're too open from a user stand point, we introduce potential confusion.

<jon_avila> Consistency of indicator is a separate issue - but one we need to address is Silver. Underline indicators are confusing.

<JakeAbma> example to look at is at: https://codepen.io/JakeAbma/full/rNaggxZ

Alastair: Consistency is important, but it's not one we're trying to address at the moment.

<JakeAbma> when zooming, you will fail, also when making screen smaller it will fail

Alastair: It confuses the focus item with the selected, so I usually advise people to keep them separate.

<jon_avila> Agree with Alastair that the pasted example does confuse focus indicator with selected which is confusing.

Alastair: +1 if you think we should update to include

<Nicaise> +1

<alastairc> Plus one to update to include the new size metric

<JakeAbma> it's not about the focus or selected, can be other colors, it's example for the focus itself

0

<Chuck> +0

<david-macdonald> +1 to consider...

<jon_avila> I'm ok with allowing flexiblity of larger buttons

Jake: The selected versus focused is not the issue. I can change. It is just showing that the button gets wider and that same focus indicator fails, while based on the screen estate it is even more visible.

<jon_avila> You do have retest in each variation per WCAG 2.1 Conformance requirements

David M: We don't normally compound SCs. So if you magnify this, I don't know if I would fail this, because it passes in the default view

Jake: That's not true about Reflow.

Alastair: But this isn't based on Reflow, it's about the page variations.

Rachael: Based on converation so far, we can include or continue considering
... Does anyone have any objections?

Alastair: I noticed the way I phrased it needs rewording.

<alastairc> The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or is at least an 8 CSS pixel border along the shortest side of the element.

<GN015> -1

<Chuck> +1

<david-macdonald> +1

<Fazio> 0

<kirkwood> 0

Please +1 if you are okay with this new wording, or -1 if you object or need more time.

<OmarBonilla> 0

<jon_avila> +1

0

<JakeAbma> +1

<alastairc> AWK - that's the next item

<Detlev> +0 seems very specific...

Gundela: It was discussed in the list that 'border' may be misunderstood.
... It should be 'equivalent to an 8 pixel side...'

<Zakim> AWK, you wanted to ask why we are getting rid of mode of operation?

AWK: My question was, it seems like we're getting rid of our mode of operation language.

Alastair: That's the next survey item.

<Zakim> alastairc, you wanted to say it's a different type of measure

Alastair: I remember the perimeter issue coming up.

<Chuck> +1 to alastair's description

Alastair: We need one surface area requirement. You either do the 1px equivalent or you use the 8 side.

JF: An equivalent to an 8 px side is the size of the indicator.
... We need a definitive unit of measurement.

<GN015> I have seen a wide (around 8px) left side border being used frequesntly as: cursor indicator (if the user enlarged it), or as a marker, e.g. in calendars, tiles, cards, and other user interface elements. have you seen it being used as focus indicator?

JF: The size indicator will have to be 8css pixels wide.

<JakeAbma> https://adrianroselli.com/

MichaelC: A CSS pixel is defined as a relative unit.

Detlev: I'm concerned it's getting too specific.

<alastairc> MichaelC_ - in this case equivelent is about the surface area (in CSS pixels)

Detlev: Some kind of icon indicator, for example.

Jake: Detlev, have you seen the examples Alastair created? I think he created pretty well.
... There is a good explanation of how to measure the stars, etc.

<GN015> On https://adrianroselli.com/ I see the focus indicaator being implemented as a full yellow border, where the left border is wider than the others, for the header controls, and by having the link indicator (underline) disappear for the links within the body.

Rachael: Are you comfortable moving forward?

Gundela: Can you summarize?

<alastairc> "The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or is at least an 8 CSS pixel border along the shortest side of the element."

<JakeAbma> it's under 'blog'

<JakeAbma> the indicators we're looking at

<Detlev> I still think it is far too specific...

Jake: The measurement covers most example out there.

Detlev: Just taking that example that Jake posted, the indication of the focus will be just as good in the responsive review. I find it odd to say just one exception. There may be others that are as visible.

<Rachael> ak gn

Gundela: I would like to mention in this context, when I read the 1 px border, I take it as a mathematical equivalent. If I get something 40 sq pixels, I can use something of the same size. When I say the 8 pixels, I thought it was the same.

Alastair: The first example provides an area. The second scenario is about a relatively thick indicator that is likely to fail because we're using a proportional indicator. So this provides an alternative.
... I'd prefer not to have it.

Rachael: Who feels we need to add it?

<JakeAbma> +1

<alastairc> 0

<PascalWentz> +1

<Francis_Storr> +1

<Jennie> 0

<Chuck> 0

<kirkwood> 0

<AWK> 0

<Detlev> -1

<Rachael> +1 if we need to address the situation, 0 , -1 if you feel the complexity outweighs the need

0

<GN015> -1

<Brooks> 0

<JF> 0

<Rachael> mbgower: Sticking w/ square area calculation, how close is this to being a border edgue using the calculation? How closedoes it come to not failing?

<Rachael> alastair: I haven't run the calculation. It will pass in the desktop. When you zoom it fails.

<Rachael> mbgower: Didn't we establish that zooming in is separate?

<Rachael> alastair: The page variation on smaller screen changes the calculation because it changes the Css pixel width

Jake: To conform to this criteria, he needs to make the menu smaller. So to pass, he makes it harder for some people to interact with.
... We do not want that.

Brooks: I voted 0 in the last poll because i don't have any understanding of what's required. I don't have studies.
... It's difficult for me to have a strong opinion because I don't have an understanding of what's going to fulfil the user need. Let's get the data and let that shape the language.

<OmarBonilla> +1 for finding an evidence-based approach wherever possible

Detlev: I have some anecdotal evidence. It can become a problem if the focus is far removed from the item with focus.
... is it possible to carve out an exception that takes into account the part of the control that is not part of the 'payload'
... I would much prefer something close to the experience of users.

<Zakim> alastairc, you wanted to talk to user need

Alastair: To Brooks' point about the user need, this came out of LVTF.
... We did some testing about pixel borders, adjacent colours...
... The 3 bullet points are the 3 dimensions of how you can make a focus indicator more visible.
... What we are talking about here is 'where do we draw that line?'

<Detlev> just think of a designer choosing right align for the control text in the responsive view, but showing focus on the left sifde (passing the SC with the proposed exception!)

Alastair: A thick block of contrasting color does work, but we're excluding certain things without wanting to but not wanting to make it too complex.

Rachael: I want to wrap this up soon.

GN: I would like to ask... Would a border with a pattern be easier to perceive?

Alastair: It can pass if it is thick enough. It would need to be 2 px thick to pass (assuming the dash is half on half off)

<kirkwood> sorry alastiar cover it basically

<kirkwood> i’m good

Rachael: I"m hearing a slight consensus to address this, but it needs more work.

<kirkwood> I was concerned about low vision needs

RESOLUTION: Keep open and try other wording.

Rachael: Please, please do the surveys in advance. WE need more participation.
... I am circling back to the 'steps' topic. AWK, any concerns?

<GN015> will the questionnaire be open for a longer time frame?

AWK: What is a step? What is not a step? We use it in 2.4.5 but it is in the 'don't do this' context.
... In this case, you have to pay attention to what constitues a step. I am fine getting it out for additional comments, but it is a source of concern.

<Rachael> https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22WCAG+2.2%22+-label%3A%22Technical+%28bug%29%22+-label%3A%22Survey+-+Ready+for%22+-label%3A%222.4.x+Focus+visible+%28enhanced%29%22

<Chuck> https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22WCAG+2.2%22+-label%3A%22Technical+%28bug%29%22+-label%3A%22Survey+-+Ready+for%22+-label%3A%222.4.x+Focus+visible+%28enhanced%29%22

Rachael: I've just pasted in issues. We need someone to sign up. Please take some time and take one on, even if it is starting to analyze it.
... This is a safe way to get more involved.
... Reach out to chairs if you need more help.

Alastair: Read the comment through and think of the possible action we can take. It might be an update to a document, or a response back.
... What would bring that issue to a close?

Rachael: Sometimes it is as simple as a response back.
... Go into an issue. on the right hand side it will say 'assignees'. If there is not name, add yours.

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/may a double/made a double one/
Succeeded: s/relevant/relative/
Succeeded: s/I am finding/I am fine/
Default Present: PascalWentz, Rachael, Chuck, alastairc, stevelee, Francis_Storr, JakeAbma, Detlev, OmarBonilla, Fazio, Brooks, Laura, CharlesHall, kirkwood, mbgower, Nicaise, JF, jon_avila, Jennie, GN
Present: PascalWentz Rachael Chuck alastairc stevelee Francis_Storr JakeAbma Detlev OmarBonilla Fazio Brooks Laura CharlesHall kirkwood mbgower Nicaise JF jon_avila Jennie GN GN015
Found Scribe: ChrisLoiselle
Found Scribe: Chuck
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Scribes: ChrisLoiselle, Chuck, mbgower
ScribeNicks: ChrisLoiselle, mbgower

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: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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