AGWG Teleconference

06 Apr 2021


JakeAbma, Jennie, Sukriti, Raf, jon_avila, juliette_alexandria, alastairc, Chuck_, ben, Nicaise, johnkirkwood, MichaelC, JF, Rain, AWK, MelanieP, morr, MarcJohlic, mbgower, KarenHerr, stevelee, Wilco, StefanS, Laura_Carlson, Francis_Storr, oliverkeim, Rachael, GN, david-macdonald, morr4, GN015
Detlev, SarahH
Jennie, Sukriti


<Jennie> scribe: Jennie

AlastairC: Any announcements?


Chuck_: If you added your present plus before, please try again

Focus appearance survey https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-focus-appearance-sc-update/understanding/22/focus-appearance-minimum.html

AlastairC: We are trying to work through the last few issues.
... We were trying to find a better way to say that the parts of the focus indicator that don't meet the requirements are ok
... Also how you test when you cannot inspect the code.
... There is a list of updates in the link
... Going through the comments
... Starting with Wilco's
... Wilco said accurately determine the shape of the interface but not how
... You don't have an inspectable chunk of code to determine the size in certain situations
... He is suggesting visible pixels of the control
... There was discussion about whether to use the pixels
... I was hoping we could default to it is the component regardless of the pixels in it
... Then for the non-easy examples you can reduce down to the visible size of the component
... I think that is what the note was intended to do

<alastairc> "Note: If the component has a visible boundary smaller than the hit area, or the size of the component is not available, the minimum area can be taken from the visible boundary."

AlastairC: Yes JF we did discuss that
... We added that because the scenario where you have a link within a card that makes the whole card clickable
... But it doesn't increase the size of the control
... You can have a small, visible thing, and you cannot access the code to understand the hit area.

<Zakim> mbgower, you wanted to say the bounding box is of the area with sufficient contrast

mbgower: This is in regard to Wilco's comment
... The bounding boxes is going to be the area that's meeting the contrast requirements
... There are shadows, blended backgrounds - they will not be included
... The contrasting area - the bounding box shape would be

AlastairC: Wilco's point is that within the definition of bounding box
... which all the points of the shape lie
... they rely on the shape of the user interface control

mbgower: We have already said contrast ratio of 3:1

AlastairC: The shape of the control, whereas the contrasting area is the focus indicator that goes around the control

mbgower: In the scenario where the control is bigger?

AlastairC: I'm not sure

Wilco: You are right - that's what I mean
... You don't have the shape of the user interface component
... Which pixels are part of it, and which are not?

mbgower: We are talking about the focus indicator, which in most scenarios are the area we are talking about

AlastairC: But it's the base of the perimeter
... It is defining the size of that for minimum bounding box
... We are going back to if you are in HTML - you just pick the boundary box
... But if you are in a Canvas element you will need to put it around the visible pixels

mbgower: I can live with it, except when the focus indicator is inside

AlastairC: Focus indicator or control shape?

mbgower: maybe I'm just not understanding

AlastairC: Wilco - I raised using the note

(reads note)

scribe: Does that help?

Wilco: What is the visible boundary then?

AlastairC: If you have a border or background within the component
... and you fit your boundary box around it, it would be that

Wilco: I need to see the text again

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-focus-appearance-sc-update/understanding/22/focus-appearance-minimum.html

AlastairC: I will go through other comments and come back to it

<mbgower> +1 to that change

AlastairC: Gundala's comment suggests (reads her suggestion from the survey)
... It makes sense to me
... Any objection to the update?

<alastairc> Agree with Gundula's update to bounding box. "Where a component consists of visually disconnected parts, such as a link that wraps onto multiple lines in a continuous text, each part is considered to have its own bounding box."

AlastairC: We will proceed with that one
... Andrew asked about why we are discussing adjacent contrast
... It is because being sure it is adjacent to colors in the component
... A dark pixel around a dark button makes it almost invisible

<mbgower> We should ensure language in the Understanding document addresses AWK's question.

AlastairC: We originally had adjacent to all colors

AWK: This says the contrasting area - the focus
... Has a contrast ratio of at least 3:1 in the focus component
... Whereas non-text contrast just says against adjacent colors

AlastairC: I think we had taken that not to be the case

<KimD> +1 to AWK

AlastairC: In non-text contrast there is some confusion between the actual element itself and meeting adjacent colors

<jon_avila> for sc 1.4.11 it could be any adjacent colors - you choose - background or component.

<david-macdonald> I could respond

AlastairC: I think we decided it is not applicable within the component, at least for focus

<mbgower> Adjacent to the component

AWK: Do we say in non-text contrast that the focus does not have to contrast against adjacent colors if they are part of the component?

AlastairC: I think so, yes

David-Macdonald: At the time, as soon as focus indicator lands on the component, it becomes part of the component
... Then it has to contrast with the background
... not the component itself - what was there before

<mbgower> "For user interface components 'adjacent colors' means the colors adjacent to the component."

<mbgower> that's from the Understanding doc

AlastairC: I remember there were other scenarios that didn't make sense if we did it the other way around

DM: took me a while to get my head around that it was part of the component

Jon_Avila: my understanding was that if it was on the border, it says adjacent, but doesn't say adjacent to what
... It would be up to the person testing or designing

<alastairc> acm mb

mbgower: The wording in 1.4.11
... We are talking about adjecence to user interface components -
... We are talking about the background adjacent colors
... (reading from the text) means colors adjacent to the component
... I agree that we should have pictures to make it really explicit

AWK: OK, that sounds fine
... That makes more sense
... But, I agree about the Understanding content
... Because I have not looked at this and thought about it - I didn't remember. It is possible that others will run into the same problem

AlastairC: Yes

GN015: I remember that the requirements also has the exception that it may be low as long as the indication area is at least 2 pixels wide
... The indication is only that it becomes larger
... Mentioning colors explicitly here
... which is not tin the non text color requirement
... I am not happy as it is - but this is the difference in having it explicitly here

AlastairC: OK.
... Going back to Wilco's point
... I was happy with it in conjunction with the note
... because it would be for the control, but if you can't tell how big it is, then it is the size

Wilco: Why isn't it always about the size?

AlastairC: Because if you take a typical link or flat design button
... You will have to do more calculations
... Compared to just saying "It's the link"

Wilco: Don't you have to do that anyway?
... If the visible boundary is smaller than the hit area (Like a text link)
... There is often padding around it - above and around
... This makes the visible boundary smaller than the box

AlastairC: What if you are defaulting to it's the component?
... We are saying it can be taken from the visible boundary, not that it is the default
... If the component size isn't available, or the hit area has been artificially expanded
... But we are defaulting to the component size

Wilco: That's not how I understood you previously
... If you have a rounded button - you are saying you would take the border box, and not the circle around the button?

AlastairC: Is the border box larger than the circle?

Wilco: yes

AlastairC: Yes, but what we are saying is you can take it from the visible boundary if you taking that approach

GN015: I have a question about the visible area
... You pointed out that if the hit area is not available
... If it is in the position of the end user - they may not have the knowledge to retrieve the actual hit area
... Why don't we always allow to take the visible area?

<Zakim> mbgower, you wanted to say we need to be cautious of outliers overcomplicating the message

mbgower: I want to emphasize that the easiest thing to implement is to put the outline around the hit area and you have sufficient contrast
... Focusing on the outliers distracts
... Yes, we need to make sure they can be measured consistently

<Zakim> AWK, you wanted to ask about the 4 CSS pixels and the 2 CSS pixels

mbgower: But we want to make sure the way most people will tackle it is easy to understand

AWK: In the shape section - can you explain the 4 CSS pixel lin
... That is 4 CSS pixels thick?

AlastairC: Yes

<mbgower> the word "thick" was in there at one point!

AlastairC: It is an alternative measure that makes sense when you have something like a thick line
... that can have a variable width

AWK: This gives us a value that if someone decides the focus is a little star within the component - it gives something to measure against

<mbgower> Let's put the word "thick" back in

AWK: (reading from the text)
... If the bounding box is 10 x 10
... or 10 x 20
... In that case: 40 CSS pixels in area

AlastairC: Yes

AWK: No thinner than 2 CSS pixels says that whatever you wind up with has to have a thickness of more than 2 CSS pixels
... If I have 40 as my area for my box
... And my focus is a diagonal line that is 25 pixels long
... I made it thinner than 2 CSS pixels then it would fail

AlastairC: I think the intent is that if you have a triangle
... An extended one with a thin area at the top
... 1 px wide, 10 px tall

AWK: I think the problem I have is that we are saying the contrast area is at least as large as...it makes for a very hard to parse sentence
... Let me think if I have suggestions

<KimD> +1 to AWK

AlastairC: This sentence has expanded since we started
... We are looking for where we allow a smaller area

<mbgower> the area of a 4 CSS pixel line along the shortest side of a minimum bounding box of the unfocused component, and is described by a line or shape no thinner than 2 CSS pixels.

AlastairC: Mike was saying we are trying to keep the primary message as simple as we can

Wilco: We are trying to express math in plain language - I'm not sure simple is a reasonable expectation
... I don't know why we are trying to save the border box

AlastairC: We would be saying the contrasting area is 1 CSS px thick perimeter
... Any changes would be on the definition of perimeter
... It will be difficult because what about those things that don't have an easy visual boundary
... You would be making some sort of boundary around the text

Wilco: We had discussed saying either the exact outline, or a box drawn around - whatever is smallest
... That is the perimeter

AlastairC: We would be relying on the minimum boundary box for both size rather than perimeter

Wilco: The perimeter of the minimum boundary box

AlastairC: Yes, but I don't want to use both if we don't have to

AWK: I have a suggestion
... It doesn't account for the perimeter bit
... It makes a couple of other changes

<AWK> https://www.irccloud.com/pastebin/yfdJocmg/

AWK: Instead of "atleast as large as" in the top
... There are 2 bullets
... (reading from his suggestion)
... I changed the order of the 2
... the 2nd one becomes called out as the exception
... The concepts were being intermingled
... because the size comparison was in the introductory text

*Thank you Chuck!

<Chuck_> awk suggestion: Minimum area: The contrasting area is:

<Chuck_> • at least as large as a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component and is at least 2 CSS pixels thick, or

<Chuck_> • at least as large as a 1 CSS pixel thick perimeter of the unfocused component

AlastairC: Is it the fact that it has an additional requirement on the shape?

AWK: yes
... We are trying to say there is a calculation you can make in 1 of 2 ways to determine the area
... a quick ring around the component
... or by calculating the area of a line around one line of the component
... Then if you are doing it this way, it must be at least 2 CSS px thick
... But, someone could say they will calculate the area of a 1 CSS px thick unfocused component ...Perimeter: 56
... If I had a 1 CSS px wide line moving around the inside of that component, that would satisfy it

AlastairC: Yes?
... It is a small component

AWK: Why does that get away with a 1 CSS px line?

AlastairC: It is larger

<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-5.html

AlastairC: If you have a square
... That's where you come to a similar area
... Then once you start lengthening things out
... You get much less area
... Thinner = less area from the shape
... It depends on the shape


AlastairC: We are defining a baseline
... It should be in practice way simpler than the discussion
... In terms of the suggestion - did you just swap them?

AWK: The lead-in text is different
... Because it didn't separate out the "and no thinner"
... In the current one: shape - the area of CSS px line, and no thinner...was tripping me up
... Contrasting area is, and 2 CSS pixels thick - makes it more clear to me
... If people prefer the existing wording, that's fine. Just offering this as a suggestion

<alastairc> Poll: Current wording (1), Proposed update (2) f

<alastairc> 1

<david-macdonald> 1 fine either way though

<AWK> 2

<Chuck_> 2, no objections to 1

<Wilco> no preference

<GN015> 1

<laura> 1

<ben> 1

<KimD> 2, but still complex

<JF> slight lean to 1, but either works

<Sukriti> 1

<jon_avila> Nothing in the new SC indicates that the minimum focus areas need to be consecutive

<Rain> 2

<johnkirkwood> 2

jon_avila: say we have something that is 2 pixels wide, but it doesn't have to be contiguous
... as long as the total area adds up to 4 pixels

AlastairC: Yes, you could do a checkered patter with blocks of 4 pixels

<Raf> 0

<AWK> 8:39 in IRC Mike

AlastairC: Yes, that is possible
... but if it is at least more than 1 pixel it bumps it up

Chuck: I think 1 is the winner

AlastairC: OK, we will stick with 1

<mbgower> 2

<AWK> a tie

AlastairC: Let's continue with Wilco's point
... For Wilco's point the change would be in the outline bullet

<alastairc> "Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component,"

<alastairc> "Outline: the area of a 1 CSS pixel thick line around the minimum bounding box of the unfocused component"

Wilco: sorry, that doesn't quite work

AlastairC: I am trying to figure out what that would mean in this context

mbgower: I do think that the proposal could work - it seems to read more clearly
... I can live with either

AlastairC: I am in that state of mind - we want to get something out for review
... Things have changed a lot
... I want to get through everything we can

<Wilco> 1 CSS pixel thick perimeter around the visible pixels of the unfocused component

AlastairC: Wilco - what would work for that outline?
... Keep perimeter rather than minimum visible bounding box

Wilco: yes
... We can have a note in the Understanding Document
... to say that visible borders should not include shadows or glows

AWK: This brings us back to whether it is around the component, or part of the component
... for that perimeter

Wilco: Around

AWK: In the definition of perimeter it is calculated to be inclusive of the area of the component, and I think
... we are saying additional to that, which would change the calculation
... to 2y+4

<JF> +1 Andrew

Wilco: good point

<johnkirkwood> +1 Andrew

AlastairC: I think the bigger change is that for components which have padding but no border or background
... the requirement is then less
... which may not be a bad thing
... It just triggers more people to do calculations

Wilco: If they have a border around it, they are good always

GN015: If you discuss the perimeter of the text people might follow the curves of all the letters

Wilco: good point

<johnkirkwood> +1

Wilco: then we would still need the trigger of the boundary box

AlastairC: We still need some kind of word

Wilco: Bounding box isn't really a box

<Rain> "perimeter of the text area"

<AWK> Why isn't it a box?

Wilco: that doesn't need to be a box

AlastairC: We have box in the definition

AWK: I thought we were saying it was a box

<alastairc> "minimum bounding box: the smallest enclosing box within which all the points of a shape lie."

AWK: If there was a circle, with a square bounding region
... there is still a box around it

<mbgower> maybe we should say rectangle

AlastairC: That does increase the requirement

<JF> AND it's always a box

<johnkirkwood> text area? highlight area?

AWK: But for a circle you could still have a 1 px thick perimeter of the visible component

<mbgower> bingo

<JF> @mgower in CSS they speak of the 'box-model'

AWK: You would be looking at one bullet, not the other one

Wilco: No you wouldn't
... Because of the 2 px requirement
... I tried to take out the 2 px minimum requirement and that gets a lot more complicated

<david-macdonald> explain please

AlastairC: If you had a 100 pixel square
... you have 400 pixels
... but with a circle you have 314 - quite a bit less
... It does increase the requirement for circles

<david-macdonald> why not a 1px around a circle.... ?

AWK: When we said perimeter of the circle

AlastairC: Previously we said it was 1 CSS pixel of the focused component
... or whatever your browser would tell you about the size of the component
... and the min area can be taken from the visible boundary
... That was to try to cover the grey area

AWK: I don't understand the problem with perimeter
... If you look at the continuous line which comes from the visible boundary
... If you choose that instead of the bounding box

AlastairC: I agree with that, but Wilco wanted to have something in the SC text that is applicable across scenarios

<mbgower> It would be sufficient

David-Macdonald: Are we saying a circle with 1 px would be sufficeint because the hit area is a square?

AlastairC: In the current text I would say that was sufficient
... If we go with the bounding box
... The area doesn't quite come up to the same
... The underlying code - that circle is within a square

<Zakim> Chuck_, you wanted to ask for scribe change at top of hour

<Sukriti> scribe:Sukriti

Alastair: current approach - you can tell what size the control is and if there is a discrepancy between underlying code and visible area, you can fall back on visible size. Assumptions built in there
... Alternative is bounding box route and use as a default. Different types of control will be different. Fairly arbitrary
... If testing, bounding box approach better
... can't do both at the same time

davidm: testing with bounding box is a great win

Alastair: In other areas of the web page, might be harder

<mbgower> Is this a decision killer for anyone in either way?

<alastairc> Poll: Current text (1), Taking bounding-box approach to all sizing (2).

<mbgower> Either approach is okay, prefer 1

Davidm: could we phrase something like. If you have a non-boxlike shape, you're basically going to be doing 2 pixels
... is that a better way of explaining it

<JF> A complex shape liek that will still have a box-model hit region (unless it's an image map)

alastair: for a complex shape like a star, 1 pixel outline along the shape is going to be longer than a bounding box
... other shapes will be more

JohnF: in native html, everything is going to use the box model
... in an image map, you can define a polygon region

<Wilco> There are more

JohnF: the other concern is floating content
... z index layer than other content. Not measuring on the same plane
... let's work with what we've got (box model)

<alastairc> Poll: Current text (1), Taking bounding-box approach to all sizing (2).

<GN015> prefer 1

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-focus-appearance-sc-update/understanding/22/focus-appearance-minimum.html

<Chuck_> 2, struggle with 1

Alastair: star passes more easily, circle doesn't pass as easily

Wilco: buttons with rounded corners too, not just circle

<jon_avila> why can't we allow either?

Wilco: all would need a 2 px border if we go the bounding box route

JohnA: Can we allow either?

<JF> I like the either/or approach

Alastair: That's what we currently have. Open to objections

davidm: do we mean the visible unfocused component in the current wording?

Alastair: the area of the component in the code. If there is a visible boundary, the area can be taken from there

Davidm: The proposed language seems to say that

Alastair: 1 pixel perimeter around the bounding box of the unfocused component
... doesn't take into account the shape of the component
... As an author if you can just say 1 pixel outline with a contrasting color, won't be more complicated than needs to be

JohnK: the border radius has never been discussed
... visually highlights the focus area a lot
... default is 2-4 pixels
... this would make it less accessible

<Zakim> mbgower, you wanted to address Jon's comment

MikeG: they're going to have to increase the border
... in css you would define the border as a 2 pixel solid color. By introducing a border-radius, you're making the line shorter
... you're going to have to bump to 2 px to accomodate

<alastairc> Current approach (1), Bounding box for everything (2)

<ben> 1

<mbgower> 1 preferred

<david-macdonald> 1

<Rain> 1

<jon_avila> Current approach

<alastairc> 1

<Wilco> ... 3?

<johnkirkwood> 1

<JakeAbma> 1

<Chuck_> 1


<Wilco> My option 3: Area: The contrasting area is at least as large as a 3 CSS pixels border along the shortest side of the unfocused component box.

Mikeg: Is there a problem with getting this out to the public and opening an issue?

Wilco: Don't mind if we can revisit

Alastair: Anyone objecting to current text?

RESOLUTION: Accept the amended updates to the SC Text and understanding document for Focus Appearance

<mbgower> is "thick" being added?

<mbgower> sorry

<mbgower> second sub-bullet

The math is difficult to understand and explain #1439

Alastair: Techniques are not too complicated but defining visible is
... what we're discussing is not changing requirements
... focused on testing niche cases

Kim: Wording is more complex than it needs to be
... we know more than a designer or developer
... if we see issues, not sure how someone without specialized knowledge will parse

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-focus-appearance-sc-update/understanding/22/focus-appearance-minimum.html

Alastair: The intent of the understanding document makes it pretty clear
... if there is a way to make the wording simpler with same requirements, all in

<Zakim> Chuck_, you wanted to ask about simplifying

Chuck: I like the idea of simplified but every try has been met with exposure to limitations

<david-macdonald> "make it a simple as possible, but no simpler" Albert Einstein

Alastair: Allowing a bit of flexibility, got a AAA version that is harder to meet. Can also explain in the understanding document
... will be voting against having this requirement at all

<alastairc> Poll: Accept response (1), Something else (2)

<Zakim> Chuck_, you wanted to ask about not including it?

Chuck: Simplest approach is to not include it because haven't been able to simplify further

<mbgower> 1 add suggest we will be updating hte Understanding document

<jon_avila> what is the resposne?

<GN015> 1

<alastairc> https://github.com/w3c/wcag/issues/1439#issuecomment-802405219

<KimD> 2 - same as my comment. But also agree that the concept is needed.

Melanie: Potential alternative. Include exception for using browser default focus indicator and leaving door open for custom indicator

<johnkirkwood> +1 to Melanie

<KimD> +1 to Melanie - that exception is a good idea

<jon_avila> The Firefox indicator is hard to see and we've tried for many many years and I have not been able to move it.

<Chuck_> 1, because we will have another round of review, and I'm not in favor of ditching (yet)

<ben> 1

<jon_avila> I am opposed to dropping the SC.

MikeG: It wouldn't hurt to say in the response that the understanding document will be updated

JohnA: If you were using the default focus indicator, and it meets the requirement you don't need a custom indicator

<Zakim> Chuck_, you wanted to ask say how we got to the possibility of dropping

Alastair: Likelihood of browsers updating indicators is higher if this is part of 2.2

Caryn: There have been improvements but still difficult to understand. We have done straw polls in the company
... current state is not clear to people

<mbgower> We don't have techniques in. that would help.

Alastair: Do the teams look at the understanding document as part of the process?

Caryn: We asked them to

<david-macdonald> most dev teams don't look at understanding in my experience.

RESOLUTION: Accept the proposed response to address issue #1439

Target size/spacing (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results

Alastair: Will be CFCing the SC and looking at understanding document text

<alastairc> "The offset from A to B may be different than the offset from B to A, if the size of these targets differs."

Alastair: Did everyone get the A to B aspect?
... with editorial changes incorporated, is everyone happy to accept?
... to put in a CFC for wide review

<Chuck_> +1 to Alastair

<david-macdonald> +1 to amendment

+1 as well

RESOLUTION: Agree with the updated and amended SC text for Pointer Target Spacing

<jon_avila> Open issue related to the Firefox default focus indicator https://bugzilla.mozilla.org/show_bug.cgi?id=1284235

Summary of Action Items

Summary of Resolutions

  1. Accept the amended updates to the SC Text and understanding document for Focus Appearance
  2. Accept the proposed response to address issue #1439
  3. Agree with the updated and amended SC text for Pointer Target Spacing
[End of minutes]

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

Scribe.perl diagnostic output

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

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/increase the radius/increase the border/
Succeeded: s/You're making the line shorter/By introducing a border-radius, you're making the line shorter/
Default Present: JakeAbma, Jennie, Sukriti, Raf, jon_avila, juliette_alexandria, alastairc, Chuck_, ben, Nicaise, johnkirkwood, MichaelC, JF, Rain, AWK, MelanieP, morr, MarcJohlic, mbgower, KarenHerr, stevelee, Wilco, StefanS, Laura_Carlson, Francis_Storr, oliverkeim, Rachael, GN, david-macdonald
Present: JakeAbma, Jennie, Sukriti, Raf, jon_avila, juliette_alexandria, alastairc, Chuck_, ben, Nicaise, johnkirkwood, MichaelC, JF, Rain, AWK, MelanieP, morr, MarcJohlic, mbgower, KarenHerr, stevelee, Wilco, StefanS, Laura_Carlson, Francis_Storr, oliverkeim, Rachael, GN, david-macdonald, morr4, GN015
Regrets: Detlev, SarahH
Found Scribe: Jennie
Inferring ScribeNick: Jennie
Found Scribe: Sukriti
Inferring ScribeNick: Sukriti
Scribes: Jennie, Sukriti
ScribeNicks: Jennie, Sukriti

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]